[Foreign Design Issue 121]

Over the past few years, user interaction has evolved so rapidly that designers can hardly keep up — leading to the adoption of interaction design techniques from other media (and even older app designs) when creating mobile apps.

It’s important to remember that interaction patterns and design change as the medium changes.

The first stage of this thinking can be seen in the transition from desktop computers with mouse and keyboard to Touch screens (Apple’s new 3D Touch[1] is a more elaborate example). Every new device, environment, mode, and gesture brings opportunities and pitfalls, from entirely new modes of interaction to tiny details and trends.

Photo credit:Apple[2]

It takes a lot of work just to understand them — let alone design for them — and here are a few things to 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 a developer, it’s easy to shut users out unless you solidify them into a database. But from a user’s point of view, it’s unglamorous.

Why do I have to register to find out what’s in there? The process is laborious and has to be worth it.

Instead, user data can be stored offline and transferred to an account when the user finally decides to create one. Alternatively, consider using “visitor” or “trial” mode, exposing core functionality (such as Wunderlist[3] below), showing application functionality, but with limited functionality, or watermarking.

Photo credit:Wunderlist[4]

Once your app has proven its value, users will no doubt decide to sign up. Before that, it’s a bit much to ask.

2. Users need a tutorial that tells them how great your app is

Let them use it and show them how great your app is. Explaining how good it is is very weak. Also, users often skip and forget the boot page.

The user who reads all the instructions does not understand the entire lead page design.

If you absolutely need the user to pay full attention and navigate step by step (and some apps do), keep it as short as possible and present it with a help menu. This makes a lot more sense, even after the user has used it for a while.

Photo credit:UXCam[5]

3. Don’t assume one size fits all

Even common interaction patterns [6] should be evaluated according to the specific context of your application.

A common example is the “province” drop – down option in the address box. Since the name of a province can be written in several different forms, the standard predefined content drop-down menu makes sense. While this may be acceptable on the desktop (though debatable), drop-down menus are the worst option for mobile usability.

App interaction is also a great opportunity to emphasize the brand. There are some memorable brand “moments” in today’s apps, such as Twitter Bird when entering a news stream from a splash image, Snapchat’s animated profile image, and Hopper’s loading image (see # 5).

The point is that we shouldn’t be superstitious about tried-and-true methods. That’s not the only way to make our apps shine.

Loading interface for Hopper app [7].

4. App design and responsive Web design are the same thing

Although responsive design [8] is similar to mobile application design [9], there is a world of difference between designing for any device and designing for standalone applications.

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

For example, iOS apps often have a “Back” button in the upper left corner to return to the previous screen. In a Web browser, the site itself does not need a back button; It is usually omitted because it is too similar to the browser itself.

While this is a very basic and obvious example, everything from menus and forms to “pop-ups” and font sizes vary slightly. What we do on the web is often a little awkward or crude in mobile apps — not necessarily because there’s something wrong with it, but because it’s different.

Photo source:TD Bank iOS app[10]The login andLinkedIn iOS app[11]The login

Compare the login screen for TD Bank iOS to LinkedIn iOS.

In the TD Bank iOS app, you’ll find their main UI elements made to look like the app, with a back button in the upper left corner and a menu at the bottom (in line with iOS). Instead of styling the login box itself (and the rest of the page’s content), as apps do. Input boxes have default iOS rounded corners and shadows, check boxes are very small, links are underlined, and there’s even a copyright notice in the UI. Lack of an application-specific feel.

By contrast, the LinkedIn iOS app does feel like an app, though not because of any particular design or interface element. It’s because they don’t package the web as an app. They’re designed for apps, not mobile web — we can see the difference.

5. “Load the wheel” is the right way to express loading and thinking

The default loading ICONS (such as the small dials on iOS, with gray lines emanating from the center point) seem to have negative connotations.

Not only do they come at an inopportune time, they are also a feature of mobile operating systems that indicate the state of everything. From powering up your device, to having problems connecting to wifi, or apps loading slowly.

For this reason, people hate to see a single wheel, with no indication or timeline.

Instead, try to make loading feel more natural — or even hide it. One way is to hint at content through placeholders, which is how Facebook shows the loading status of the timeline. You can also take advantage of this opportunity to get creative with loading indicators and information, such as adding whimsy to the interface or emphasizing the brand.

Photo credit: Facebook iOS app[12]

6. Users blindly allow notifications when they first use it

Never rely on the operating system’s default Allow Notifications dialog box. This mindless design will trip up countless mobile designers. First, it doesn’t make it clear enough why an app needs permission to violate users’ privacy anytime, anywhere.

Instead, design a custom “allow notification” interface in your application.

Always tell your users how important your notifications are (show them examples if you can) and assure them that they won’t be bombarded with unnecessary spam.

Once users understand the value of app notifications, be careful to provide native, system-based pop-ups — they’ll see them right away and won’t mess things up.

Photo credit:peach.cool/[13]

A recent, widely publicized app Peach[14] does it perfectly.

Its first “Allow notifications” dialog looks a lot like a real iOS dialog (but it isn’t), and they reassure by explaining “why” notifications are needed. After clicking “Allow,” the user is presented with the actual iOS dialog box (which is much less useful by comparison).

Photo credit:peach.cool/[15]

7 (and more)

People expect more from the interface, and the bar is rising.

For app-based companies, inappropriately ignoring details can hurt your app’s acceptance — and even damage your relationship with your users.

These six assumptions are just the beginning. If you want to go further, learn to be mindful and avoid everyday assumptions. Be careful not to assume you know what interface works best — always try to find the best solution.

To learn more about ux design best practices, see the Definitive UX Design Ebook Collection 2016 [16]. This collection contains over 350 pages and over 300 examples of mobile design, user experience design, and web design.

Original link: studio.uxpin.com/blog/6-assu… [17]

Author Information: Drew Thomas Drew Thomas is the chief creative officer and a co-founder of Brolik[18], a Philadelphia digital design agency. While Brolik is his focus, He also fails to find a “maker” and tinkers with all kinds of side projects, both digital and physical.