UX Academy Journey—Week 13: Why User Testing Is Everything

Thea Chard
Prototypr
Published in
6 min readJun 11, 2018

--

A/B/C? (Illustration by Andrew Wilshere).

Hey there, design reader!

Last week we were discussing how a nice break from work does wonders for your mental state (and your productivity, once you’re back at it!) Let’s pick up right where we left off — exploring how folding UX design principles back into my other work has led to accelerating returns.

Ready? Set… Let’s go!

How user testing adds value to projects

Lately I’ve been approaching my existing client work from the perspective of a seasoned UX designer (well, a newbie half-faking it and learning as I go) — and I’ve noticed that both my processes and my work deliverables have vastly improved.

My marketing copy is cleaner, leaner, and more intentional (thanks, microcopy!). Visual designs are formed deliberately around planned information architecture, rather than responding directly to an amorphous idea from the client. And final products are the result of round of feedback, revision, and improvement.

In the case of my freelance book client (the financial advisor publishing the part-memoir, part-wealth management instruction manual we discussed last week), the book, being part financial “how to” guide, is supported by a number of activities and workbook materials that supplement the text.

They give the reader a bit of at-home curriculum to work through, and apply to their own financial investment plan. As project manager, I took it upon myself to design and refine that content through a user testing process.

Ideally, user testing is part of the entire product cycle, happening cyclically within the iterative design process. Image credit: Smashing Magazine.

My client had no idea what “user testing” meant when I first suggested it. But observing just a few potential readers actually go through the financial planning tasks he’d created highlighted a number of pain points. For example, the instructions could be clearer (especially for readers unfamiliar with the financial industry), and the fiscal examples could be more realistic and relatable.

It only took a handful of tests to get these insights — they were all conducted in just one day, and at minimal cost to my client. His initial readers generously volunteered as participants, and the few hours I spent synthesizing and analyzing the data was the only additional billable item.

As a result of this process, we revised the materials, and the book will be able to reach a wider audience more effectively. And, after all, that is the overall goal of the book.

Oh, usability testing, you are a beautiful, generous goddess!

Design, Test, Repeat

While the book isn’t out yet, so I can’t share too many details about these supplemental materials, I cannot stress enough how vital user testing has been to pretty much every client project I’ve undertaken recently — not to mention my UX Academy coursework.

Just take a look at some of the results from my KAUS insurance project, which I had been working on for pretty much all of Phase 1.

My KAUS affinity map, compiled after a simple four-person user test.

I spent weeks laboring over the landing page design, futzing with the structural organization and prototype interactions, and even spending way too much time designing a custom logo animation (because, why not!). Yet, at the “end” of it all, I ran four user tests that revealed — you guessed it — some pretty obvious design flaws that I had entirely overlooked.

One irony here is that I’d put off doing my own user testing because I feared it would be difficult and labor intensive — when in fact, it turned out to be quite easy and surprisingly comprehensive. Clock that up to first-timer naiveté.

The truth is, a user test with just five participants will still uncover 85% of the issues within the tested UI. In fact, in most cases experts recommend testing more often with fewer users, rather than making more elaborate testing plans with large numbers of participants.

It hurt to see all those hours of work go into something that would ultimately change, but that is the iterative process — the whole point is that it changes, and for the better.

You can check out the current iteration of my prototype here — without the fancy animations because I couldn’t figure out (yet!) how to get InVision and Framer to play nicely together. The prototype is a work-in-progress after all, but it was improved massively by the insights gleaned from a simple round of testing.

See my full KAUS case study slide deck for more details.

The biggest lesson I learned here was not to be afraid of the user testing process — and in future projects to incorporate it earlier, and repeat it as often as possible.

3 Habits for Successful User Testing

Folding these techniques into my existing client base has catapulted my work — and the satisfaction of my clients — onward and upward. Just a few small adjustments have revolutionized the way I work, and these tweaks have naturally cut out the excruciating time suck of going round for round on a project where the client isn’t quite happy with the product, but doesn’t know quite why or how to express it.

My are my top three tips & tricks for successful user testing with clients:

  1. Define the problem first. You know that excruciating time suck mentioned above? Oftentimes getting caught in the creative doldrums, especially when working with clients and stakeholders, is directly linked to a lack of clear definition of the problem at the start of the design process. We creative types love to get lost in research rabbit holes, and wax poetic about our creative wonderings — but it’s easy to slide from wondering to wallowing, without making any real progress. I’ve found that achieving a clear problem definition as early as possible in a project can help to avoid this creative cul-de-sac entirely, and instead light up a clear path ahead.
  2. Create flexibility in the testing & implementation plan. Testing is essential. As designers, we all know that — but sometimes clients and stakeholders may not be as sold on the process. When you create a testing and implementation plan, remember to build flexibility into the proposal. Unfortunately, clients often look at cost first and results second. If you’re lucky enough to have a client who sees the value in robust testing, fantastic. If not, advocate for the process and explain its value, and present a range of testing plans that require different levels of investment. This approach should ensure that some level of testing is happening, and that you can avoid the burden of trying to design without the ability to test your work.
  3. Test early, and as often as possible. Do as I say, not as I did! I feared the user testing and put it off. But by doing that I learned the value of building in user testing to the early stages of a project. Your design process will be more lean and more effective if you can get crucial insights from users before too much time and money has gone into the project. The last thing you want is for late-in-the-game user tests to indicate that you need to completely rebuild a design that the client is already wedded to. Even worse, suggesting user testing too late in the process, after the client has already invested a lot in the solution, may strain your relationship and make it harder to keep things professional.

Before we wrap things up for this week, I’ll leave you with some resources that helped me overcome my fears about user testing:

And with that, until next week, happy designing (AND TESTING)!

Looking for a change of careers?

Designlab’s UX Academy program offers rigorous curriculum, personalized mentor support, and a thriving, global student community. Ready to launch your new career as a UX designer? Get all the details here.

Check out UX Academy

This post was originally published on the Designlab Blog. You can follow the whole series here.

Check out some of the other stuff I do!

--

--

I'm a writer, editor and designer live/working in Seattle. Designlab UX Academy student. Nat Towsen’s Downtown Variety Hour (at UCB East!) producer-at-large.