Five Things I Learned About Lean UX and Development

Agile has really done a number on me. I can’t see software development the same way anymore. Deliver value early, often, in small batches. Optimize for the flow of feature delivery, not utilization of a person.

Now I’ve had the chance to engage with a complimentary methodology: lean (or “lean startup”).

After weeks of applying lean principles to a business problem, I’ve got some basic takeaways for the lean-curious:

1.  Agile = efficiency. Lean = effectiveness.

Agile is all about efficiency. Removing waste from production and optimizing the flow of goodness. Prioritizing the work we need to do. But agile doesn’t ask the question: is this even the right product?

That’s where lean comes in. Lean asks us to challenge all of our assumptions by testing BEFORE we build.

And when you get into it, we all have a LOT of assumptions about what will make great software. And too often, we incur the full cost of building that software and making it perfect, only to learn from customers at the very end that it’s not really what they wanted at all.

2.  Test assumptions with a minimally-viabile prototype

The developer in me hates and loves this one at the same time. If you assume that customers will totally love your idea, sketch up the idea and show it to a few people first instead of coding it. That last part is hard (the not coding part).

The basic principle is: build a prototype to the lowest level of fidelity (i.e., cost) to validate your assumptions.

Some amazing tools for this are:

  • Balsamiq. This is amazing for a non-designer type like me to communicate design ideas in a reasonable-looking way.
  • Usertesting.com. This site allows you to test web-accessable prototypes out easily and get feedback from real people outside your usual sphere.
  • Prototype on Paper. If you’re prototyping a mobile application, this free (!) iPhone app lets you knit pictures of sketches together and even makes a small website for you and your users to navigate by clicking hotspots on each sketch. Crazy cool.
  • The cloud. Once you move into HTML prototypes, look at Azure / Amazon / Heroku / App Harbor to quickly get feedback on clickable prototypes.  I used the heck out of my MSDN Subscription credits on Azure and it worked beautifully.
3.  Test weekly

Every week, there should be some new ideas or assumptions to validate. Get some people, somewhere, that aren’t on your team, to bounce the prototypes off of. It’s amazing what you’ll uncover. Building software isn’t a special forces operation. Don’t go dark. Make testing a part of your weekly cadence.

Lean Weekly Cadence
4.  Gather and scatter

This is particularly important for the other introverts out there who, like me, get drained by all-day meetings and constant debates over features and ideas.

There is a huge temptation to think if you just spent another hour at the whiteboard, you’d come up with an idea so perfect it would be impervious to refinement or customer feedback. You can’t. Get an idea, scatter to work on it, test it, reflect on the findings.

5.  Frame the problem, not a possible solution

Another way to say this is: focus on what customers need, not what they might possibly want.

If you start with a problem, you can come up with some metrics to measure progress towards a solution. If you start with a solution, any metrics could end up supporting your conclusion.  Which is kind of the whole point of lean – validating that our solution ideas meet some need or produce some meaningful outcome.

Lots of this was inspired by a wonderful book called Lean UX, which you should check out if you want to dig deeper.

Lean_UX