Changing the UX methodology to reflect the needs of the project and team
Introducing a development team to Lean UX
The development team in which I was embedded had just had its project brought to an end.
For the 18 months prior, we were building on an existing product where the problem/context was well understood.
The team and I had been using an approach to UX that allowed us to design and test new features just ahead of development time.
We were now faced with a new project, to understand a new context and problems that might be solved through the buildinng of a new product.
The devil makes work for idle developers, and the danger was that we’d simply begin developing the wrong thing using our previous approach.
The developers were tasked with wrapping up the previous project, giving me time to work out our approach for this project.
I’d read enough about “Lean UX” to be confident that the approach prescribed in Jeff Gothelf and Josh Seiden’s book suited our needs.
I compared the fifteen Lean UX “principles”, to team behaviours to understand how big of a task it would be to make the change with the team.
| Principle | Following? |
|---|---|
| Cross-functional teams | ✅ |
| Small, dedicated, colocated (teams) | ✅ |
| Outcomes, not output | 👎 |
| Problem-focussed teams | ✅ |
| Removing waste (no unimplemented designs) | 👎 |
| Small batch size (just enough design) | 👎 |
| Continuous discovery | 👎 |
| Getting out of the building | ✅ |
| Shared understanding | ✅ |
| Anti-pattern: rockstars, ninjas and gurus | ✅ |
| Externalising work | ✅ |
| Making over analysis | |
| Learning over growth | 👎 |
| Permission to fail | ✅ |
| Getting out of the deliverables business | 👎 |
Developing the process
Driven by the principles of Lean UX, the objective was to have a tight build-measure-learn process each sprint. Our process would be:
- Collect every question the team had
- Turn those questions into hypotheses
- Agree on the “validation signal” for each hypothesis
- Develop a research script with which to test these hypotheses
- Publish what we’d learned and develop a wireframe solution/feature
- Implement the MVP of the feature to test in the next cycle
Implementation - getting buy in
Throughout the process of getting buy-in and implementation, I framed the switch as an experiment, to say ‘this isn’t permanent’ and ‘there’s room for adjustment’.
I presented my diagnosis and plan to the Project and Product Managers. Their feedback, agreement and support was critical.
I asked each developer to write down (as a sealed bid) the proportion of time they’d be prepared to commit to research, forming a contract.
I visualised the entire process on the team dry-wipe board, so the team could understand the new process as we worked through it.
Outcomes
We became better at dealing with ambiguity. Simply spending time writing down the things we didn’t know, but having a plan to find out helped manage the unknown.
We reduced “design waste”. Only designing just enough to get the MVP built meant no time was wasted on unimplemented design work.
Cross-functional collaboration improved. Invested in answer their own questions, for example, engineers would write research scripts.
Research improved. An MVP meant we could see genuine user behaviour, such as hesitation, in a way we couldn’t with wireframes.
Team decision making improved. Agreeing on validation signals meant gave confidence to commit when the agreed signal was seen.