Lean UX and TDD

Ten weeks ago the result of years of curiosity landed me in my first week of coding at Makers Academy. This post is about test driven development and why to apply a similar process to UX design work.

*Warning this post may cause some designers mild to severe discomfort.

Militant TDD

Makers separates itself from other coding bootcamps in that it values the ability to adapt and learn new things over deep vertical learning of one particular language or framework.

They are militant about Test Driven Development (TDD) and in the initial weeks you spend a lot of time frustrated at not being able to dive straight into coding. What’s the point of spending so long on testing frameworks, learning how to stub, mock, spy etc… It becomes a lot clearer if you try and start building features without TDD.

I’d recommend all new students to try one of the challenges without testing, just to get a taste of the infinite loop you’ll find yourself stuck in pretty fast. A couple weeks in and the familiarity of hypothesis testing between TDD and lean UX hypotheses was emerging.

The basics of lean UX are all about understanding the problem and then developing a set of hypotheses about your design work. Take a look at a lean UX hypothesis along side a unit testing expectation to see the similarities.

A lean UX hypothesis looks like this:

We believe that [ doing this / building this feature / creating this experience],
For [these people/personas],
Will achieve [this outcome],
We will know this to be true when we see [this feedback / quantitative measure / qualitative insight ].

An Rspec unit test looks like this:

it("rollFirst can hit 4 pins and pins left are 6", function(){      

The principles are all there;

  1. you set out the change you are planning on making
  2. make the change
  3. measure the resulting effect against your hypothesis

Working in design teams for a number of years I’m still yet to see teams who truly practice hypothesis driven design. More often you find teams or individual designers working in the dark without properly understanding the problem they are trying to solve or the hypothesis they are testing.

Designing in the dark

Not making conscious design decisions and testing your expectations can lead to a load of issues like:

  • Stakeholders are left in the dark about your decision process
  • You’re not quite sure when you’ve actually solved the problem and when you’re over-designing
  • It’s harder to defend your design solutions

Understanding the problem is not easy

You need a strong collaborative effort between product managers, analysts, researchers and designers to properly set a clear problem statement and formulate hypotheses. Simplicity is the goal but understanding complex problems is the means.

Maybe you’re already doing it informally, maybe you’ve never tried it but next time you hit up a design project try applying a TDD/Hypothesis driven process and see where it takes you. Lean UX is a great resource for this.

I’ll be blogging more about not designing in the dark and looking at some of the ways I try and avoid it.

Like what you read? Give Murtaza Abidi a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.