5. Lean is rising
“Lean UX is the practice of bringing the true
nature of a product to light faster, in a
collaborative, cross functional way.”
“Continuous engagement allows you to strip
away heavy deliverables in favor of
techniques that allow us to build shared
understanding with our teammates”
The contrast between how we used to do things and how the Lean UX book described things was large. We were used to big batch work activities such as generating end to end storyboards for the entirety of Visual Studio, we were used to running large scale UX studies on significant pieces of the design. We weren’t used to the idea that we could iteratively design and evaluate designs on a weekly basis. Getting to the point where we could run weekly iterative design sessions seemed like a challenging goal.
I was assigned to work on a recently formed project around March/April last year. The project was focused on the developer experience for building an application that can run on both Windows and Windows Phone. It just got announced a few weeks ago.
To begin with, the team was very small. There was just three of us working on it – myself, a designer and the program manager. Our task was to come up with a design for the end to end experience that the engineering team could then figure out how to build. Traditionally we would have gone into slide creation mode and spent weeks designing a sequence of slides that demonstrated the proposed experience. Those slides would have been fairly detailed, would have been fairly expensive to create, and would never have been shown to a potential user before engineering looked at them to determine how to build it.
It was also a fairly challenging problem to work on. There were many questions about the experience that I didn’t really have an answer for. How would developers expect to be able to design different UI for the same app running on Windows and Windows Phone. How would a developer debug their code on both platforms? How would a developer know what code can be shared across platforms and which code is unique to one of the platforms? How should we lay out the structure of a developers project in Visual Studio?
Coming shortly after reading the Lean UX book, what was uppermost in my mind as I started thinking about this project was the idea about permission to fail. Lean UX recommends that you make a list of assumptions you have about your users and your product and then validate those assumptions with mockups, prototypes, whatever materials you have available. It further makes the point that you should do this in an iterative, continuous fashion.
So the questions that I had about the experience, I could use the Lean UX technique to iterate my way towards a solution. We could come up with some candidate designs for the questions we had and use weekly feedback sessions to continue to iterate and refine the design. This seemed really attractive to me.
So on our first project meeting I proposed to my two colleagues that we start a weekly cadence design iterations. We would meed on Monday to discuss the design problem and the study we would need to run to get answers to that problem. We would meet on Wednesday to discuss progress on the preparation of materials for the subsequent study. And we would meet on Friday to run the study and then discuss what we had learned. I purposefully chose not to describe the whole Lean UX process as I was worried that it would be considered too much. I was overly cautious
So we proceeded on that basis. And it was really successful. Each Monday we would ask questions like ‘What does the project structure look like in Solution Explorer’ and then set up a study that week to try to find out what users thought. We would come up with candidate designs and in the study we would show these to participants who would give us their feedback. We did this every week and each week felt like we were making great progress.
And we were. But things started to go a little haywire after a couple of months. We felt like we had been making good progress but soon more people started to join the team. And they asked if we had tried different design alternatives for certain scenarios. When it turned out we hadn’t we revisited that question and ran more studies. But now we weren’t in a good position to add to the learning we had generated previously. We were simply comparing opinions of different people on different designs. It wasn’t really clear what we were learning compared to what we had learned. There was no grounding to help
What I had neglected to do was to pay attention to defining the hypotheses that we were ultimately testing. In my haste, I had chosen not to focus on that as I felt it was too big a change to be one that I could easily convince my colleagues to adopt. But now were were in a position where we had a lot of opinions and feedback expressed by participants from multiple studies but we had no framework to bring them all together. We were accumulating information but we weren’t necessarily learning the same amount.
Through experience we learned that had we taken the time to think about the assumptions and hypotheses that were behind the questions we were asking we would have been on much more solid ground. We would have been able to synthesise data from multiple studies and grow our understanding of the impact our designs were having on the UX.
It seems obvious in hindsight – the hypothesis driven approach is really almost the definition of lean UX.
As UX people, none of us want to watch people suffer with products that you work on. We want to create great experiences. increase the chances
You become responsible for driving outcomes, not for running tests. So you can’t sit on the sidelines and observe and simply pass on your observations. You need to agitate, motivate and advocate for change. You need to be a part of making that change.
Your colleagues need to know that the rules have changed though. Becoming an agitator when they expect you to be a dispassionate observer will simply agitate people.
They further postulate that continuous collaboration and continuous discovery are fundamental to how you “bring the true nature of a product to light faster.”
I’m reminded of a famous Steve Jobs quote where he said, “design is the soul of a man made thing”. I believe continuous collaboration and discovery are the keys to how, “you find the soul of the product or service that you are making”.
“Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed”
“This continuous engagement allows us to strip away heavy deliverables in favor of techniques that allow us to build shared understanding with our teammates.”
“We can’t continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective.”
Telemetry – think about the Monaco auto save story – the outcome is reducing anxiety, not reducing the number of times that people press ctrl-s. Don’t focus on what you can easily measure.
It’s sometimes hard to ask the question – what is the outcome we are trying to accomplish.
This sounds really dumb, but in a large, complex organisation where there are perhaps not enough UX people to go around, and where lean UX hasn’t yet completely embedded itself within the organistion, you may find yourself being added to a project some time after it has started. It may only be a few days after, maybe a few weeks but it has already started. In those situations it is tough to be the one that stops and asks the questions – what are we trying to achieve? But it is often the best time to do it. Many other people on the team have probably got so focused on what they need to do that the question of why they are doing it is one that they
Then there is the practical business of how do you define an outcome for a particular piece of a massively large project for which the ultimate project outcomes is difficult to connect to the piece you are working on.
On the project as people were added to the team, they weren’t aware of what we had done before. And even those that had been involved started to forget what we had learned earlier. So we took some time to review each iteration and compile a set of learnings so that we could communicate that to everybody else and so that we could remind ourselves. We used OneNote
what happened when people joined the team later on.
On both the product you are building, and the process
When you focus on outcomes, you don’t get judged on the deliverables you create. You no longer should be satisfied with simply being responsible for running a study or creating a design. You actually have to take responsibility for achieving an outcome. That means lots of things. It means you are actually working to make a difference in somebody’s life, which is obviously very fulfilling. When you get this right, the rewards are great. But it also means that you aren’t necessarily the only person that can create a design or run a study.
Giving this up has been one of the hardest things
Stories pull people in, and stories can be shared. Good stories will be shared.
This helps you pull people in and helps you scale.
