Good and Bad Practices in Mobile UX Design
by Bradley Nice, Content Manager at ClickHelp.com — software documentation tool
Mobile UX can be tricky and requires taking thousands of little things into consideration. Making a mistake here might not only confuse and slow down your users but force them to uninstall your app altogether. So I wanted to talk about some things that can’t be neglected during the app design process.
Ever wanted to be a detective? I believe most of us did at some point in our lives. And UX design provides just the opportunity for you to feel like one because you will have to do lots of research before you even start designing an app.
You need to do a comprehensive competitor analysis — check out apps that are similar to what you want to design. Take notes of which features you like, which you don’t and which you wish were there. Features you like and find user-friendly and useful you can adapt for your app; features you don’t like should be a reminder of what you need to avoid. And, finally, features that you find lacking in your competitors’ apps are the features that can make your app stand out.
And don’t forget about your target audience — after all, they are who you’re designing your app for. Research users as well. One of the simplest (stupid simple, I’d say) ways to do so is by checking competitor apps’ reviews — look at what people write about them, what they like, what they don’t, and so on. It won’t let you see the big picture, but can provide some insight.
Remember — research is your key to success. And don’t even try designing your app first, especially in its final form, no matter how much you crave it. You won’t get the perfect design on the first try, because you lack one crucial element — feedback.
There’s a very simple workflow you can follow, and it’s shown in the image above. Don’t isolate yourself while designing. Work in iterations, and after each, try and gather feedback, thus being able to notice weak spots and avoid false-consensus effect (in short: you assume that users like what you like and their behaviour is similar to yours).
Of course, you will want to include every possible feature into your design. But that’s actually a rookie’s mistake, and instead, you should focus on your main feature. No, I’m not saying you should design an app that has only one feature, but don’t either spread yourself too thin. Think about what will make your app stand out among competitors, and build your design around this core feature.
You will also want to make your app as simple and understandable as possible. Review every feature, every button, and an image you added into your design. Don’t hesitate to cut everything you think is not really necessary. The less clutter there is on a screen — the better. Also, try to avoid putting too many actions on one screen. Ideally, you’d be better off with just one main action, the rest can be moved to other screens or a menu.
Of course, there are exceptions. Sometimes you need several actions of same importance, sometimes you need something extra present on the screen, which, in other cases, should be removed. Don’t forget that it’s your design and it’s unique, and I’m not writing UX bible here — just talking about some general practices. Bear this in mind while reading 😉
Speaking about menus and navigation in general — it should be comfortable and familiar. Users, when launching your app, should feel at home. They should be able to jump into action quickly and understand navigation system without any tips from your side. But what does that really mean?
Well, first of all — don’t make custom gestures the main interaction. For some advanced features — sure. But users should not draw pentagram to summon the main menu, they are used to the main menu being accessible by swiping from left side of the screen to the right or clicking the sandwich menu button.
Another point here is to be consistent. Don’t assign different gestures to the same action on different screens and don’t change the positioning of elements, unless it’s super-necessary. You will only confuse users if on starting screen menu is on the left, but on the next — it’s at the bottom. Or if on one screen long tap copies text into the clipboard, but on the other — selects it.
You’ll want to also pay attention to info architecture. All of the info in your app should be accessible in as little taps as possible. Yes, this can be very tricky, especially if you have plenty of screens and a lot of info to provide, but that’s your task as a UX designer — to make this happen.
It’s also important to notice that your app should ideally have no dead ends. In most cases, you’ll want to support the flow, where users move only forward through your app. Is this an error screen? Adding a simple “go back” button or suggestions (in form of links/buttons) where the user can go (other screens, perhaps) will not break the flow as much as opening menu and going somewhere else. This is a pretty complicated matter, like, what’s the difference between user clicking “<” button on top of the screen and “go back” on the error page? What breaks the flow and what doesn’t? I could speak about this, but I’m no expert in UX (that’s why this article is about general practices) and describing all the nuances will take a lot of time — after all, books are written on this subject!
There are hundreds of little things you can do to improve the usability of your app, but I wanted to touch on some of them — because these mistakes are made more often than not, especially by newbie designers.
Don’t forget that you’re designing a mobile app, where physical space is very limited. Try making your elements “finger-friendly” with the minimum recommended distance of 7–10mm between them. You aren’t designing desktop app, where a certain amount of precision with the help of the mouse is present. If you make a distance between two interactive elements less than recommended, the number of occasional miscliks will increase drastically.
Okay, it’s pretty apparent what to do with interactive elements, but what about copy? After all, your app will feature text as well (unless it’s a very specific image/elements-driven app). The main thing here is to make text legible. Find a typeface that works well in different sizes and weights. And for the sake of all that’s dear to you, don’t make text small. It may look good on your 27" monitor, and you’ll be happy that you fit so much text on a single screen, but in reality that 6px font will be hardly legible on a mobile phone.
And I believe I don’t even need to speak about color contrast because it’s pretty evident? Yeah, I thought so. But nonetheless, look at this image:
Another good practice is to let your users know that they actually clicked something. I mean — provide feedback. If a user clicked a button, and nothing is happening (though in reality, your app is loading content in the background) — do you think they will patiently wait? No, they will smash that button over and over again, waiting for some kind of result. The simplest way to show users that content is being loaded is to show preloader:
But there’s a somewhat new trend going around, it’s about using thing called “Skeleton Screen”. Look at how Facebook is loading info:
It’s not loaded all at the same time, but rather in sequence. Basically, skeleton screen is essentially a wireframe of the page with placeholders instead of images and text. It’s like a page is saying to the user: “Hey, I don’t know what the contents are yet, but this is how I look”. They are believed to attract more attention and “amuse” users while they are waiting for content.
Of course, not only loading content needs feedback. Pretty much every action should make it clear for user that they performed it. Make buttons switch colors on switch, twitch or change size — anything to let users know it’s not broken and they actually clicked it.
Another thing to keep in mind is when you need info from users, basically, making them fill out forms — request only the bare minimum, because filling out tons of input fields can be tiresome and even drive users away.
Also… Don’t EVER ask for the rating on the first launch. No, seriously — DON’T. After all, they’ve just launched your app, they didn’t see all of it, they are still checking it out — and they should already provide rating/review? They’ll most likely just click “Never Ask Again” and be off with it.
Another thing you should not ask about at launch — permissions. It always drives users crazy if, when launching the app, all they see is endless “Allow access to…?” pop-ups. And it’s okay to ask for permissions, but before this — provide context. For example, if a user orders something from your shopping app, you can ask for permission to know their location so they won’t need to input their address. Or when mobile games ask you for a permission to send notifications and telling what’s that for: “Hey, I would like to send notifications so you won’t miss free gold, ok?”.
An the end of the usability section I wanted to talk about an interesting point I saw in some articles about mobile UX. Most of them suggest you don’t take users out of your app into a browser (for google/facebook auth, for example), and instead you should use an in-app browser. On one hand, it’s logical — taking the user out of app will break UX flow. And when you need your users to read something, like a help article on your website, it’s perfectly fine to use an in-app browser. But what about user input? Especially authentication with social networks— not everyone has stuff like Apple Keychain, where you can store login/password system-wide. On my Android phone, I had everything saved in Google Chrome, and I always hated in-app browsers, because I had to enter my email and password manually.
What do you think on this point? Feel free to comment.
Though this is one of the most important things in UX design, there’s not really much to talk about. In the scope of this article, at least. Don’t get me wrong — testing is a large area with its own pitfalls, and nuances, but we’re talking about general practices here.
So, yes — test your design. It’s necessary to test your design on mobile devices, otherwise how would you know how it would look and feel in an app? Test it, but don’t limit testing to yourself. Give your prototype to colleagues, friends and potential users, and test on various devices of different sizes. Only through actual use, you can understand what’s good and what’s bad about your design; you won’t get that insight from just looking at your artboard.
As I’ve already said (multiple times, I think) UX design in general and mobile UX in particular is a very complex matter, and can’t be reviewed in the scope of a single article, but nevertheless I wanted to talk about some general things that you should keep in mind while working on your design.
Have a nice day!
Bradley Nice,
Content Manager at ClickHelp.com — best online documentation tool for SaaS vendors
