User Testing Process & Techniques

2 minute read

Background

There are multiple ways of carrying out user testing. The following explains the process I took in establishing user testing as a part of an organisation's design process and the method that followed.

Draft version of a recent high fidelity design

What I did

Process

1. Obtain buy-in from stakeholders

The benefits of testing had to be communicated both internally and to external stakeholders. This is a very important step to take if you are in a situation where stakeholders, whether internal (eg. product people) or external (eg. users) are unfamiliar with what it is and what it involves. Buy in and interest from both sides is allows for effective user testing.

2. Plan

Planning is a critical part of any type of design work. And user testing definitely requires good planning.

Before conducting any user testing, I meet with internal product people (product owners, those doing research, QA's etc) to identify the most critical features, interactions or products to test. We then prioritise the ones we'd expose to users.

process image

A group of us (Product Owners, Testers and I) met and identified key areas of the products to test. The product owner then prioritised the test areas.

Identify relevant user types (personas)

Different user types may use an application for different purposes, especially with enterprise products.

Take the example of a hospital setting: a receptionist would be more interested in the timetable/scheduling part of the application than on an area specific to a medical discipline. This is why its always important to ensure that the correct user types are chosen to ensure maximum value from feedback.

The number of user types will obviously vary depending on the project. At present I deal with an application that has 6 user types.

3. Test

When the test cases have been prioritised and the user types have been identified and scheduled for testing, you're ready to go.

Often its not always practical to do testing in actual environments. It is however, important to observe such places in order to get a sense of any practical issues they may contend with on a day to day basis. I do find in-person testing to be the most effective when possible - as you get to dig deep then and there with the user on any pain points they may have. They are also opportunities to get to know the user better and sometimes even design with them in paper form.

process image

We set up a screenshare where we could watch the users complete tests while being less conscious of our presence (above left). Onsite research of where the users actually work (above right) was also done in a separate session.

Before and after each test I had some particular questions I wanted to ask each user. Interviewing someone is an art in itself. I find having a light hearted and loosely structured conversation to be most effective when trying to elicit a response from users. A relaxed atmosphere enables them to open up more about specific problems or struggles they may have.

4. Adjust where necessary

A team member and I then identify patterns in usage, documented our findings and adjusted the prototypes where necessary. Sometimes it makes better sense to sketch out alternative designs with the users just after testing as a means of getting rapid feedback.

process image

Here's an example of two different layouts of the same information. A quick sketch like this allowed me to get feedback off some users when under a strict time constraint.

5. Test Again!

We then retest the areas we had question marks over in order to ensure things are on the right track. These follow up testes are usually done on a remote basis using Invision prototypes.

Below is an example of a prototype sent to a user group. Its always important to make sure the user knows what the purpose of the test is and how to engage with a prototype in order to obtain maximum feedback.

process image

An example of a prototype sent out to remote users. It was important that all users were familiar with what we were presenting them with and how they could provide feedback to us.

The iterations we have made based on feedback has varied from product to product. Sometimes it was as simple as changing the text of a button. Other times it involved us completely rethinking the layout of a module.

All in all, it's become a critical task and is now an integral part of the company's design process.

Results

What I learned