Update: Jeff’s presentation is now available online.
Today I was lucky enough to attend Jeff Gothelf’s O’Reilly webcast on Lean UX.
I was particularly keen to attend the webcast as I’ve been around Agile projects for some time, performing business analysis activities and supporting clients through rapid prototyping, but I wasn’t sure how to make UX activities Agile and I was hoping that this webcast would help me answer that.
Well the good news was, Jeff explained that Lean UX is inspired by Agile development theories:
Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
And is based on the values from the Agile Manifesto:
- Individuals and interactions vs. processes and tools
- Working software vs. comprehensive documentation
- Customer collaboration vs. contract negotiation
- Responding to change vs. following a plan
Up until this point I hadn’t really seen any differences between Agile software development and what Jeff was describing as Lean UX. That’s when Jeff explained how Lean UX is really based on the Lean Startup Process. And how Lean UX had evolved the Lean Startup process to create this:
It started to make sense to me.
There has been a shift from can this product be developed (technically) to should this product be developed (because our users need need/want it).
Jeff went on to say that “In a fast-paced environments, traditional UX is a bottleneck. We have to change perspective on how to “do” UX, today’s markets require a new way. A faster way. Designers can no longer hide behind their monitors any more! This is a designer led initiative. Get designs out there. Fast. In public – where others can see them.”
5 Things you need to do to be Lean
In Jeff’s presentation he suggested 5 tactics that you can do to help kickstart Lean UX into use in your projects:
- Solve the problem together
- As opposed to implementing someone else’s problem.
- Give them a problem to solve – not guidelines to implement a solution.
- This team will be far more effective, motivated and productive if you do.
- Sketching – it’s all the rage!
- Get the ideas out of peoples heads.
- It’s NOT drawing, we don’t need to see the finished article. And you can do it collaboratively.
- Doing it together allows software engineers and designers to problem solve.
- Sketching brings experiences to life faster.
- Prototype it [Amen!]
- Build an experience, not a document.
- Once validated, demo it to the team. And get everyone started.
- There are no additional deliverables needed!
- Pair up! But do it, cross-functionally.
- Pairing saves time and builds a common language and a common understanding of the challenges.
- You start to free up your designers and empower your developers.
- Developers don’t have to wait for a design to start coding something and designers are freed up to do something difficult.
- Start a style guide
- The cause of, and solution to, all UX problems.
- A catalogue of the code snippets, the colour palette, the elements, the graphics.
Lean UX is not
If you’ve been around Agile projects in the past you’ve probably had to defend the things that it is not to the outside world. Lean UX is no different:
- Its not a shortcut
- The only thing being removed is waste
- Leave the toolbox intact, just use it one tool at a time and at the right time
- This is not a design by committee
- That never leads to anything pretty
What did I learn?
A lot. As I’ve been writing this post I’m considering more of what Jeff described and how it can be worked into projects that I’m working on. There were a few nuggets that will stick with me though:
- The Goal: Moving forward in parallel path with development and design.
- ‘The Spec’ doesn’t control: Lead with the conversation, trail with the documentation (that you need).
- The Pepsi challenge: Use data to settle subjective issues. A/B testing can settle them.
- Go for bronze: You’re not aiming for gold medal work. It needs to be ‘just’ good enough.
- Every design is a hypothesis: Don’t design things people don’t want. You can find out if people want theses things before hand.
- Validate your hypothesis with the users: Keep it light and cheap. Put it in your diary once a week – get 3 or 4 people in and show them what you have ready to show them.