Lately I have been binging on books, presentations and articles related to ‘Lean UX’. I don’t like the term, but then I don’t like the tech industry’s love for inventing a new label for every damn thing. I do like the things emphasises: shared understanding, deep collaboration, continuous user feedback. These are principles that have always implicitly guided the choices I made when leading teams at Hubbub and now also as a member of several teams in the role of product designer.
In all these lean UX readings a thing that keeps coming up again and again is prototyping. Prototypes are the go-to way of doing ‘experiments’, in lean-speak. Other things can be done as well—surveys, interviews, whatever—but more often than not, assumptions are tested with prototypes.
Which is great! And also unsurprising as prototyping has really been embraced by the tech world. And tools for rapid prototyping are getting a lot of attention and interest as a result. However, this comes with a couple of risks. For one, sometimes it is fine to stick to paper. But the lure of shiny prototyping tools is strong. You’d rather not show a crappy drawing to a user. What if they hate it? However, high fidelity prototyping is always more costly than paper. So although well-intentioned, prototyping tools can encourage wastefulness, the bane of lean.
There is a bigger danger which runs against the lean ethos, though. Some tools afford deep collaboration more than others. Let’s be real: none afford deeper collaboration than paper and whiteboards. There is one person behind the controls when prototyping with a tool. So in my view, one should only ever progress to that step once a team effort has been made to hash out the rough outlines of what is to be prototyped. Basically: always paper prototype the digital prototype. Together.
I have had a lot of fun lately playing with browser prototypes and with prototyping in Framer. But as I was getting back into all of this I did notice this risk: All of a sudden there is a person on the team who does the prototypes. Unless this solo prototyping is preceded by shared prototyping, this is a problem. Because the rest of the team is left out of the thinking-through-making which makes the prototyping process so valuable in addition to the testable artefacts it outputs.
It is I think a key oversight of the ‘should designers code’ debaters and to an extent one made by all prototyping tool manufacturers: Individuals don’t prototype, teams do. Prototyping is a team sport. And so the success of a tool depends not only on how well it supports individual prototyping activities but also how well it embeds itself in collaborative workflows.
In addition to the tools themselves getting better at supporting collaborative workflows, I would also love to see more tutorials, both official and from the community, about how to use a prototyping tool within the larger context of a team doing some form of agile. Most tutorials now focus on “how do I make this thing with this tool”. Useful, up to a point. But a large part of prototyping is to arrive at “the thing” together.
One of the lean UX things I devoured was this presentation by Bill Scott in which he talks about aligning a prototyping and a development tech stack, so that the gap between design and engineering is bridged not just with processes but also with tooling. His example applies to web development and app development using web technologies. I wonder what a similar approach looks like for native mobile app development. But this is the sort of thing I am talking about: Smart thinking about how to actually do this lean thing in the real world. I believe organising ourselves so that we can prototype as a team is absolutely key. I will pick my tools and processes accordingly in future.
All of the above is as usual mostly a reminder to self: As a designer your role is not to go off and work solo on brilliant prototypes. Your role is to facilitate such efforts by the whole team. Sure, there will be solo deep designerly crafting happening. But it will not add up to anything if it is not embedded in a collaborative design and development framework.
I’ve run several teams following the lean UX approach.
What seems to have the biggest impact is making the following two activities a team effort: — Hypothesis formulation — Evaluation of the required prototype fidelity to answer the hypothesis.
This creates the required buy-in on the goal and method, and makes arriving at the required fidelity a team responsibility. Combining this with “go-no-go moments” where everyone can provide input, on whether the prototype reached a state where it can answer the hypothesis makes it a much more gradual proces.
The challenging part is that everyone has a different interpretation of what “answers” a hypothesis. This tends to get better over time as the team gets more familiar with user research and gets exposure to different methods.
While the UX-team of one is helpful to keep a high pace, it tends to limit you to hypothesis you as a designer can prototype. As Bill Scott clearly lays out, todays challenges often require a set of different skills rarely found in one person.
Few agile teams are currently positioned to fully commit themselves to a experiment/lean UX approach. It seems that the 20% time type projects are currently best positioned to get them on the fast track to production by applying lean UX processes.
My impression is that few teams outside the valley have gotten to run a continuous experimentation program. This is subject to change, but might explain the limited discussion.
Thanks for dropping by and leaving such a thoughtful comment!
Why do you think that is?
Good question! I think its largely because they are stuck in an operational role, where the outcomes are not measured by impact on the user/business but by number of features created.
Teams where this measure by impact is already at the core (e.g. innovation or optimisation departments) are much more able to make the transitions.
Businesses are often risk-adverse, while experimentation should reduce the risk (validation before going through the entire production funnel). Many businesses still see it as something that diverts resources from “sure things”.
Products nowadays reach the plateau (in Jared Spool’s maturity model; stage 3: Productivity Wars) much earlier, and therefor expectations are higher. I expect this trend to continue and with that the relevance of the experimental approach.
Yeah the pressure to crank out features is huge. There is this mental trap where any activity aimed at understanding if it is worth the effort to build something is perceived as wasteful. But orientation is the schwerpunkt. So that should apply here as well.