One night (user testing) in Paris
A night’s stay in Paris is probably at the top of many people’s mini-break lists, but last week I visited the world’s most romantic city with a very different agenda; to take part in a one day user-testing session with a new client. Previously our design and ux team had spent two weeks working in the client’s office to devise site structure and lay down design principles. Now however I was hurtling through the Channel tunnel to try and validate our work over a series of testing sessions and design iterations, all in the space of a few hours.
“Où est le menu?”
User testing is probably the best way to move a design on from flat concepts that garner praise in the boardroom to something people would actually use in the wild, which can come as a shock when someone points out that your beautifully photoshopped page is missing a back button. Without feedback from real people all we have is our best guess, albeit a guess based on collective decades of experience.
Just a few short sessions can yield really useful insights that might otherwise be missed until designs go into development, at which point it’s far harder (and more expensive) to change. And it’s easy to do — there’s a myth that user testing is hard and costly to setup. It definitely isn’t, it just needs a bit of planning and willingness to execute.
It’s all about the prep
In the client’s office the day before the sessions we ran through the testing process. The set-up for the day was fairly simple; one team, the testers, run a series of 1–1 sessions with test candidates throughout the day, and inbetween these sessions meet with the design team to discuss findings and pin-point feedback that can be incorporated. The designers quickly work-up revised design solutions which are presented to the next set of test-candidates. This continues throughout the day with the objective that at the end the design will have quickly evolved based on actual user feedback.
A tight process is key to this type of testing session, where iterations on the design need to be fed back from the testing team to the designers and actioned in time for the next testing candidate to see. It does place some limitations; changes to the design generally need to be very small, but offers a rare opportunity to react almost instantly to a user’s feedback and then validate that decision.
Test candidates can be anyone, but better if they’re targeted to the user personas already developed in the previous sprints, in this case affluent existing customers with at least some online shopping experience. This helps to sift through feedback and know what is insight and what is just user opinion — which is very important in deciding what to change in the design.
How do you say “limited functionality” in french?
We love to user test at bb, and we have lots of ways of doing it, however for this case we had a couple of hurdles to overcome. First of all the test candidates were loyal customers of our client and were therefore French. This meant that in order to get the best out of the sessions they had to be run in French, and as none of us were proficient enough in the language, the client’s own team were in charge of running the testing and feeding back to us.
In addition in order to action the amends in time we also needed to work with the client’s own design team (who thankfully spoke better english than I did). While this had the potential to derail our findings, we actually found that the client’s team’s passion for their product helped to engage the testers more effectively and gave the team themselves a sense of ownership of the design, building on the workshops and creative sessions we’d run in the previous sprints.
Never rely on technology
The other challenge we faced was more technical. For our testing we’d chosen to use Marvel app, a rapid-prototyping tool which has the advantage of a very configurable user interface and dropbox syncing which should’ve meant changing a design was as simple as saving out of Photoshop and letting our prototype magically update itself. However being in another country meant we had to rely on the weak wi-fi connection (in the client’s office / hotel / Starbucks) left us nail-bitingly close to not updating in time for the next test session, reducing me to a nervous wreck each time the little blue ‘syncing’ symbol appeared over a file name.
Everyday is a school-day, and we’ve since looked into prototyping options that are less reliant on a solid internet connection, Axure or Pixate or even good old Keynote, although these are more time consuming to create and update. It’s sparked a lot of discussion of the creeping overlap of the roles of UX, visual design and development (would it be quicker to code a prototype?).
In the end however these are just tools, invisible to the user. The most important thing is to engage them and tease out their thoughts, because all feedback is valuable. A prototype is just the means to get it.
Putting yourself out there
For everyone involved user testing can be scary. You’re taking your assumptions and ideas and actively asking people to criticise, to say what’s wrong with them. Sometimes it’s just validating, everyone loves the design so we’re on track. Sometimes this feedback can be painful, but that makes it all the more important to go through. This fast-iteration process can be manic and squeaky-bum-inducing, but as the saying goes “move fast and break things” and actual user feedback is worth any number of polished board room presentations.
After just one night in Paris we were clear on what was working and what needed work, and even better we’d been able to test some quick-fix ideas to give us a head start. By running the sessions in the client’s own office, rather than a separate testing lab, we were able to prove to them that testing can be relatively quick and easy, and get them more deeply invested in the project, both valuable outcomes in their own right.
