The Design Of Everyday Tests

(Title Inspired By Donald Norman’s book – The Design Of Everyday Things)

I had an opportunity recently to attend  a Design Thinking workshop by David Webster of IDEO. Amongst the attendees that comprised Product Managers, Copywriters, Graphic Designers, there was me, the lone software test consultant. Most people there built, I helped design better tests to critique or break the designs faster.

Got me thinking, why testers didn’t think like designers? Didn’t they design stuff – even if it was to break stuff? Why did they have this hands-off view of design? Didn’t they want to understand how designers thought through a problem, and arrived at a solution, so that they could question the hypotheses?

So what’s bad about design thinking that are making testers stay away from it?

As David also pointed out, the fancy word for how designers think – actually encompasses a process of Design Research, Synthesis, Brainstorming & Prototyping. During the workshop I attended, in under 3 hours, we executed the four phases in teams, and every group came out with a whole host of marketable solutions for a problem that was thrown at us, proving thereby that this was no rocket science, and also took the aura off the “design” folks.

So let’s look at the first two phases and how that can easily correlate to testing.

Design Research (as explained) is where you understand who your users are, explore analogous experiences, and understand the problem by immersing yourself into it. Akin to understanding the application (or product under test) in terms of how it is used, what drives users to use it in the ways that they do, what is important to them, what are the possible weak spots – given the underlying architecture choices…

Synthesis, is the process of defining the meaning, looking for patterns, setting directions and extracting insights…. Akin to understanding the application under test in terms of looking for commonalities (to bunch tests in), using stories to create possible test scenarios (what if a user did this…), using the “How Might We..” (HMW) starter to design test approaches (e.g. How Might We be able to prove that the user credentials cannot be compromised when using the application across different devices / browsers).

To me it seemed obvious that this was an effective approach in defining a test strategy, and the sessions gave me additional clues into how designers think – so why run away from it? My suggestion would be for all testers, to go through a design thinking workshop (not a theoretical session) and I am sure that this will augment your approaches. Better still, attend these sessions not with testers alone, but with the design and development teams, and you can be the odd person out pointing out flaws in their thinking 😊