Jeff Gothelf at London IA February 2012
Sjors Timmer reviews Jeff Gothelf’s talk at London IA February 2012
Lean UX – getting out of the deliverable business by Jeff Gothelf
Jeff Gothelf, formerlly director of UX at the Ladders and currently principal at Proof, an innovation studio in New York, has already made some furor with his concept of Lean UX. In the past we had only his slide deckto rely on, but last Tuesday Jeff finally made his UK debut at London IA.
Jeff’s Lean UX story starts with a retrospective. If Lean UX is such a good thing, then why aren’t we all practising it? Jeff states that long, long ago, there was a world with very young information architects, where every trade had their own deliverables –some had reports, some had code and others had excel sheets– but the young discipline of IA had nothing, nothing but wireframes. In order for IA to claim a seat at the table, the wireframes were used to represent IA. For a while this approach was successful but the good times didn’t last. Web projects became more complex, and in line documentation kept on growing and growing. We now have reached a point where projects are so complex and situations so unpredictable that it becomes impossible to describe them with documentation. Something has to be done.
As a remedy Jeff proposes Lean UX, where real experiences are continuously tested and where people work together towards great experiences in a shared understanding of the problem.
Jeff explains Lean UX in 5 points:
1. Solve problems together. Business, marketing, development and design should start actively collaborating on solving business challenges. Working collaboratively leads to a shared understanding and more motivated and invested people.
2. Sketch. The common language, the thing that everyone gathers around, should no longer be spec documents but sketches. They can become the initial artifacts that spark discussion and create a shared understanding. And because they are easy to make, no-one is too invested in their own ideas, and they can be easily thrown way.
3. Prototype. In line with the Lean Start-up concept, prototypes are seen as a great way to create validated learning. Due to their interactive nature they allow for easy validation, and quick iteration.
4. Pair up. Cross-functional pairing is another pillar to the method. When designers work directly with developers they both start out with a shared understanding of the problem. Developers can start working on the things that are hard for them, whilst designers can focus on the more complex interaction challenges. Pairing creates mutual trust and deeper investment. Jeff mentioned using firebug as a tool that allows developers and designers to work together in an agile way.
5. Style guides. In order to live without massive specs, some documentation cannot be avoided. Jeff opted for the idea of a living, breathing style guide, that allows developers to quickly look up which style comes with ‘main call to action’ and designers to check if there are existing code patterns that could be reused.
Jeff continued by dealing with some of the critiques and challenges of the Lean UX approach. In order for it to work we need to get rid of this idea that designers should get it right the first time and it should be the designers and not the spec document who are in control. To create buy-in and shared understanding it’s important that everything is open and visible. For people who are used to working towards a certain amount of perfection in their deliverables the Lean method will at first feel a little uncomfortable, but as Jeff stated, how can you aim to make the best product when you don’t know if you are working on the right product? It’s successfully solving problems and creating value for our clients (and users) that should be our focus and not the creation of beautiful deliverables.
Q&A and Discussion
The second part of the evening was a panel discussion with Johanna Kollman, Leisa Reichelt, Jeff Gothelf, James O’Brien and Mark Plant, and Jonty Sharples as the host. Based on questions from the audience, they discussed how it’s possible that while everyone agrees with the premises of Lean/Agile –less waste, shared understanding, focus on the end results– a more lean way of working still seems to be far from common practice.
Several reasons were discussed.
Economical: many of the larger agencies are actually in the deliverables business and get good money for delivering wireframe decks. Also there’s an initial cost of changing to a new method. This might only change after clients themselves become more agile too; to achieve this, Johanna argues, there need to be internal stakeholders or embedded teams.
Trust: to become more agile people have to trust each other, Leisa argues that it’s almost impossible to do Agile in a situation with 3th party developers. If you haven’t build up a relationship with your client they will most likely go with a competitor who claims they can deliver on a fixed deadline and fixed budget, and will see your agile approach as too risky.
Technical: creating a living and breathing wiki style guide takes time and effort. How do you integrate such a thing in your organisation? Jeff suggests choosing someone as the owner of the wiki, and if it also includes code snippets, to co-own it with development and have a dev-owner too. James argues that instead of using a wiki, patterns should be printed out on the wall, and a css-preprocessing language can be used to store all the default styles.
Social: getting agile to work means spending more time talking and explaining things to colleagues, not everyone is up for that. Also here it is possible to start small, make some of your process or some of your team more agile, and let everyone slowly get used to shared responsibility and shared ownership.
Experience: no-one would argue getting agile to work is easy, it’s best done by people who know a rich set of tools and methods to adjust their process to the problem (and not the other way around). Mark argues that it’s impossible to force people into an agile way of working, they must want to work that way, and Johanna wonders if mentoring and show’n’tell is a good way to distribute Agile knowledge.
Psychological: Agile can be a painful process for perfectionists. Visual designers in particular protest against losing their time and ability to do large pixel-perfect design upfront. James argues that the agile process forgets quiet places and time for reflection. Developers have refactoring time, where they clean up old code, and designers should claim this time for themselves too. Another element that Jeff brought up is that designers are used to being applauded for the beauty they bring into the world. Agile, and its focus on the end product, however, has no room for individual heroes and only works well as a team sport.
Somewhere towards the end, Leisa wonders if we’re just finding endless new ways – Agile, Lean UX, goal directed design – to rename what should be known as good design? And this sentiment also resonates with others, was this evening just another version of our yearly agile versus waterfall debate or is there something new under the sun? What is certain though, is that we are moving towards a more complex and uncertain future, and that we need all the ideas we can get to stay in control of our technology. This evening at the Sense loft was therefore an evening well spent.