Intro

Welcome back to Really old UX research! Today, we are finally finishing Designing for Usability: Key Principles and What Designers Think. This foundational paper by Gould & Lewis turned out to be dense with content, thus this is indeed the third blog post of mine dedicated to this paper. Here are part 1 and part 2. Now, the last part of the paper is a small case study elaborating the theoretical content of the preceding paragraphs and our topic of today.

The case study

It’s the early eighties, so it should not come as much of a surprise that the medium used is a touch-tone phone and the company bankrolling it is IBM.

Point of the whole endeavour is to create a system for office professionals to send messages to each other, called ASD. They do indeed achieve this, and they are no major plot twists in the rest of the story. So I am going to end this summary here and bring up details along the next paragraphs where I note the two aspects most interesting to me.

The interesting bits

Surprisingly vast changes

Out of the whole case study, the learning that stood out to me most was how ready the dev team was to carry out really, really fundamental changes to the whole product at any point in the process:

• Initially, they envisioned the system mostly as a thing to do dictation (which would be then transcribed and read). Sounds cool, however it turned out that almost no one used this. Instead, people loved just recording spoken messages. So, they pivoted the whole focus of the product.
• At a later point, they devised a changeable table binding keys to actions for tests - which turned out to be such a neat idea that they just integrated this table-based config into the stack of the final software.

Look at this - they weren’t kidding when they said that your process and prototype must allow changes! Radically modifying the software stack in the process is maybe not so shocking in today’s Agile world, but changing the modality of the product from written text to spoken audio is…wild. I feel like many of today’s teams may lack this kind of readiness for fundamental changes, especially when their job title has UI/UX in it.

Pragmatic testing

When I read the paper’s earlier paragraph about quantifying behavioral goals, I kind of imagined a very strict, stringent testing philosophy to be applied. On the contrary, the design team pragmatically picked whatever test felt appropriate for what they were currently trying to measure - new feature, new reading material, whatever. All the following methods are mentioned:

• having users write down their actions for a given intention on paper
• having users type on a keypad
• video-taping usage
• memorization/recall studies
• psychological studies on impression formation
• lab tests of audio quality
• …and more

I like this! Do what works for what you want to know. It reminds of advice often given in recent literature like Don’t Make Me Think and Traction.

Final words

As always, there is more to the paper and I would encourage you to read it.

However, for now I want to close this post with yet another great quote from the paper:

The most important lesson is the unpredictability of good design: The large number of features of the final design that were not and could not have been anticipated in the initial design

Gould & Lewis

Thanks for reading! This post is part of my series of reading and summarizing papers, mostly relating to UX. I use a casual tone because that’s the most fun to me. That means my interpretation of a given paper may be off. Or incomplete. Or plain wrong. Always think for yourself, and please, don’t cite this in an academic context. Use the original article instead. Cheers!