6 assumptions that will kill your mobile app design

User interactions have evolved so rapidly during the last few years that designers can barely keep up—making it tempting to use interaction design techniques from other media (or even legacy app design) when we build mobile applications.

In reality, it’s important to remember that our interaction patterns and interaction design need to change when the medium changes.

The first step toward this kind of thinking was seen during the transition from mouse and keyboard desktops to touchscreens (Apple’s new 3D Touch is a current and more granular example). From entirely new interaction patterns to smaller interaction details and trends, every new device, environment, pattern, and gesture comes with possibilities and pitfalls.

Photo credit: Apple

It takes serious work just to know what’s out there—let alone to design for it—so here are a few assumptions you should avoid in your mobile app design.

1. Users always need to create an account

They don’t, and a lot of times they won’t and shouldn’t have to.

As a developer, it’s much easier to lock users out until they’ve solidified an entry in the user database. But from the user’s perspective, that’s almost devious.

Why would anyone sign up before knowing what they’re in for? The process is mental and physical work. It has to be worth it.

Instead, user data can be stored locally and eventually transferred to an account if and when the user ultimately decides to create one. Or, consider “guest” or “trial” mode access to key functionality (like Wunderlist below), showing off what your app can do, but with limited or watermarked features.

Photo credit: Wunderlist

Once you prove your app’s value, the decision to sign up will be no problem for a user. Before that, it’s a big ask.

2. Users need a tutorial to show them how awesome your app is

Show them how awesome your app is by letting them use it. Explaining that it’s awesome is much less powerful. Plus, onboarding is typically skipped and often forgotten.

Users who swipe through instructions aren’t getting much out of the Onboarding Show.

If you feel you absolutely need a full-attention, step-by-step onboarding (some apps do), then keep it as short as possible and offer it through a help menu. It will make a lot more sense after they’ve used the app for a while.

Photo credit: UXCam

3. Don’t assume what works for one app works for another

Even common interaction patterns should always be evaluated in light of the specific circumstances of your application.

A common example of this is a dropdown “State” field in an address form. Since state names may be written in a couple of different ways, it makes logical sense as a dropdown of predetermined, standardized values. This may be acceptable on a desktop (although that’s debatable), but dropdowns are the worst choice for mobile usability.

App interactions are also a great opportunity for brand reinforcement. There are a handful of really memorable, branded “moments” in apps today, such as the Twitter bird when the app goes from splash screen to feed, Snapchat’s animated profile picture, or Hopper’s loading graphic (more on this in assumption #5).

The point is that we shouldn’t assume the tried and true method is the only approach to making our app stand out.

Hopper App’s loading screen.

4. App design is the same as responsive web design

While responsive design is similar to mobile app design, there’s a big difference between designing for any device versus standalone applications.

Users expect certain interaction patterns and interface elements in mobile apps.

For example, it’s common in an iOS app to have a “back” button in the top left for returning to the previous screen. In a mobile browser, there’s no need for a back button on the site itself; it’s generally omitted because it would be too similar to browser chrome.

While that’s a fairly basic and obvious example, there are nuances to everything from menus and forms to “popovers” and font sizes. What we design on the web often feels awkward or unpolished in a mobile app—not necessarily because something is wrong, but because it’s different.

Credit: TD Bank iOS app sign-in and LinkedIn iOS app sign-in

Compare the TD Bank iOS app sign-in screen with the LinkedIn iOS app sign-in screen.

In the TD Bank app, you’ll see that they treat the main UI elements like an app, with a top left back button and a visible menu across the bottom (consistent with iOS patterns). What they didn’t do was style the sign-in form itself (and other page content) like an app. Default iOS rounding and shadow are used for inputs, the checkbox is tiny, links have been underlined, and there’s even a copyright notice in the UI. It lacks the distinctive feel of an app.

In contrast, the LinkedIn iOS app does feel like an app, though not because of any specific design or interface element. It’s because they didn’t port over web code and wrap it as an app. They designed for an app, not the mobile web—and we can tell the difference.

5. “Loading spinners” are the right way to indicate loading or thinking

Default loading icons (like the iOS spinner of gray lines radiating from a central point) tend to have negative connotations.

Not only do they appear at undesirable times, they serve a variety of mobile operating system functions, indicating the status of everything from device start-up to problems connecting to wifi or loading a slow application.

Because of that, people hate to see only a loading spinner with no indication of progress or time.

Instead, try to make loading feel natural—or even hide it. One way is to hint at content using placeholders, something the Facebook app does as it loads the timeline. You can also use the opportunity to get creative with loading indicators and messaging, such as adding whimsy to your interface or reinforcing your brand.

Credit: Facebook iOS app

6. Users will blindly allow notifications upon first use

Never rely on the operating system’s default “allow notifications” dialog. This is a no-brainer that trips up countless mobile app designers. To begin with, it doesn’t say nearly enough about why an app needs permission to invade a person’s privacy any time it pleases.

Instead, build a custom “allow notifications” interface into your app.

Always tell users why your notifications are important (show them an example if you can) and reassure them they won’t be bombarded with spammy or unnecessary messages.

Once the user understands the value of your app’s notifications, carefully offer the official, OS-based popup—they’ll see it only once, so you don’t want to mess this up.

Credit: http://peach.cool/

The new and highly publicized app Peach does this perfectly.

Its first “allow notifications” dialog looks like a real iOS system dialog (but isn’t), and they explain the “why” behind the notifications, leaving no room for confusion. It’s only after the user taps “Allow” that they’re shown the real iOS system dialogue (which is a lot less usable, by comparison).

Credit: http://peach.cool/

7 (and beyond)

People expect a lot from app interfaces today, and the standards are just getting higher.

For an app-based business, ignoring the wrong detail can be detrimental to app adoption—or even sabotage your relationship with the user.

These six common assumptions are merely the start. If you want to get ahead, learn to notice and avoid the assumptions we make every day. Be cautious and don’t assume you know what’s most appropriate for an interface—always work toward finding the best solution.

To learn more about mobile UX design best practices, check out the Definitive 2016 UX Design Ebook Bundle. The bundle includes 350+ pages and 300+ examples of advice for mobile design, UX design, and web design.