This text explains the key operational elements and results from user tests, following the UCD (User-Centered Design) process.

Whether you are a product owner, project manager, UX professional or developer, you probably have one overarching goal when developing an app - ensuring that the next released version provides the best user experience and meets the needs of people using it.

There is no better way to achieve this goal than simply by running checks. After defining the user, precisely scoping and prioritizing the goals (another piece about this stage coming soon), an experienced designer will feel convinced that they’re able to design a user interface that is agreeable to use, gets the job done and is ready to be programmed. However, as we’ve observed during a number of projects, getting the users involved before one starts coding is helpful in many ways.

But first things first. How do you actually conduct user tests on an app that hasn’t been developed yet? There are four key ingredients here: test scenario, an interactive mockup, a careful examiner who conducts the tests and, last but not least, a group of recruited users.

User-Centered Design in practice

The test scenario should be very simple and precise, covering only the most important user goals within the app. It’s all about allowing people to focus on the user interface alone while having everything else given to him or her on a silver platter. In order to keep them engaged, it needs to be efficient and written in a straightforward manner.

For example, when testing a classifieds app, the goals could be set as follows:

• register your account using Facebook, set your real first name as your username and add your telephone number 001234567890, then log out.
• log in.
• add your ad - selling a women’s bicycle for 400 USD, title the ad with “pink rocket for sale”, add two previously taken photos from your photo library, enter a description saying only “I’m going to miss it so bad!”, then finish by bringing the ad online.
• log out
• log in again, enter the first ad on the list which is a blender for 20 USD and call the seller.
• you’re done!

Completing all the tasks should take the user no more than 10-15 minutes. Please note that we’re not checking any elements that are dependant on user preferences. For example, we’re not finding out whether they’re going to register using email or Facebook, we’re not finding out whether they’ll be using the search engine to find the item they want to purchase, we’re not even checking the format in which they’re inputting their telephone numbers. These elements are to be checked later using quantitative methods.

Just like that, we have the scenario. Let’s now get to work on an interactive prototype. How do we create it efficiently? Well, it takes some time to prepare a fully clickable prototype of an application, especially in the case of complex user interfaces. But of course, it is possible. Especially with the help of some parts of the user interface, included within the test scenario. Remember - the prototype’s goal here is to let you check stuff, not to encourage plenty of clicks. There are many tools that are helpful in this case. We’re currently using UXpin and InVision app for mobile apps, but there's definitely more.

So, you have the test scenario and a beautiful prototype. Now it’s the UX researcher’s role to conduct the tests with the users. The researcher needs to possess three traits: an ability to create a relaxed atmosphere during the testing process - in order to encourage people to comment on their actions and to ask questions when they feel the need, a sensitivity to their uncertainties to smoothly guide them back onto the task at hand, and an ability to ask the right questions. His or her tasks are as follows:

• prepare the testing environment,
• welcome the participants and explain the goal of the tests,
• introduce the environment,
• observe the testers and assist by answering questions in a helpful manner when needed (while making sure the testers are executing the scenario on their own, feeling taken care of at the same time),
• ask questions and make notes,
• make note of issues without drawing any conclusions at this stage.

At KISS digital, we’re recording every lab session using Morae, a dedicated software that captures the view of both the participant and their actions on the screen of either a smartphone (in the case of mobile apps) or a computer (in the case of web interfaces). This way, the researcher can focus more on observing and assisting, rather than making elaborate notes.

Now that we have a plan, tools and a person to run the tests, what is missing are the actual users. How many users should we test? What conditions should they meet? Where to recruit them? How to encourage them to take part? What else is important?

When conducting qualitative research such as this one, the number of users per test scenario varies between 3-12 people depending on the scenario and type of application. In the case of business apps, the number of participating users is usually smaller as they already have an understanding of the tasks they’re being asked to conduct and the tasks themselves are more specialized. In the case of more typical apps targeting a broader audience, the number should be increased. Doing so allows the discovery of bottlenecks as they tend to repeat with varying intensity.

When picking users, make sure they fit within the profile of your prospective target group in terms of literacy, psychographic features (including computer/smartphone literacy) and demographic details. It’s important to set reasonable conditions, as such qualitative research lets an experienced User Experience Specialists draw valuable conclusions.

Recruiting users can usually be done by the business owner or by the UX team. There are companies who actually specialize in finding the right users - these come in handy when you have a very specific profile that needs to be met. The process can be time consuming: gathering the potential testers’ data is one thing, while making sure they show up is another. You might end up postponing the test which results in painful delays for the whole project. Nonetheless, it should be a simple process, as long as you have it planned in advance, streamlined and organized.

You should reward your testers both with money and appreciation. The amount of money should be big enough so that they feel obliged to give you valuable feedback. Yet it should be small enough so that they don’t feel the need to overly praise the creators of the user interface. And one more thing - make sure you work with people who don’t treat user tests as a way to make some extra money, as they tend to be biased.

How to provide the best user experience ever

Drawing conclusions is a crucial part of the User-Centered Design process. Usually picking up the key bottlenecks is very easy, as long as the tests have been properly conducted. What’s more complicated is agreeing on whether an issue pointed out by one or two users is in fact a problem. In any case, it’s of course advantageous to come up with top-notch solutions to all problems right away and to treat them as starting points in the improvement phase that comes after. The conclusions should be presented and defended to any member of the team who is familiar with the test.

So we’re done. Yay! But it seems like that was quite a lot of work just to make some improvements to the interface.

Well, let’s see what we’ve actually achieved when following User-Centered Design:

• we avoided some frustrations on the user side which, if left alone, would cause negative feedback or a more general rejection of the app,
• we reassured the business owner of the quality of the user interface and let them check both the idea and the interface itself,
• there is a strong foundation for encouraging programmers to work with greater engagement as they have reason to believe that their digital creations will contribute to a greater user experience and a happy end user,
• money can be saved both by limiting the need for user support and more importantly - any redevelopment costs.

All in all, our product is going to be an essential piece of software in the hands of people wanting to take their app-making ability to the next level. After all, it's all we do on a daily basis. Want to know more?