4 UX Design Tips for Mobile Apps
User experience (UX) decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the app world, onscreen objects like buttons, sliders, and ﬁll-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. What actions will occur as a result of the user interacting with those widgets?
Keep in mind that users will expect to interact diﬀerently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their ﬁngers instead of a mouse or a trackpad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling and working the app’s other controls — the Path app is a good example, and increasingly so is Facebook.
When designing specifically for Android, you will also need to decide which parts (if any) of your application to write in HTML5 and which to write in Java, the primary programming language for Android devices. For reasons of speed and programming eﬃciency, many apps (like Facebook) are designed a little like 1960s-era TV sets where a small window of frequently updated content (the HTML5 part) sits within an application wrapper (the Java part) that implements less dynamic content such as the app’s widgets. Which part of the app is HTML5 and which is Java is not obvious to the untrained eye (there may be no browser address bar, for example) — but implementing the app this way enables much faster content refresh (via the web) and more responsive widgets (via Java). HTML5’s “write once, deploy anywhere” model is also another advantage. Parts of the app written in HTML5 can be deployed across iPhones, iPads and Android devices without rewrite.
In addition to deciding what happens on the frontend, you also have to decide what happens on the backend — speciﬁcally, what data will users share? For example, will users want to “broadcast” their GPS locations to other users in real time (such as to enhance a gaming experience)? Will the app share or store movie or restaurant preferences or purchase histories with backend recommendation engines? If so, these functions will most likely “call” the APIs of backend service providers — you won’t actually have to write those functions yourself.
But, for the time being, set those backend functions aside and focus on the frontend. Just like you want to build a product with the minimal viable number of features, you may also wish to build your ﬁrst prototype using “dummy” data that’s static rather than shared. It’s much easier to ﬁne-tune the frontend if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.