During the creation of mobile and web apps, the biggest focus needs to be the user. Our product can be stunning, but if the user is unable to even register into it, it becomes useless. The critical phase of app development is therefore the so-called usability testing. In other words testing of how easy or difficult it is to use it. But do you know when to include it and whether to pick the fast or the slow alternative?
The User Is Behind All
During the design phase of a digital product, we are trying to build on the knowledge of its users as much as possible. We are trying to find out the most about the user. From our client or through research directly from the users.
When we get to know the user well, we can create a product that will have the right added value. And a product that the user can appreciate. We use user research in order to understand the user behaviour and their problems and needs.
If we simplify, at the moment when we know what the product should include and what the priorities are regarding its functionalities, we can create a prototype. That is a functional, clickable black and white design (wireframe). Thanks to this, the client and user can get an idea not only about how the final product will look, but mostly about how it will work.
What Is Usability Testing For?
Not even professional designers with extended experience cannot predict flawlessly how the given target group will view the product and how they will use it. That is why we must never forget to test it. The best time for this test is even before the designers draw up its final version.
So, what is usability testing basically? A way we use to be able to validate the result of our work on real users. It does happen in laboratory conditions, but in real situations. It gives us the opportunity to meet many different people. Hater who liked nothing about the application, but had not a single issue with using it. A modest quiet user who can give you an idea for two new versions of the app out of nowhere. Or a chatty senior who will recount the history of F1 in one sitting.
Good Preparation Is the Key
Apart from the prototype, it is necessary to secure the screener, test scenario and - obviously - respondents.
The screener is basically a set of requirements based on which we can select the appropriate respondents. These are the basic demographics of the target group. Or their experience with the topic, awareness of the competition and so on. It can be for example a 30 to 35 years old mother on maternity leave from the close surroundings of Prague that is shopping online for groceries with different providers due to lack of time. We are trying to specify the user as much as possible, but at the same time, we remain aware that the more precise the requirements are, the harder it becomes to find such respondents.
The test scenario includes the individual tasks that the respondents need to perform during the usability testing. We focus on the most important parts of the product. It is not necessary to test everything. That would be demanding for the host, respondent and the client’s wallet. A typical task during testing an online grocery shopping app could be: your husband invited neighbors for a grill party and you know about them that they do not eat meat and you want to prepare a great feast. How will you go about shopping groceries?
We are testing 5 respondents and we have an hour reserved for each. Using this number of respondents, we are able to pinpoint the main flaws. With a higher number of respondents, the findings tend to repeat and therefore it is not necessary to invest further time and money.
It Is Not About User Research
The usability testing itself, as the naming suggests should focus on the usability of the product. Therefore we are observing whether the users are able to perform the individual tasks and what causes issues. The goal is not to replace user research. We are not trying to find out whether users are even interested in the application or how they picture the product.
On the other hand, there are situations where there is no extensive research available and therefore we are trying to find out at least some information about the user's needs. It is however only a secondary attribute that we might not have time for in case of longer testing.
Testing In Two Different Ways
There are basically two approaches to usability testing that we use. The first one is testing the full product after finishing all the wireframes. We go through the whole product with the user, or more precisely its main parts, in one sitting and we get complex information about its usability.
The second approach is short and fast tests of selected functionalities. In this case we give the given part of the application - for example searching and filtering of products in e-shop - to users for verification. This way we validate one by one all the parts of the product that might be problematic.
During the testing of the full product, we need 5 respondents that should ideally fulfill the detail requirements of the defined screener. This method is ideal to use in case that the target group is narrow and well identified. Thanks to the findings from the testing, the product is subsequently modified and the bugs are fixed.
On the contrary, during rapid testing where we only validate selected functionalities, we split the testing into multiple parts and therefore we need more respondents. 5 people for each functionality. This approach is suitable for a wider target group because such respondents are fairly easy to find. At the same time we can validate the product fast and still during the process of creation of the product and iterate in case of need.
Another advantage is that the testing is done in early stages of the product and so even the developers can get an idea about the product and they are therefore well prepared for the project. At the same time, there is only a few minutes needed for each respondent.
However, that does not mean that the target group dictates the testing approach. It is always necessary to consider the product itself, the client and the timeline of the project.
You Can Never Be Too Careful
Usability testing is one of the most important parts of creating a digital product and we should not underestimate it. It is basically the least we can do for the product before launching it into the world. Investing a few days of work is certainly better than having your mobile or web app making a bad first impression.
In the worst case, users might not even be able to get through the welcome screen which is one of the worst things that we caught during testing. Up to 3 out of 5 respondents did not realize that they were trying to register in the log in form. They were convinced that the application is simply not working.
It does not matter whether we have an extensive user research behind us or if we use the finally designed or wireframe prototype during testing. The most important is that we test it. Most of the time, however, we are testing wireframe. Its modifications are easier than the modifications of the final design.
We can also validate the understandability of the product. During the testing of an application for searching and creating experience events, we were able to uncover that the users were not able to distinguish properly between searching and creating. During the task where they were supposed to find and filter existing events, they were trying to create their own.
Firstly, thanks to testing, we were able to save a lot of money for the client that would have needed to be spent after the release of the application on redesign and programming. Moreover, we prevented the situation that a not understandable app would reach the store. That would basically mean lost profits for each day until the fix.
Live Operation
Is usability testing more important than user research? The answer in most cases is not simple. In case you have no idea about the potential users, testing will not save you. Yes, the client often tends to want a product for all and user research is often time consuming and costly. But only in case you do not know who will use the product and if there is even a demand for it.
In case that we have an idea about the target group and we agree that we are not going to go through detailed research, we can still get at least some feedback from the respondents during testing. At the same time, the best feedback is always from the real users when the application or website is already launched and the users are using it in live operation. That way we improve our product constantly throughout the time. The launch of the tested product is not the end of app development.
Thanks to fast development and testing, we can get the product among the users as quickly as possible and after that we can look forward to authentic reviews in App Store or Google Play. Those can sometimes surprise us positively or negatively. But they are always valuable feedback.
