Usability testing has become an important part of the design process here at Brightec and is one of the most pleasing elements of UX design.
Seeing a user take steps through a new prototype and to see an idea either succeed or fall apart (hopefully not) can be both exciting and enlightening.
We tend to use usability testing at two stages of the product cycle.
First, at the initial design phase to test prototypes and initial ideas.
Second, after the release of products with live apps to build upon the MVP and add features that will help the business and product grow.
In both cases, the test process is similar although the technical setup is different.
In the early design phase, we enjoy using paper prototypes.
Paper prototypes can be used to instantly test ideas on an unsuspecting colleague or corridor passerby.
The lo-fidelity of the prototype allows room for the user’s imagination. Often testers will unknowingly contribute great ideas and show-up obvious flaws.
The next stage is the digital wireframe stage.
This is a tricky stage to test and has potential pitfalls. This excellent talk explores the digital wireframe stage:
Whereas the paper prototype is very definitely not an app or website, the digital wireframes can be seen as final interactive designs. Users and clients might wonder why they’re so bland, dysfunctional and uninspiring.
Taking that into account I tend to only test these prototypes on participants that might be a bit more tech savvy or familiar with wire-framing.
The next stage is the full interactive prototype based on the final design.
For this, I use the Invision app for both websites and apps.
Invision is simple enough to make quick changes but complex enough to give a strong idea of functionality, screen transitions and the flow of the app or site.
In order to share insights with developers and other designers, I use Quicktime to record the screen, clicks and the user’s voice / reactions.
For live apps, the setup is a little more complicated. The developers sit in a separate meeting room with two screens set up.
One screen shows the user’s face from a Google Hangout or Skype call. The second screen is a Chromecast or Airplay of the user’s device.
This allows the developers a chance to see the product in use with real-time loading and transitions.
If need be, the full session can then be recorded using software such as Camtasia. However, when we only need the recording for a quick future reference, we often use lookback as an easy way of recording the screen and the user on iOS (for Android you cannot use lookback at the same time as casting).
A quick and easy recording solution Lookback.io can be helpful as a reference point.
Download the scripts, instructions and consent forms.
The users need to sign an NDA in some instances and a form giving consent to be filmed / recorded.
Steve Krug also provides a testing script to be read out. This can feel somewhat formal but users have fed back that the formality actually put them at ease and made the task at hand more structured and easier to follow.
I start the test as per Steve Krug’s instructions with the home page tour. Asking the user to tell me what they think of the homepage and ask what they might be able to do here.
For apps, I carry this over through many screens and try a gauge a certain ‘gut reaction’ for each one.
Following the initial reaction I ask the user to carry out five or so different tasks designed to test the main functionality of the product.
Steve Krug's document Things a therapist would say is particularly useful for keeping the test as neutral as possible.
Maintaining silence as often as possible is also fruitful as it gives the user space and encouragement to vocalise their thinking.
To wrap up I ask the user for any further thoughts and ask if there was anything they expected to see but didn’t or would like to see in the app.
The final stage, when the test is formally over, can be particularly helpful.
As users become more relaxed they might wish to share more critical insights or opinions on the market as a whole so keep ears open until they’ve had a chance to say all they wanted and have left the room.
A useful checklist
For the live app tests, Steve Krug has a checklist called Instructions for Observers that the developers and other designers can use.
It is important to heed Krug’s advice and stick to a few important points rather than many small issues so the follow-up meeting and iterations is focused and constructive.
This article was originally written for Brightec by Ed Jenkins
Search over 200 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!