Earlier in the year I had the good fortune of presenting to a class from the University of Technology, Sydney’s Interaction Design course. As someone who occasionally hires designers, experience in user testing and a sincere integration of users in the design process is what makes candidates stand out. Why? Because this is what reduces errors, minimizes IT and build change requests and helps ensure users can understand and use our products. It’s a mistake to think something has to be detailed and almost production-ready to be tested. Test ideas, test sketches, test digital, test services. Test early, iteratively and often.
As a student I worked in retail. I was expected to invite conversation with open questions. It’s harder that it sounds. Years later when being trained in user research I was encouraged to ask why. Not only why, but as many whys as I could … and you know why … to get to the root cause, that deep fundamental driver of behaviour. Of course this too is not as easy as it sounds. Unless you’re a charming 5 year old asking why can sound pretty obnoxious and being asked why can make anyone feel quite defensive. I’m guessing advice like this has its roots in the famous 5 Whys, which I take to be a tool of analysis, not a script. If you disagree with anything here, or have more to add please say so in the comments.
And if you are looking for more in depth information on conversation for design research read Ethnography for Marketers.
I recently finished a project where I conducted user testing to validate the effectiveness of a navigation menu. The project was a collaboration with the client’s project team who were responsible for the prototype and the recruitment. Everyone was confident going in to the user testing on the IA scheme but were open to changes. This may seem a mute point—why do testing if you are not going to change anything? Strangely I have seen people be highly selective of what they wanted to have proven in testing. Luckily this project featured no such hubris and everyone was respectful of the problems encountered by the users.
Elsewhere in the organisation other stakeholders held competing and contrasting views of what needed to be designed in the schema and what labels needed to be used. User testing the IA was seen as a means to streamline and manage the internal decision making process by bringing everyone together on the same page and letting users themselves determine the outcome.
The project was a simple engagement but an important one in an organisation that is seeking to embed UCD and customer centric thinking. The client team invited their colleagues to witness proceedings. Luckily during the testing itself I completely forgot that up to 17 people were watching me! time was scheduled in between the user testing sessions to debrief. I collected the thoughts of the observers; their impressions, implications and design ideas. The debriefing sessions were important. Not only did I benefit from the input of subject matter experts, but members of the organisation got to see the process itself. I was able to field questions about the method, diffuse doubts on the spot and collectively we arrived towards the findings. When it came to the presentation of the recommendations there were few surprises and high engagement.
The testing was not about flogging a dead horse to validate how much something did or didn’t work. Sufficient time was left between sessions for important changes to be made and tested. Stakeholders learnt by observing the process that user testing is not a research exercise. It is a design process. One that is more effective, more pertinent and faster than design by committee.