Moving to Lean UX: how
This post is part two (here’s part one, “why?”) about what we learned switching to Lean UX.
In this part I talk about the process behind creating the process — putting the framework together, introducing it to the team — as well as the benefits. It will be useful if you’re sold on Lean UX, but wondering just how to get your team onboard.
Making the switch
It’s one thing to read a book and want to implement Lean UX, but it’s another to roll it out with your team. In the example I was talking about in the prequel to this post, around half of the new team had worked with me before on a previous project, so they were as used to the ‘traditional’ approach as I was. I was keen to make sure everyone was happy to give this a go — highlighting the experimental nature of this was key — as well as giving them ample opportunity to raise any concerns.
Product decisions needed to be made, so we had to design our first research session soon. First though, I needed to run the team through my Lean UX research and I did that with an introduction to the new board. The team had seen it being assembled over the course of a few days, but it was empty, and with good reason. It was down to us, the team, to fill it up with our assumptions, hypotheses and validation signals.
We started with a straw man proposal from the product manager as to the wording of our assumption and we adjusted together over three or four minutes. From there we took 5 minutes to individually write down any questions that this assumption threw up. We took turns in reading our questions back to the room and sticking them up on the wall. Some of the questions were general (“how do we know people will pay for this?”), and some were more technical (“would people be happy with this script?”) but natural groupings started to appear:
Collectively we voted on the groups with questions we were most eager to answer, particularly the ones pertinent to technical decisions we wanted to make soon. From there it was a short hop to generating some hypotheses in the form of belief statements, along with matching validation signals so we’d know when we could describe them as being true.
Creating the board
If I could only highlight two words in Lean UX, they would be learning and visualise . Putting our learning up on our wall ticks both of those boxes.
The wall should update and change weekly, like our learning should. Hypotheses and their signals should come and go, with new ones put up after validating existing ones. The learning log should contain really good evidence that’s useful for decision making.
Most of all, our board is visible to everyone. Discussions about competing technical implementations, or design options can be made objectively and implemented, without bias or emotional attachment. Continuous discovery means that it will be ok for us to be wrong, because we’ll find out much quicker and know how to correct ourselves.
Finally, with all this in place, we spent around 30 minutes creating our first research call brief. It’s amazing how much easier it is to create a brief for a research call in the context of a few hypotheses — it really focuses the mind.
Moving to Lean UX has definitely brought benefits, but it’s also brought new challenges
So what’s different? Moving to Lean UX has definitely brought benefits, but it’s also brought new challenges to contend with. If these seem a bit anecdotal it’s because they are, I haven’t worked out how to measure a more quantifiable metric yet.
The positives
+Managing the unknown
For projects with products in their infancy, Lean UX appears to help with acceptance that there will be many unanswered questions, including some fundamental ones like ‘is the thing I’m working on actually of any use to anyone?’.
+Time
Less of my time as a UX Designer is spent perfecting UI designs, fussing over polishing personas or taking an entire day to design a research call and create the assets for it. That frees me up to support other projects, or requirements of my role. It used to take a day or two to build a research or usability testing call plan. Now it takes about 15 minutes every week. I’ll do that with one other person, and all we’ll do is make adjustments to last week’s plan, removing and adding questions in line with the removal and adding of hypotheses.
+Waste
When wrapping up previous projects, I’ve always been a bit surprised about the amount of unimplemented design work that I have had to archive — folders and folders of it. I can see how that can quite easily be viewed as a waste of my time (there is some learning in there, I’m sure), I’m confident this won’t be the case when I move on from a Lean UX project.
+Collaboration
We still pair or group sketch, but the sketching now feels less onerous. Where sketching used to start with a 30 minute introduction to the problem space, it now just starts because the team already have their heads in that space so much so that sketching and wireframing kicks off without me. Other team members can take ownership of things like wireframe productions, and it feels good to be able to hand over that responsibility to people who have a desire to build on those skills on their personal development plans.
+Research
We can test with the product itself, not a prototype, which means I rarely have to break out Axure or Balsamiq in order to validate a concept with users. Not only that, but it’s easier to create the plans as a team, because it takes less time, but because we also know as a team what we need to find out.
+Decision making
Decisions appear easier to make; an example came up recently, whereby a technical decision needed to be made. We had data from the previous week’s research that indicated user preference for one implementation over the other, so we managed to make a data-driven decision and accepted the risk on the sample size by agreeing to monitor it in future calls.
The (potential) negatives
— Time
Although de-emphasising the need for polished deliverables has given me time back, it’s worth pointing out a good portion of that time is now filled with facilitation tasks; maintaining a research register, making sure the team is up to date with the latest learning and finding users to arrange calls with.
— Creativity
Creativity can suffer. For a few weeks I struggled to get my head around how we might extend a feature in the future to handle some of the use cases that a few of our users were starting to describe to us. I can’t help but feel that with the traditional UX model I would have nailed the problem. As it happened, a chance email from a previous research participant provided the answer anyway, but if creative space is something you crave then I would suggest carving out some creative time each week.
— Team involvement
The early days of any software product are very busy with lots of provisioning work to get through. I was worried that the team wouldn’t be available to get involved in UX as much as Lean UX suggests is necessary. We tried to mitigate this risk by asking the team at one of our kick-off meetings how much time they would like to dedicate to research and learning. As it turns out, my fears that the team would be too busy to be involved were completely unfounded.
Finally, as the role of UX Designer evolves, it’s become clear how by shifting to Lean UX, it becomes less about me producing stuff for development, and more about facilitating development teams in building products. That’s something I’m still getting used to.
