Feedback from user testing
To help improve your product and understand your users that need to use it better, the only way is to observe real users. Getting any feedback is really useful; the simpler the review, the more likely you are going to make it part of your processes.
There are many usability methods that can be used to evaluate interactive designs. Testing a website can be simple – getting a typical user to do a few tasks; or a more involved study – developing a formal test plan, recruiting participants representing the target audience, compiling big honkin’ - external link findings and recommendations reports. Steve Krug, the usability guru, recommends a simple do-it-yourself testing philosophy - external link:
a morning a month, that’s all. But how you approach it depends on what you are testing and the feedback you need: if you need quantitative results, like a scientific study, or more informal qualitative results, like discount usability tests, as Krug defines them.
When to test it?
Testing earlier in the design process, and regularly, is important because it is easier to make changes to a concept than a completed product. If a problem is detected too late you may not be able to fix it at all.
But the interface needn’t be finished; even concept sketches can used for testing. When the appearance is less perfect, it will also help elicit more feedback as users are often less inclined to critique something that looks like it’s finished, that a lot of work went into it. You can also test your current website or those of your competitors if you aren’t ready to test the new design yet.
Once you have a working concept, something that users can navigate – clicking on links and buttons – you can do more in-depth testing and get a better idea of how the site performs.
What to test?
The most important things to test would be the main features and functionality that the website would support. List the most important tasks users should be able to do when using your site – then turn those into scenarios.
A great technique that uncovers more realistic tasks is called interview-based tasks, championed by Jared Spool and the team at UIE - external link. Instead of assigning tasks to test participants, they are interviewed before the test starts. Participants then design tasks based on their interests and experience, engaging them more in the test. UIE’s Usability Tools Podcast on this technique - external link is worth listening to.
Common usability issues
Some of the common usability issues that we come across:
As defined by Jacob Nielsen in his book Eyetracking Web Usability - external link, miscues are distracting elements, something that draws the user’s attention at the wrong time. Nielsen says a miscue
occurs when the user starts out doing something wrong, but then recovers and gets back on the right track.
On the Web we need clear affordances for good usability, clarity about what is clickable – a button must look like a button.
The term affordance was first introduced by the psychologist J. J. Gibson, but Donald Norman put forward the concept to the HCI and design community in his book The Design of Everyday Things - external link. Norman describes affordance as
the perceived properties of the thing...that determine just how the thing could possibly be used, like a chair affords sitting, knobs are for turning, slots for putting things into.
A current Web trend is Flat design; user interfaces that seem simpler and cleaner with no more distractions by aesthetic elements - external link. But
flat equals less information as Jessica Enders highlights in her article on A List Apart – Flat UI and Forms - external link, which reduces affordances and therefore less usable.
Norman now advises us to forget affordances - external link:
what people need, and what design must provide, are signifiers. He defines a signifier as
some sort of indicator, some signal in the physical or social world that can be interpreted meaningfully.
Weak information scent
Not providing enough clues to users as what to do next, making important things stand out, what Krug refers to as failure to shout, causes serious usability problems. When interfaces don’t provide clear information on what information is needed or what is required, mistakes are easy to make.