Are these friction points lurking in your app?

It really doesn’t take much for someone to uninstall an app and move on to something else. Maybe the app kept crashing, or its interface wasn’t intuitive. Maybe it asked for way too much personal data.

Those are 3 examples of friction points in user experience, but there are countless other ones you may have overlooked while building your app. Let’s take a look at some of these small yet noteworthy issues—and how to fix them.

The login wall

Research shows that forcing people to sign up before allowing them to use any of an app’s features is the best way to lose the majority of your (potential) users.

Login walls require a significant interaction cost for users. Mobile apps that are highly personal, like banking apps, are justified in utilizing login walls to protect against potential intruders.

But when other apps use them, it can come off as a complete nuisance to the user. The argument that “it’s only the first time—next time users stay logged in” holds no water. There may not be a next time.

Related: 3 ways friction can actually improve your UX

People want convenience—being forced to register right from the start isn’t convenient, so really consider whether your users need to log in at all.

You can also track your login funnel to see how people are reacting to being forced to log in.

Another option: try delaying the login process by letting people experience bits and pieces of the app freely. They want to know what the app offers before signing up, and login walls prevent that.

People won’t easily give out their full name and email address, so make sure to either ask for as little data as possible, or show your users why they need to give away this data.

Lacking transparency and control with sharing

Privacy is at the very top of priorities for mobile users, and your app needs to address that with a solid privacy policy. One of the cornerstones of a solid privacy policy is giving users full control over sharing, especially on social media. They shouldn’t have to worry about your app posting to their Facebook or Twitter accounts.

So, do the following:

1. Make access to sharing settings easy and clearly visible
2. Use clear and distinct descriptions for different sharing options to avoid any and all types of confusion
3. Avoid lumping sharing settings together
4. Give users options to share on different social media platforms (some people prefer Facebook over Twitter, for example)

Deleting user queries after tapping search

Let’s say you’re trying to find a new bumper for your old-timer BMW E21. You type in “BMW E21 bumper spare parts” in an app’s search bar, and then you realize there are 2 types of bumpers: plastic and chrome.

So, you want to add “chrome” to your query, but the app deleted the original query after searching. Now you have to type in “BMW E21 chrome bumper spare parts.”

Then you realize there are different types of bumpers, depending if your car is from 1979, 1980, or 1982. Again, you’re forced to type in everything because the app deleted the original query after you tapped search.

This detail seems tiny, but it can really frustrate someone to the point that they no longer want to use your app. Keeping the original text will make searching much easier for users and hopefully carry them through your conversion funnels.

Related: These 5 major UI mistakes will kill your app

Navigating users to a dead end

Everything about your app should revolve around flow. Mobile users go from page A to page B to page C, eventually solving an issue or completing a task.

If, somewhere along the way, they stumble upon page B2 and it offers no way forward to ultimately reach that final page C, they’ve essentially reached a dead end. There must always be a way forward. So instead of dead ends, it’s a good practice to utilize empty states.

An empty state is what someone sees when the app has nothing to show. That state shouldn’t making someone say “Now what?”—instead, it should navigate them forward.

A couple of examples:

1. Let’s say your app encountered an error. Instead of simply informing the user and creating a page that says “An error occurred,” use that empty state to tell the user what to do: “An error occurred. Try refreshing the page.”
2. Music apps rarely come with music. When the user opens the app and sees no songs, no playlists, no files—that’s an empty state. A poorly designed app will only have a message like “No songs found,” while a well-designed one will have something like: “No songs found! You can import music from your library, or head over to iTunes.“
3. You’ve taken the initiative to empty a trash folder in an email app like Gmail or clean a to-do list from a task management app. Here, an “empty state” positively reinforces the act of emptying/clearing that the user has completed.

Asking for ratings too soon

I get it—app ratings are important. They’re one of the main reasons why people choose your app over your competitors. Inviting users to show support and leave a good rating and a few affirming sentences is a welcome move, but timing is crucial.

