Solutions for recurring problems in UX often start with tried and tested UX design patterns. Find out which ones to use and why to use them. By Luis Abreu.
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Already a member of Kodeco? Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Already a member of Kodeco? Sign in
The apps we create aren’t completely unique. For example, Uber, YouTube, and Slack solve three very distinct problems: getting from A to B, video access and creation, and communication.
Along with their differences, these widely used mobile apps also have similarities. Consider that they all face the recurring (and boring) problem that is authentication, and they do it by using the recurring solution that is the log-in form.
Solutions for recurring problems like this are known as UX design patterns. UX design patterns offer three main advantages:
UX Design patterns can be composed of smaller, more specific patterns, such as a password visibility toggle that reduces mistakes from not being able to see what you’ve already typed.
In this article, we’ll skip basics such as lists, search or log-in forms. Instead, we’ll focus on these five advanced UX design patterns for mobile app UX — speed, security, and comfort:
Each UX design pattern is described in detail below, with tips on how and when to use it, along with some real-world examples of each.
The Skeleton view makes your app feel faster.
My experience is that users are more time-sensitive than you think. Research by Google suggests even delays as small as 200ms push users away. This is why Google has invested heavily into making content appear faster with a fast web browser, and numerous other technologies such as AMP, HTTP2, and many other initiatives.
Instagram, now with 700 million users, understood very early that speed matters. To drive engagement, it made posting and other common actions in its app appear to happen instantly for the user.
Skeleton views should be used whenever network or processing speed limitations prevent your app from responding immediately to user choices.
Do not assume everyone has a fast network connection or a fast processor in their phone. At the same time, creating a skeleton view for every single view and screen is unnecessary if the view doesn’t depend on the network, or if it’s not accessed daily by most of your customers.
A skeleton view can be used to replace a launch screen. Facebook does this on its web, Android, and iOS apps. It’s the first thing you see when you launch the app.
You can also provide a skeleton view for specific items in a list, grid, or any other view. This is particularly relevant if you’re doing partial data loading, such as when you’re loading just the bytes you don’t have already cached.
Instagram loads likes for a post and a few of the post’s comments when that post is displayed in the timeline, but it only loads the full comment thread once you tap to see the details of that post. Interestingly enough, it doesn’t yet provide a skeleton view for the comment thread or timeline posts like Facebook does.
When I first started adding skeleton views to the apps I design, I had to ask myself: Which views should have a skeleton equivalent? How tall should the skeleton of a text label be? Which shade of grey should I use? How do I transition from skeleton to the loaded view? How should I animate the skeleton views?
As you likely have similar questions, I’ve included the answers in the form of a video and list of tips below.
Your browser does not support the video tag.
Some tips on creating skeletons:
Two-step authentication improves the security of user accounts.
The problem with the traditional username and password UX design pattern is that passwords aren’t changed often, they’re shared between services, and password managers are often required to handle hundreds of service-specific passwords.
Two-step works by generating a temporary One-Time Password (OTP) remotely on the server when the user starts the log in process, and sharing that temporary OTP with the user via SMS or Email. The user then types the temporary OTP, completing the log in process and causing the password to expire. See the tips below for ways to avoid the typing step.
The temporary nature of OTP and their delivery methods means that users don’t need to create or remember passwords, nor they can share them between services.
For most services, Two-Step offers a balance between security and convenience.
Two-Step is the primary authentication method for mobile apps such as WhatsApp, with 1.2 billion monthly users. Others such as Facebook, Google, Dropbox, and Apple offer Two-Step as a fallback for Two-Factor Authentication.
Without going into much detail, the drawback of Two-Step is that SMS and email, with some effort, can be compromised. Two-Factor is a stronger but harder to use alternative. Two-Factor is stronger because it doesn’t rely on SMS or email.
Instead, codes are generated locally within an app or dedicated hardware as the second factor, the first being the username or email. This makes it harder to access the OTP for both attacker and user.
The bottom line is this: While not perfect, Two-Step is an improvement over username and password authentication. Most users will make the claim “as a user, I don’t want to install an app so I can register or log in to my account” — despite what you may have read in other (fantasy) user stories.
Also note: as Two-Step requires an SMS or Email sender, you may have to weight OTP distribution costs based on how many users you’ve got.
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Already a member of Kodeco? Sign in
