Learning through making

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.

Design research #3: Don’t ask why

While I was a student  I worked in retail. At one store we were encouraged (forgive me if you hate sales assistants) to ask open questions to invite conversation. It’s harder that it sounds. Years later while being trained in user research we were encouraged to ask why. Not only why, but as many whys as we 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.

User testing IA for stakeholder buy-in

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.