I love usability testing. There is something extremely rewarding and challenging about interacting with actual users who will show you what works and what doesn’t.
And so, I was very excited to hear the last talk at the Future of Webdesign, the amazing conference I participated in recently. The talk was by Dan Rubin – and it absolutely blew me away. I had never thought to approach usability testing this way, so I’m very excited to share my epiphany with you.
Dan told about a project where they had to enhance the user experience on two sites led by the same core brand. They started out by conducting a so-called inherent value test (which you can read more about on Jarod Spool’s site uie.com.
An inherent value test basically tells you what’s right and wrong about the existing site, or as Dan put it: “Discover what the users love, so you can protect it”.
In the project in question, the team used the results from the inherent value test to determine which areas to focus on in order to enhance the UX of the sites.
But that wasn’t what sparked the epiphany. It was the next step:
Testing on high fidelity prototypes
The key is to build prototypes with high fidelity design, but low fidelity code. Avoid building anything, except from links and fields.
The big advantage to this approach is that you don’t have to do any kind of cross-browser checking – the prototype will work anywhere due to it’s simple, low fidelity code structure.
And the user doesn’t see that the site isn’t fully functional or coded fully. They see a finished site with the functionality they need to complete the tasks they’re asked to do.
So how do you build a high fidelity prototype? You go task specific. This means that you only make the areas that are relevant for the tasks clickable. Everything else is a static background image.
It’s important to run the test in the browser, and to only test on one user at a time. This is crucial, because part of the key to success is to modify the prototype based on each user’s input. So each user actually tests a slightly different prototype. And you can only take this approach because the prototype is high fidelity in design, but low fidelity in code – it’s dead easy and fast to make improvements on it after each test session.
Another key issue in this type (and really any type) of usability testing is to supply the data the users are to type in during the test, e.g. name and address for a signup form. The reason for this is it will give you full control on the output – which means you can check it for accuracy and thereby see if there are usability issues with the form.
Last but not least, make sure to record both the user (both video and audio) and the screen so you’ll be able to catch anything the user might not say out loud during the test.
A final word of caution: Make sure you have a skilled test facilitator who knows how to ask the right questions, form the right user tasks and conduct the test will provide you with accurate results. This really is potentially the weak link of any usability test.
And there you go! A truly efficient way to approach usability testing. Didn’t I tell you it was an epiphany? :)
If you’re interested in watching Dan’s talk in full length you can buy a full video access to all the talks from FOWD at the FOWD website.