London’s Design Museum has selected the new GOV.UK website as the overall winner of its Designs of the Year 2013. See what you think.
Quote of the month
‘Yes, it looks more like an expired domain page than an integrated central location for government services… Then again, it’s a little like the DMV [Department of Motor Vehicles]: you’re not going to spend any more time there than you have to. Wham, bam, thank you for registering your vehicle with us, ma’am.’
Welcome to our May 2013 newsletter: Designing websites with users
Because we are working on creating some new websites, we thought we’d share our thoughts about why it’s important to involve users right through the process, and how you might do that.
With website usability testing, people who represent your intended audience work through a set of tasks on your website.
For example, you might enlist a group of sugarcane farmers to test a website that calculates potential sugar yield.
You’re not looking for feedback on the look and feel of the website. The aim is to observe people using the website so that you can discover errors or areas where they struggle or fail to complete an assigned task.
In general, you want to get a measure of how easily people complete their tasks.
When planning a usability test, remember you will be looking for answers to these questions:
Efficiency – How much time, and how many steps, are required for people to complete basic tasks?
Accuracy – What mistakes did they make?
Recall – How much did they remember afterwards?
Emotional response – How do they feel about the tasks completed? Are they confident or confused?
The user shouldn’t need to be able to spell to be able to complete a task. Credit: Nielsen Norman Group
What to do with feedback on usability
By Robbie Mitchell
Once you’ve completed usability testing and evaluation for a website, it’s time to:
debrief the users who carried out the testing
analyse the results
recommend appropriate changes to the website
Debrief users
Discuss how the users felt the test went, and resolve any issues that arose (for example, if they couldn’t complete a task and would like to find out how to do it).
You could ask them to fill in a questionnaire to collect subjective information such as:
how they feel about the website
which aspects appeal to them
what they think should be changed
whether they would use the website again
Analyse and prioritise issues
You may end up with a long list of issues you’d like to resolve.
Gather all evaluation information you’ve collected—include market research, your own and your team’s feedback, as well as the user questionnaires.
Prioritise the issues, from critical to less important or unnecessary. This will allow your web developer to work through the issues systematically, saving time and money.
Report results and make recommendations
If you are carrying out testing for a client, it’s important to report your findings and recommendations.
Tell your client the:
purpose of testing
process used for testing
results of testing
prioritised list of changes
recommendations on which changes to make and further testing required
Keep it [cognitively] simple
By Sarah Cole
If you’ve ever created a website or an app, you will understand your product in much more detail than your users.
And as a user, you’re probably often distracted or on the go when you’re visiting a website or trying out an app for the first time; so the simpler they are the better.
A couple of ways we can simplify the user’s experience are by minimising the number of steps needed to complete a task, and/or minimising the amount of time it takes to complete the task.
But David Lieb, CEO of Bump, suggests we sacrifice these flavours of simplicity for ‘cognitive simplicity’, whereby we reduce the cognitive overhead.
Reducing the cognitive overhead of a product is about cutting the number of ‘jumps’ or logical connections your brain has to make in order to understand what you’re looking at.
Lieb illustrates the concept of cognitive simplicity with these examples:
QR codes: They’re fast and common, but cognitively complex. A novice user might think: ‘A QR code is a barcode? No? A website? Ok. But I open websites with my browser, not my camera. I need to take a picture of it? With an app? Which app?’
Shazam: An app that ‘hears’ what song is playing on your phone and, magically, tells you what it is. Shazam does a phenomenal job keeping the user’s cognitive burden low. They could have made the flow faster or required fewer taps, but it would have come at the cost of cognitive simplicity.
How to reduce cognitive overhead
David Lieb suggests 3 ways:
Don’t be afraid to get the user to do something, rather than being a bystander. More automation is not always best.
Give real-time feedback, like a magician leading an audience through the steps of an illusion. The user should never have to wonder if the product worked.
I’m a less-is-more kind of person in lots of ways so I love the idea of a website where every piece of content earns its keep or gets removed (unpublished?).
Sometimes, when you’re designing a website from scratch you’ll find an endless supply of sort-of-relevant content and a philosophy of ‘well, it can’t do any harm to publish it’.
I think it can do harm, by obscuring the critical information and by adding to the ‘cognitive overhead’, as described by Sarah elsewhere in this edition.
The desire, almost a compulsion, to publish everything somewhere, to make it ‘accessible’, is probably related to the ease of publishing material digitally.
But accessible to whom? And for what reason?
The website I’m working on now is a portal about bioenergy for people in Australia’s primary industries—agriculture, fishing and forestry.
From a survey and a bunch of in-depth interviews we conducted, we have good information about who the users will be and what they will want to know.
We’ve got:
farmers/foresters interested in supplying material (biomass) that can be turned into bioenergy
regional developers who want to create jobs through, perhaps, setting up a bioenergy plant
government people who are interested in what is happening in the industry
To make sure we are giving them the information that they want, we’ve recruited a small ‘user reference group’ with 6 members.
Their job is to tell us what tasks they expect to be able to complete on the website. They will also review prototypes and help us with usability testing before we go live.
There’s a vast amount of content out there. So the trick will be to select only content that helps a user complete a task.
Will we have the focus and resolve to do so? I’ll be doing my best.
