Destroy 6 of mobile application designs for granted

Over the past few years, user interaction has evolved so quickly that designers can't keep up with them-leading to the copying of interactive design techniques from other media (and even outdated application designs) when creating mobile applications.

It's important to remember that interaction patterns and designs change as the media change.

The first phase of this idea is seen in the process of a desktop computer with a mouse keyboard transitioning to a touchscreen (Apple's new 3D touch is a finer example). Every new device, environment, pattern, and gesture brings opportunities and pitfalls from a new interaction model to a small interaction detail and trend.

It takes a lot to get to know them--let alone design them--and here are some of the things you should avoid when designing mobile apps.

　　1. Users always need to create accounts

They don't need it, and many times they don't want it or need it.

As developers, it is easy to shut them out unless the user is solidified into a database. But from the user's point of view, this is not a glorious move.

Why do you have to register before you know what's inside? This process is laborious and must be worth the money.

Instead, user data can be stored offline and transferred to the account when the user finally decides to create an account. Alternatively, consider using the "visitor" or "trial" mode to open core functions (such as the wunderlist below) to show the functionality of the application, but with limited functionality, or with watermarks.

Once your application is proven to be valuable, users will no doubt decide to sign up. Before that, it was a bit too much to ask.

　　2. Users need a tutorial to tell them how good your application is.

Let users use it to show how good your application is. It is very feeble to explain how good it is. Also, users usually skip and forget the boot page.

The user who has browsed all the instructions does not quite understand the entire guide page design.

If you definitely need the user's full attention, step-by-step through the boot (and some apps do), try to be as short as possible and present it with the Help menu. This is more meaningful even after the user has spent some time.

▲flipboard's Boot interface

　　3. Do not assume that some way to adapt to all applications

Even common patterns of interaction should be evaluated based on the specific circumstances in which you apply them.

A common example is the "province" Drop-down option in the Address input box. Since the province name can be written in several different forms, the standard predefined content Pull-down menu has its reasonable meaning. This may be acceptable on the desktop side (although this is debatable), but the drop down menu is the worst option for mobile-side availability.

Application interaction is also an excellent opportunity to emphasize branding. In today's apps, there are some very memorable brand "moments", such as Twitter birds, Snapchat's profile pictures animations, and hopper loading pictures (see 5th), from the launch map into the flow of information.

The point is that we should not be superstitious about time-tested methods, which are not the only way to make our applications shine.

Hopper application of the loading interface.

　　4. Application design and responsive web design is one thing

Although the response design is similar to the mobile application design, it is a big difference for any device design, and for independent application design.

Users expect specific interaction patterns and interface elements in mobile applications.

For example, there is usually a "back" button in the upper-left corner of the iOS application to return to the previous interface. In a Web browser, the site itself doesn't need to return a button; it's usually omitted because it's too much like the browser itself.

Although this is a very basic and obvious example, everything is subtly different from menus and forms to "pop-up windows" and font sizes. Our design in Web pages is often a bit awkward or rough in mobile apps-not necessarily something wrong, but it's different.

▲TD Bank iOS App login and LinkedIn iOS app login

Compare the TD Bank iOS version and the LinkedIn iOS version of the login interface.

In the TD Bank iOS app, you'll find that their main UI elements are applied, with the back button in the upper left corner and a column menu at the bottom (consistent with iOS mode). There is no design style for the login box itself (and other page content), as applied. The default iOS fillet and shadow are on the input box, the check box is very small, the links are underlined, and the UI even has a copyright notice. Lack of a unique sense of application.

On the contrary, LinkedIn iOS apps feel like an app, not because of a particular design or interface element, but because they don't pack the pages into apps. They're designed for apps, not mobile pages--we can see the difference.

　　5. "Load small turntable" is the expression of loading and thinking in the correct way

The default load icon (such as the small turntable of iOS, the Gray line that emanates from the center point) seems to have a negative implication.

They not only appear not time, but also as a function of mobile operating system, indicating the state of all things. Booting from the device to a connection WiFi problem or slow application loading.

Because of this, people hate to see a lone turntable, without any indication of information or time schedule.

Instead, try to make the load feel more natural--and even hide it. One way is to imply content through placeholder elements, and Facebook renders the loading state of the timeline. You can also take advantage of this opportunity to get creative with loading indicators and information, such as adding some fantastic ideas to the interface or emphasizing branding.

　　6. When users first use, will blindly allow notification

You must not rely on the default "Allow Notifications" dialog box for the operating system. This brain-free design will trip countless mobile-end designers. First, it doesn't make it clear why applications need access to the user's privacy anytime, anywhere.

Instead, you should design a custom allow notification interface in your application.

Always tell the user how important your alerts are (show them as many examples as possible) and assure them that there will be no unwanted spam bombing.

Once users understand the value of applying notifications, be cautious about providing native, system-based Windows--they'll see it right away and don't mess things up.

A widely publicized recently applied Peach is perfect.

Its first "Allow Notifications" dialog box looks much like the real iOS System dialog box (but not), explaining why it needs to be notified and dispel doubts. When users click "Allow", they will see the Real iOS System dialog box (which, by contrast, is a lot more useless).

　　7 (and more)

People expect more from the application interface, and standards are rising.

For an application based company, ignoring the details can damage the application's acceptance-and even damage your relationship with the user.

The above 6 assumptions are just the beginning. If you want to go further, learn to be mindful and avoid everyday assumptions. Be careful not to assume that you know what the interface is best for--always try to find the best solution.