At a concert, what’s the first thing the singer asks as they take the stage? Definitely not “Are you enjoying the concert so far?” Because, obviously, the concert’s just starting.

The same idea goes for apps.

You should never:

• Ask for ratings before leaving users alone with the app long enough
• Interrupt users in the middle of their tasks

Instead:

• Choose the least intrusive moment (perhaps after completing a certain number of tasks)
• Make rating your app optional

Being too vague with in-app permission descriptions

In-app permissions that seem irrelevant—or, even worse, too intrusive—could turn your users away. You have to properly describe why your app requires certain permissions—it’ll remove the fear that exists in every user.

Only ask for things that are absolutely necessary for your app to work, and avoid asking users for that information as soon as they open your app for the first time. If there’s too much ground to cover, you can use your onboarding process to give folks more details about in-app permissions.

Hiding passwords during registration/login

A desktop/laptop experience is completely different from the mobile experience. Still, there are many little things the mobile world needlessly “inherited” from the PC universe. One of them is hiding passwords during registration and log in. It’s pointless—and it makes registering or logging in longer and harder. Always give your users the option of seeing what they typed in before submitting.

It’s funny how big of a difference such a small change can make. Without masked passwords, users make fewer errors, feel more confident, and are less likely to give up on an app.

Related: UX design tips for your app, part 1

Omitting relevant defaults in search bars

Your app’s search bars should always come preloaded with queries that are useful to each individual user. Consider this as personalization, or simply being helpful. By suggesting relevant things, you’re making your app faster and more convenient to use.

Having relevant search defaults means less effort on the user’s side. In that case, not having search defaults means users need to make additional effort when using the app.

Knowing that users will always stick to the principle of least effort, we come to the logical conclusion that the app with omitted relevant search defaults creates a weaker user experience. So, if your app doesn’t already offer relevant search defaults, make sure its next iteration does.

Keep in mind that the keyword here is relevant. Offering irrelevant search defaults will frustrate users more than not having any defaults at all. If you’re going to offer search defaults, make certain they’re relevant.  

For example, an accommodation app could use a person’s location to suggest nearby hotels, restaurants, or clubs by default. Even though this tiny feature frequently gets neglected, it’s common logic and can do wonders for your UX.

Pro tip: Assume nothing

There are many ways to track the mobile user experience, like keeping an eye on session durations, or task success rates. But the problem with the majority of these key performance indicators (KPIs) is that they can’t tell app pros why users aren’t satisfied. They can’t describe why session durations aren’t at a satisfactory level, or why certain tasks never get completed. Methods like A/B split testing are often considered a good solution to improve the numbers on the KPIs.

But that still doesn’t let you see things clearly: You may stumble upon a solution, but that’s all you’ve done—stumbled upon a solution.

This is where qualitative analytics steps up to the plate. Qualitative analytics gives you answers as to why users behave a certain way. So instead of stumbling upon a solution, app pros will be able to use cold, hard numbers and qualitative data to back up their claims. Specifically, qualitative tools like touch heatmaps and user session recordings allow app pros to pinpoint exactly where the friction in the UX is. They’ll be able to see if the login wall is exactly why people abandon the app, or how big of a difference default search queries make. Essentially, they’ll know exactly why their users behave the way they do, and that will allow them to make informed changes to their app’s UX.

The ultimate experience

It’s 2017, and mobile users are more demanding than ever. They’re difficult to onboard and almost impossible to retain. They want apps that are fast, seamless, intuitive, and personalized. If they don’t get what they’re after, they’ll ditch you for something else.

App pros, on the other hand, are impatient. They often submit to the pressures of the market, rushing to get their app out there as soon as possible. This rashness often results in apps whose UX comes with too much room for improvement, and that can frustrate a lot of users.

Pay attention to all the nuances of your app. As the saying goes, it’s the small things.

You’ll love these posts, too

• Where has the creativity gone in web (and UX) design?
• 13 impressive statistics on UX
• How to rock your app launch