The Northern User Experience meets up in Newcastle every couple of months to talk about everything about user experience.
This month was about user testing.
Jamie Campbell - UX Designer at Newcastle University
Jamie talked about the who, what, why, where, when and how of user testing.
Who - identify a varied selection of participants to cover things like abilities, different technologies or ways of working, language.
What - type of test which could be paper or digital prototypes, working systems, a/b testing.
Why - to validate or disprove by testing with real users. So we get close to who we are designing for and to keep users in mind at every step.
Design isn’t finished until someone is using it.
Where - testing can be done in a lab setting in the office or in other locations.
Jamie has had much success testing with students in popup sessions on fresher days as well as gorilla testing in coffee shops by offering coffee vouchers for 10 minutes of someones time. This enabled him to better target his audience and get quick feedback.
How - these steps help organise a testing session.
- Before - meet the participant, explain the process, make them feel relaxed, sign consent forms (disclosure, recording permission, etc), start recording, reassure them
- During - ask them to think aloud, do easy scenarios first to ease them in, time the tasks, note the best bits (so you can find them in the video), keep quiet, don't help (you can lead them, so let them fail to identify problems).
- After - thank them, ask about things that were not clear, sort reward/payment.
- Review - think about your assumptions - which were right or wrong, find new ideas and questions.
- Share findings - quotes from participant, time on task (expected or otherwise), success rates, show the video to stakeholders.
- Prioritise the Backlog - score priority with business need vs user need
Tom Devlin from Userlab
Tom talked about running a user usability testing session.
There are two type of usability testing
- formative which works with prototypes and answers questions on how/why and is typically carried out in the discovery or alpha phases.
- qualitative which is used later and answers questions on the how many and is carried out in the beta or live phases.
Like Jamie, he discussed types of tests such as pop up research which are easy to setup, goes where the users are and have shorted research sessions. Field usability testing which observes users in their natural environment and uses their own equipment to remove device bias. And lab studies which are controlled and scripted.
Do's and Don'ts
- Do your homework - read peer work
- Don’t test without a clear plan. Figure what we need to learn and the questions to be answered
- Do test early and often - design by assumption is a trap which lures you in slowly
- Don’t use Lorum Ipsum or similar as it can confuse people, use real content
- Do review designs using usability and accessibility conventions and design standards which can identify potential issues before testing
- Do a pilot test to fine tune or ditch bad tests and to check duration
- Do include your team in creating and running tests so they understand what is going on
- Don’t talk too much
- Do let your testers use their own devices
- Don't ask people if they like your product - this can skew the results. Ask non-leading questions such as how did you find the task? not what did you like/dislike?
- Don’t just do usability testing - use a mix of data such as analytics and surveys
I think user or usability testing would be big benefit for the software we develop at work. Currently we rely on feedback which comes in the form of incidents from Service Desk, analytics or trickle in from elsewhere such clients own user testing. But a lot of what we design comes from gut instinct or assumptions with no data.
We have had some some success with analytics in some software, but backing up what we develop with usability testing would help make sure the changes we make are fit for purpose or can confirm what the data is telling us.
We could start small with some user testing with users in the business to identify bottle necks in process or perhaps recruit users internally for trying our user testing to validate prototypes or parts where we have identified problems.