5 crucial findings from usability testing: Empower your design process
So, what is usability testing exactly and why should every product have at least one?
As UX designers, our work is to know the best UX practices. We need to predict and understand what is easy for the users to use, and what isn’t.
Although our knowledge can be really vast and extensive, we have to understand that we are not our users. We don’t know how they are going to react.
Since we are deeply involved in the design process, we can’t exactly evaluate whether a part of the product will be easy to use or not.
Except if you’re a genius designer. But they also need to use the usability data to be successful. That’s why it’s incredibly important to test our product before we even build it. Enters usability testing.
“Usability testing is a method which tests how easy-to-use a product is by testing it with participants.”
We are using usability testing to find out what are the biggest pain points in the design, and we do this with a set of tasks we give to the users. It’s crucial for users not to feel as if we’re testing them because usability testing can look like a test.
So, the first step is to explain to them that we are testing the product, not the user. And every problem that they find only helps us to make the product better.
While designing, we actually do get a good picture of what functionalities can be more difficult to use than the others. Usability testing is the perfect way to test those hypotheses.
Just a side note: We actually write down those hypotheses at the beginning of the testing.
The great thing is that we can find around 80% of the pain points in our product with only 5 users! It’s recommended that we make our design changes after that and test again with 5 new users. We can go on like that as long as the budget and time allow us.
Also, we need to be careful who we are testing. It’s better to not do usability testing than to do it with the wrong audience. For example, if your persona is a senior user, be sure you test your products with senior users.
How we started doing Usability testing
We studied the literature and tutorials about usability testing and completed one course, but weren’t too happy with it.
In the end, we learned that everything we need we already have on our well-known Nielsen Norman Group page. So, we read everything that they wrote, watched all their videos, and decided to give it a shot.
The first usability testing was just a practice to see how it goes and we made it with a couple of our friends. The app we were testing was a tourist app, so our persona was a more general one. We didn’t have any specific guidelines, so we just wrote down tasks and checked them with users.
It was very interesting and we did find some pain points. But once we learned more about usability testing and how it should be done, we recognized some of the mistakes we’ve made. Thus, the second testing was much better, with much more insights.
The biggest error we did on our first testing was giving users more instructions than we should have.
By doing that, we manipulated them in some way to think something they may not have thought of initially.
So what we learned was to be involved as little as possible, because we can’t be beside every user that’s going to use our product (or any other, for that matter).
We also found three templates for usability testing:
- one with the script we need for our test with potential users,
- one for the report, where we write our findings,
- one for giving feedback to the facilitator (the person who conducted the testing)
It saved us a lot of time and trouble. You too can access these templates for usability testing, and we can just say – thank you so much Slava Shestopalov! We modified these templates a bit to better reflect our needs, but the changes we made were minimal.
The example we used for usability testing
The usability testing of the product we will reflect on is – a mobile application called Growing. Growing is an app for the development of children from birth to their 3rd birthday. It includes a journal, data entry, relevant articles about children’s development, and a support section for parents.
Although some things we’ll mention are well known, there is always that wishful thinking that something is going to work if we put it in the app.
And it’s actually great to know at the beginning that we’re going to do usability testing, so we can create some functionalities and keep in mind that we’ll check later if they work or not.
The first hypothesis was that the users will be confused about what is the difference between journal and informative data. And if they don’t know at once, they likely won’t try to find out and they’ll be left confused.
Spoiler alert: our hypothesis was good, but more on that later.
The second hypothesis is that the Timeline functionality is something users are gonna use the most. For that reason, we put extra focus on it and more tasks were about that functionality.
We did usability testing after the design proposal due to the conclusion that it is the cheapest in that phase. The type of usability testing we did was remote moderated usability testing, which means we talked with users remotely with Google Meet. Users shared their screen on mobile phones with opened Figma prototype.
After usability testing, we made 10 changes, some of them were small changes, while some changes affected how we view the entire app.
Finding #1: Visual difference is not enough for users – differentiate elements with labels
As designers, we spend hours and hours ideating, designing, and prototyping the final product. We know the core of the problem and have the ideas to solve it.
But sometimes, something so obvious to us designers isn’t so clear for first-time users. Speaking of the Growing app – after Discovery workshops, we realized that Timeline would be the most important thing in the app and the most difficult one. Naturally, it was crucial to do that functionality right.
Timeline is the part in the app where parents can find all information about the child: data, articles, journal entries, memories.
We put data on the left side and the rest of the information on the right. We made three styles of cards; one for articles, one for journal entries, and the last one for memory. Finally, we told ourselves that would be enough to differentiate it.
In testing, we create tasks where users have to open the Timeline and tell us what they see. The first user understood its purpose alright, but couldn’t understand what is on the right side of the timeline.
Then we asked the user to open “memory” and she just couldn’t find it. She opened memory before in the Usability testing, in the Home screen, so she was actually familiar with the functionality, but still couldn’t find it.
The same thing happened with the next two users with whom we tested the app. We had two more users and decided to make changes before we tested the app with them.
The solution was simple – we just added labels above the title. Finally, we told the last 2 users to find “memory” on Timeline. They simply read the label “memory” and opened it!
So even though we know that our users don’t always read the text in apps, short noticeable labels will always be visible and show users which is which, more than visually different styles.
Users did see eventually that there is a visual difference but still didn’t know what that meant.
Finding #2: No functionality at all is what users need sometimes
“Less is more” – how often did you hear this quote, roll your eyes, and think: “Yeah, right”?
But in design, this quote is often the most precious practice you can follow. One of our design principles: KISS (Keep it simple, stupid) says that minimalism is the key to the user’s understanding.
Facilitate the user experience, make it faster, and without too much thinking. The goal is to get the maximum impact with the minimum content. The more we complicate, the more we risk making the whole process unclear to the user.
Filtering can be found complicated even in cases where we tried to make it as simple as possible. Our articles will have tags and users can filter those tags. What we wanted in that filtering functionality is for the users to be able to exclude tags.
For example, if a mother doesn’t breastfeed, she probably wants to exclude articles about breastfeeding since she doesn’t need it. We talked a lot about it, and in the end, we made a screen where we had a checkbox for choosing tags. And on the right, there was a button – Exclude. Two actions on one option.
Problem was that users thought both actions meant the same. So, when we asked the first user to exclude one tag, she did both actions. She clicked on the checkbox and then clicked on Exclude. We didn’t have much luck with other users as well.
We even had short instructions on the top of the screen, but not one of the users actually read it (more on that in Finding #5). Also, we asked one user to read the instructions, and she still didn’t know how to use functionality.
We’ve come to a conclusion that functionality, as much as welcome it may be, doesn’t really make sense if the users can’t use it.
Complicating filtering with the Exclude button prevented users to use filter functionality altogether. So, the logical solution was to remove the Exclude action and have only the usual filtering options.
Finding #3: Meet the user’s expectations anywhere you can
…or how we figured out how to boost our app usability.
If you are using Facebook Messenger, then you know that clicking on the user image inside the message gives you additional options (Voice Call, Video Chat, and View Profile).
All these functionalities can be found also by clicking on the image in the Messenger header. Clicking on the image = additional options. The user expects that practice anywhere in the Messenger, so let’s give it to her/him.
Clicking on the child’s photo initially opened the bottom sheet where the users could choose the child if they had more profiles.
If they wanted to add a new profile, they could go to Settings and find the “Add new” button easily. But when we asked users to add a new profile, all of them clicked a profile picture, expecting to find an “Add new” button there.
So, after the second user tried to do the same, we knew exactly what to do. Our app will have the “Add new“ option on both the bottom sheet and in Settings. Easy peasy (maybe not for developers, but everything for users).
Finding #4: Every functionality should have a value of its own (similar ones spark confusion)
Don Norman once said that if you have to explain what something is, or how it works, then it is not intuitive enough and makes your users think.
Don’t make the users think!
You, as a designer, should think about all functionalities you are designing and how to combine their features into one simple action. Two functionalities we have in the app are the journal entry and child’s info.
Journal entry is pretty clear, you enter whatever you want and save it. In the child’s data section, we design 2 types of data:
- numerical data
- informative data.
Numerical data is also pretty clear – here we have weight, length, and whatever numerical data parents want to add.
For informative data, we pictured something like a doctor’s visit, so that parents can add dates. But not only informative data was confusing for itself, but in users’ minds it could easily be the same thing as a journal entry. Inputs that went in both functionalities were also similar and users couldn’t tell the difference.
What we learned here is if the difference between the two functionalities is not big enough. There is no need for both of them to be there and the user will probably just go with one of them. For us, that was the journal entry and we removed informative data functionality completely.
Finding #5: Almost any text longer than 2 rows is invisible to users
No, no, we know – long texts are horrible. People don’t read them, they scan them.
They need to find things fast, and reading long texts is just the opposite. It requires concentration. We want to do whatever we can automatically.
But when users don’t see the solution for their problem that’s right in front of them, only because the text goes on for 3 rows – that’s pretty mind-blowing.
We love to use bubble info, elements that have short snippets of instructions in various parts of our apps that help users understand our functionality better.
With every copy, we are trying to be as concise as possible and have 3 rows maximum. Well, after the last usability testing, we kind of learned that our bubble info has a mission to take space from the screen… And that’s about it most of the time. Only one bubble info caught the user’s attention, one that went into only two rows and it wasn’t even in the task to find it.
The task was to find Sources for help. On the image above, you can see that the user knew immediately to go to the Support section and searched for Sources for help at the bottom of the screen. He searched through the “When it’s not okay” category, totally oblivious to the bubble info, which was below on the screen.
What we have learned here is that maybe it is better to remove bubble infos altogether because they only take up users’ space and time. That energy directs to make sure all actions are clear, and users can quickly know what to do without any instructions.
Of course, we have to be careful who the persona is. Some users will actually read all the instructions, but the invisibility power of longer texts is stronger than we thought.
Usability testing for the win!
Taking everything into consideration, we can surely say that we are richer for one meaningful experience that becomes a crucial part of our design system and business practice.
Usability testing helps us to get the best possible products for our customers and users by solving the problem they have in a simple and pragmatic way.
We hope that you learned something from our experience and find this post motivating to start your own usability testing practice. After all, isn’t the best feeling ever knowing that users enjoy every click, tap, or swipe in your creation?
Feel free to reach out to us and ensure your users enjoy every second of using your digital platform!