Having worked at 3 different User-Centred Design (UCD) consultancies in the last few years (Flow Interactive, Amberlight, and Oyster Partners), I can confidently say that the type of project most commonly requested by clients looks like this:
- Client delivers test materials (e.g. prototype of new website)
- 8-12 user test sessions are carried out by the UCD consultant (the client may watch a small number)
- UCD consultant locks him/herself in a room, analyzes data and writes a report
- Report is delivered in a debrief presentation to the client
- Project ends, UCD consultant leaves and doesn’t get spoken to again for weeks or months.
It suddenly stuck me today how un-user-centred this method actually is. Sure, you get a cheaper project with a good number of users, but ultimately the consultant just throws their findings over the wall and hopes that their client catches them.
The amount of times I’ve seen a UCD consultant looking at the finished implementation months later, saying something like “Oh man! Didn’t those guys listen to the presentation?”
The problem is, the client stakeholders simply aren’t very engaged in this kind of project. Watching a few sessions just doesn’t cut it. Have you ever tried watching a series of user testing sessions? From a darkened room behind a 2-way mirror? The passiveness and repetitiveness can really send you off to sleep.
So how do you get the client stakeholders involved? The solution I’ve been using recently at Flow Interactive is Rapid Iterative User Testing. Put simply, you run design workshops between the test sessions. You talk to the client, you analyze the findings together and then, most importantly, as a group you tweak the design of the thing you’re testing. (Often the prototypes we test are UI mock-ups, so tweaking is a cinch).
Not only does it involve everyone and keep them interested during the test sessions, but it means that you get to make sure your design recommendations actually work in practice.
The main problem with this method is that it can cost more. More client stakeholders need to turn up, and the sessions may need to be spread over more days. But it hugely improves the output of the project. Instead of a report detailing the prototype’s failures, the final prototype that emerges from the testing is a living, tested implementation of your design recommendations.
Try it!
Good post :) although I’m not sure I agree that it costs more, I think it costs less to work the way you describe. And I don’t mean from a value for money perspective, I mean literally how much it costs, total cash spent on project.
A few years ago I managed the design and development of the Design Council’s website (the previous one) with Flow providing the user testing (I think Iain Barker did the work at Flow)… Anyway we ran the project just as you’ve described. Every week we either tested the latest designs, or (alternate weeks) worked on the next iteration and ‘we’ meant designers, project manager (me), UX Consultant (Iain), software engineers and the client. And it worked a treat: better buy in, clear understand of the requirements, no last minute changes, less design foo foo, less risk etc.
Basically it massively derisked the project and so cost a lot less and the final product was much better (IMHO).
Yes, totally agree! It can be great for revitalising projects too, it provides design focus and creates an energy that you just can’t get from a debrief presentation.
Pingback: TESLA (Time Elapsed Since Labs Attended) and RMU (Range of Methods Used)- 90 Percent of Everything