{"id":11647,"date":"2016-01-22T17:35:54","date_gmt":"2016-01-23T01:35:54","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=11647"},"modified":"2024-09-09T07:32:41","modified_gmt":"2024-09-09T14:32:41","slug":"6-assumptions-that-kill-your-mobile-app-design","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/6-assumptions-that-kill-your-mobile-app-design\/","title":{"rendered":"6 Assumptions That Kill Your Mobile Application Design | UXPin"},"content":{"rendered":"

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

In reality, it\u2019s important to remember that our interaction patterns and interaction design need to change when the medium changes.<\/p>\n

The first step toward this kind of thinking was seen during the transition from mouse and keyboard desktops to touchscreens (Apple\u2019s new 3D Touch<\/a> 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.<\/p>\n

\"image05\"<\/p>\n

Photo credit: <\/i>Apple<\/i><\/a><\/p>\n

It takes serious work just to know what\u2019s out there\u2014let alone to design for it\u2014so here are a few assumptions you should avoid in your mobile app design.<\/p>\n

1. Users always need to create an account<\/h2>\n

They don’t, and a lot of times they won’t and shouldn\u2019t have to. <\/p>\n

As a developer, it\u2019s much easier to lock users out until they\u2019ve solidified an entry in the user database. But from the user\u2019s perspective, that\u2019s almost devious. <\/p>\n

Why would anyone sign up before knowing what they\u2019re in for? The process is mental and physical work. It has to be worth it.<\/p>\n

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 \u201cguest\u201d or \u201ctrial\u201d mode access to key functionality (like Wunderlist below), showing off what your app can do, but with limited or watermarked features.<\/p>\n

\"image02\"<\/p>\n

Photo credit: <\/i>Wunderlist<\/i><\/p>\n

Once you prove your app\u2019s value, the decision to sign up will be no problem for a user. Before that, it\u2019s a big ask.<\/p>\n

2. Users need a tutorial to show them how awesome your app is<\/h2>\n

Show them how awesome your app is by letting them use it. Explaining that it\u2019s awesome is much less powerful. Plus, onboarding is typically skipped and often forgotten. <\/p>\n

Users who swipe through instructions aren\u2019t getting much out of the Onboarding Show.<\/p>\n

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\u2019ve used the app for a while.<\/p>\n

\"Screen<\/p>\n

Photo credit: <\/i>UXCam<\/i><\/a><\/p>\n

3. Don\u2019t assume what works for one app works for another<\/h2>\n

Even common interaction patterns<\/a> should always be evaluated in light of the specific circumstances of your application. <\/p>\n

A common example of this is a dropdown \u201cState\u201d 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\u2019s debatable), but dropdowns are the worst choice for mobile usability. <\/p>\n

App interactions are also a great opportunity for brand reinforcement. There are a handful of really memorable, branded \u201cmoments\u201d in apps today, such as the Twitter bird when the app goes from splash screen to feed, Snapchat\u2019s animated profile picture, or Hopper\u2019s loading graphic (more on this in assumption #5). <\/p>\n

The point is that we shouldn\u2019t assume the tried and true method is the only approach to making our app stand out.<\/p>\n

\"image01\"<\/p>\n

Hopper App\u2019s<\/i><\/a> loading screen.<\/i><\/p>\n

4. App design is the same as responsive web design<\/h2>\n

While responsive design<\/a> is similar to mobile app design<\/a>, there\u2019s a big difference between designing for any device versus standalone applications.<\/p>\n

Users expect certain interaction patterns and interface elements in mobile apps. <\/p>\n

For example, it\u2019s common in an iOS app to have a \u201cback\u201d button in the top left for returning to the previous screen. In a mobile browser, there\u2019s no need for a back button on the site itself; it\u2019s generally omitted because it would be too similar to browser chrome.<\/p>\n

While that\u2019s a fairly basic and obvious example, there are nuances to everything from menus and forms to \u201cpopovers\u201d and font sizes. What we design on the web often feels awkward or unpolished in a mobile app\u2014not necessarily because something is wrong, but because it\u2019s different.<\/p>\n

\"image03\" \"image04\"<\/p>\n

Credit: <\/i>TD Bank iOS app<\/i><\/a> sign-in and <\/i>LinkedIn iOS app<\/i><\/a> sign-in<\/i><\/p>\n

Compare the TD Bank iOS app sign-in screen with the LinkedIn iOS app sign-in screen. <\/p>\n

In the TD Bank app, you\u2019ll 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\u2019t 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\u2019s even a copyright notice in the UI. It lacks the distinctive feel of an app.<\/p>\n

In contrast, the LinkedIn iOS app does<\/i> feel like an app, though not because of any specific design or interface element. It\u2019s because they didn\u2019t port over web code and wrap it as an app. They designed for an app, not the mobile web\u2014and we can tell the difference.<\/p>\n<\/section>

Grab design ebooks created by best designers<\/h3>

All for free<\/p>