Get it right the first time

Surf club

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.’

Nathan Hurst, ‘Design of the Year award proves aesthetics aren’t everything … or anything at all’, Wired

‘Why does a straightforward, cut-and-dry website deserve the award? Because of that straightforwardness, actually.’

Kelsey Campbell-Dollaghan, GIZMODO

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.
Let us know what you think on Facebook, Twitter or email us.Regards from the @EconnectTeam:

Usability testing – what was the question?

By Robbie Mitchell

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 correctly to complete a task on a website.

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.

It works fine for me (alien web designer)

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.
  • Slow the results down. As counterintuitive as this is, experiments have shown that people perceived greater value from a slower travel search website—they saw it as working hard to retrieve all the different travel options on their behalf.

User-driven content

By Mary O’Callaghan

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?).

As Gerry McGovern says: ‘Anyone can add. It takes a professional to take away.’

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.

Wheel of contact codes

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.