Incorporate research into your next iterative design project

If you read this blog often, you’ll probably have heard the term Lean UX thrown around and already understand what iterative design is. Lean UX is a methodology that encourages a culture of innovation by empowering people to experiment without fear of failure. In simple terms, this means working on projects iteratively, in sprint cycles which include both design and testing.  Working in this way allows the early testing of assumptions which in the long term saves time, money, energy, fraying tempers and so on.  

Whilst this sounds great in principle, I often get asked how it works in reality. How do you actually do it?  How do you manage to fit research into those tight sprint timeframes?

These are the points at which we like to include research:

  • Right at the beginning of a redesign project.
  • At the beginning of a 2-week sprint (testing what you designed in the previous sprint)
  • After the end of a 2-week sprint (testing what you’ve just designed)
  • During development (testing something which is being built)
  • When a site launches (testing something which is in front of real users already)

What kind of research lends itself well to this?

There are plenty of useful ways to conduct user testing these days - it goes far beyond the traditional lab-based interview format although as a baseline, you must start with actual users - after all, if you don’t include users, it’s not UX!

Self-moderated user testing

Self-moderated user testing with tools like What Users Do and UserZoom lends itself well to iterative design projects because it can be turned around quickly, using existing panels. If deadlines are tight, this is the one for you.

Remote moderated user testing

Ahh, our favourite topic and something we use on almost all of our projects here. Remote moderated user testing is typically better suited to this style of project than face to face moderated testing. It’s faster to recruit participants to do something from the comfort of their home or office than to get them to trek into town on a weekday. It’s a great balance between lab-based (where a moderator can respond to users and probe) and self-moderated remote testing.

Guerilla user testing

If you’re on a tight budget and do not need to target a specific type of participant, this type of research can work well. My advice - pitch up at your local coffee shop and bribe fellow customers to answer a few questions in return for cake. Pro-tip: Independents tend to be more amenable to this than Starbucks!

So that’s an overview of the best ways to user test on tight deadlines but as I alluded above, it’s not the only way to go. Depending on where you are in your iterative project, incorporating quantitative testing can offer excellent insights into what is and isn’t working with your design.

Why not also try:

  • Tree testing
  • First click testing
  • On existing sites, linking to a feature which doesn’t exist and tracking clicks and user responses
  • Putting up a landing page under a fake name for a new product or service, tracking user responses with analytics and tools like Hotjar.

What’s the point though?

So there are plenty of ways to perform research at pace, using the results immediately to define and shape designs as you go. In more traditional UX circles, there are people who aren’t comfortable with this but personally, I believe it’s the only way to work, It’s our place as UXers to adapt to testing within an iterative design project for everyone’s benefit. Yours, the clients, the users.

Or, we could go back to the old ways - building something at great cost, on untested assumptions and then launching it only to discover that actually, there’s no market for it and people can’t use the bloody thing.  Working research into the iterative process negates these risks completely.

I say that with confidence. We’ve done all of our projects this way for the last 3 years and you know what? It gets results.

So be brave and tell your client or key stakeholder that, “Actually, you know what? We’re running the next project this way”. You can do it!