User testing? Why?
I don’t think I have come across two web projects that have been the same, each one presented unique challenges and required a slightly different approach. In addition, two developers may each use a slightly different interpretation of a specification, two art directors will invariably come up with very different visual treatments, so even if the process is the same, the results almost certainly won’t be. At the end of the process however, the final product has to be usable.
So how can we ensure that the product is working, that it is in fact usable? The simple answer is to just ask some users. This may seem like a slightly flippant remark, but I believe it really can be that simple, especially during the early stages of the design process. There are many techniques for testing websites with users, ranging from very simple corridor or guerrilla testing, to full on usability studies. Each one is appropriate in certain situations, but not in others.
I believe some level of user input is essential during all stages of the design process. After all, most of us follow same variation of a user centered process, so rather than second guessing the users, let’s get them involved. It doesn’t have to be particularly formal or expensive. Just some simple qualitative feedback can be enough to make a real difference. It could be as simple as asking a colleague for their opinion on a wireframe or an early concept sketch. More feedback could be obtained by building a simple prototype and asking people to click through it. Again, this does not have to be a full blown usability study, a small group of people will be enough to get valuable opinions.
A more formal technique for user input is a card sorting exercise, which is usually designed to create a taxonomy for content on a website and by extension a navigation schema. Again, there are a variety of approaches, depending on whether a taxonomy exists already or not. If there is a current taxonomy, a reverse card sort or navigation test will deliver valuable insights into the validity of the taxonomy and whether it is still suitable. This could be performed on a prototype of the navigation or on a simple paper prototype, which could take the form of index cards labelled with the taxonomy items, which the test candidate is then asked to ‘navigate’ through. If no taxonomy exists, a closed card sort can quickly reveal how users would group content items into predetermined groups. An open card sort allows the user to determine the group headings, but this may be problematic during the early stages of the design process.
The benefits of testing early on should be clear, the more we involve users, the more likely we are to address their needs and concerns early on in the process, thus laying stable foundations for the remainder of the project. That said, there is no substitute for more testing later on. As the visual design starts to mature and the first components are developed, it should be straightforward to build accurate visual prototypes. These can be a simple as static images with clickable hotspots produced in, dare I say it, Powerpoint or they can be more involved Flash or HTML prototypes. As with all testing, simple qualitative feedback is more valuable than not testing at all, so again, simple corridor tests are better than second guessing.
Ideally, a formal usability study of the finished product should be undertaken before launch, but it tends to be one of the first things to get cut from the timelines as they approach crunch time. That is another matter for another post though…