Implementing Lean UX in the real world

In 2013, Jeff Gothelf and Josh Seiden published a book called “Lean UX: Applying Lean Principles to Improve User Experience”. It quickly spread through the UX community like wildfire. “Lean UX” was the ultimate pep-talk that had much of the design community pumping their fists and shouting like over-excited 17-year olds at a pre-game rally, yet 6 years later many of us are still scratching our heads trying to figure out how to actually implement it in the real world, with real deadlines, and with real product development teams who have near-instinctual aversion to spending time doing anything but coding. Even if you are able to sell product and development on the idea, actually putting it into practice can be a major challenge — but it is possible. It is my desire in this article to share what I have learned about implementing Lean UX principles in the real world. It is my hope that sharing what I have learned might help you avoid some of the same mistakes and enable you to deliver improve outcomes to your users in a quick, reliable, and sustainable way.

WHY LEAN UX AT ALL?

Why did Lean UX come about at all? To understand that, it’s important to understand a bit of history. If you’re already familiar with Lean UX and why it was so needed, feel free to skip past this part. For everyone else though, I think it’s important to have some context.

When companies first starting developing software 30+ years ago, software had to be manufactured and physically distributed. It required a supply chain. It was expensive. The barrier to entry was high and the cost of failure was even higher. This caused immense pressure to “get it right”. This pressure and manufacturing process necessitated a stage-gate process. The product requirements had to be set in stone, so that design could be done, so that development could be done, so that distribution could happen by a certain date.

User feedback was also very difficult to get. If a company wanted to get feedback during the design process they would have to manufacture discs and send them to users or physically bring beta testers into their office. Because of the tight and absolute timelines this was difficult to do. So companies just chocked each annual release full of as many features as they could possibly manage and then ship it hoping that buried in the myriad of new features was something that users would find helpful. When they did get feedback after a release they had to wait an entire year to deliver improved outcomes based on that feedback.

For these reasons and others besides, the optimization became focused on output. It was all about efficiency. It was exactly like manufacturing a physical product.

This was all well and good back when software had to be distributed on a physical disc. What else could they have done? The problem, though, is that we do not live in the same environment today. The internet and cloud computing has brought digital distribution. We now live in the Experience Economy where consumers expect ever-increasing standards of great user experience, and consumers don’t put up with products that prioritize business goals over consumer needs. Barrier to entry is also dramatically lower than it used to be, and it is relatively cheap to start a software company today.

Yet many software companies are still operating much the same way today that they did 30 years ago. Product Managers are still spending most of their time grooming a 90-day backlog of requirements. Designers are trying to stay as far ahead of development as possible. Development expects full design specs and mockups before they start on anything. Leaders evaluate teams (especially developers) based on velocity and burndown charts which are 100% focused on output. Sound familiar?

The great problem with all of this is that it creates a tremendous amount of waste. Every idea, every design, every business requirement is an assumption. The only way to move from doubt to certainty is to build something, get it in front of users, and learn.

AGILE DEVELOPMENT

The founders of the Agile Development methodology recognized this and tried to improve things. The manifesto they wrote on a mountain in Utah in 2001 had 4 core tenets. They said they valued:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

They also identified 12 core principles behind the Agile Manifesto:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The goal was obvious: work collaboratively, build something quickly, get it in front of customers, then iterate based on your learning. The problem was that the founders of Agile were just focused on development, not on the full product lifecycle. There was no inclusion of design. Also, while the Agile Manifesto and Principles were firmly rooted in an outcome-based mentality, they were just that principles. So various frameworks spun up to try to put Agile into practice — Scrum for example — that in their attempt to help companies move faster, often lost sight of the reason for Agile in the first place (customer learning and outcomes). As a result, most companies practicing Agile today practice “Agile-fall” which is basically Waterfall at light speed.

NOTE: I should note here that Scrum does not HAVE to operate this way (as Jeff Gothelf & Josh Seiden thoroughly demonstrate in “Lean UX”), but many of the practices naturally trend toward a focus on output so it’s very easy to end up practicing AgileFall under Scrum if you’re not careful in how you implement it. Which is part of the entire problem with why many companies struggle to implement Lean UX in Scrum environments.

LEAN UX PRINCIPLES

Enter Lean UX. Lean UX was an effort to combine all the best ideas from Agile Development, Lean Startup, and Design Thinking. It is what Agile was intended to be. A way to help eliminate waste, and put the focus on getting something in front of customers ASAP, learn, and then pivot based on feedback. I highly suggest you read Lean UX if you haven’t yet, but the core of Lean UX boils done to the following principles:

Principles to guide team organization

1. CROSS-FUNCTIONAL TEAMS — a team made up of all the various disciplines needed to design, build, test, and ship software. (Engineering, PM, UX, QA, Marketing, etc).
2. SMALL, DEDICATED, COLOCATED — teams should be no larger than 8–10 people, should be dedicated to only 1 project, and staffed out of a single location.
3. SELF-SUFFICIENT AND EMPOWERED — teams should be autonomous and have all the people, tools, and resources needed to make decisions and ship software without external dependencies. They should be free to decide how to solve the problems you assign them.
4. PROBLEM-FOCUSED TEAMS — the team should be given a problem to solve instead of solutions to implement. This allows innovation and creates a feeling of ownership and accountability among team members.

Principles to guide culture

1. MOVING FROM DOUBT TO CERTAINTY — recognize that everything is an assumption until proven otherwise. The goal should be to learn. This provides clarity and confidence that what you’re building will improve outcomes for customers.
2. PROGRESS = OUTCOMES, NOT OUTPUT — progress should be measured in meaningful and measurable change in customer behavior, not just outputting 20 new features. Output is meaningless without improved outcomes.
3. SHARED UNDERSTANDING — the rich understanding of the space, product, customers, and their jobs to be done that builds up over time as the team works together that eliminates the need for debates, second-hand reports and detailed documentation.
4. ANTI-PATTERN: ROCKSTARS, GURUS, & NINJAS — teams should foster a team-based mentality over star performers and “mini-CEOs”. Collaboration and team ownership over individual experts.
5. PERMISSION TO FAIL — teams have to be free to experiment with ideas, but most will fail. There has to be a safe cultural and technical environment to experiment.

Principles to Guide Process

1. SMALL BATCH SIZE — create only the designs, artifacts, and product that is necessary to move forward. This helps minimize risk and puts the focus on learning.
2. CONTINUOUS DISCOVERY — a constant attitude of discovery. Teams should learn from customers frequently regarding both what they do and why. Discovery should be done frequently, on a regular cadence, and with the entire team.
3. GETTING OUT OF THE BUILDING — test ideas with a strong dose of reality while they’re still young. Don’t just sit around a conference table debating, create something and “get out of the building” with it.
4. EXTERNALIZE YOUR WORK — get your work out of your head and into the public view while its still young enough that you can act on feedback.
5. MAKING OVER ANALYSIS — there is more value in creating the first version of an idea than debating its merits for half a day in a conference room. Make something and get out of the building with it.
6. GET OUT OF THE DELIVERABLES BUSINESS — focus on the outcome you’re creating not deliverables. Deliverables have no merit in and of themselves. Documents don’t solve customers’ problems, good products do. Create only the deliverables needed to move the project forward toward improved outcomes.

For more info see: Lean UX: Applying Lean Principles to Improve User Experience

WHEN THE RUBBER MEETS THE ROAD

I still remember where I was and how I felt the first time I was introduced to these principles. I was super excited. It just “clicked”. I immediately went back and tried to implement them on my team. After a few weeks, I got buy-in to try involving the dev team in discovery and brainstorming. It was a disaster. They enjoyed the brainstorming, but that only accounted for a few hours a sprint. We tried to involve them in user research but at the level of UX maturity we were at as a company, we were still struggling to schedule user research participants in a timely manner. It also took time for us to come up with designs the devs could build. While we were designing, they were trying to find what they could do. It was such a disaster that the “pilot” was considered a failure and we went back to traditional scrum. We tried to bring in developers earlier in the process so sprint planning wasn’t the first time they ever heard of a new problem, but they were focused on solving a different problem so they helped how they could, but their head was never in it the way the creators of Lean UX made us believe was possible. A huge amount of waste was still being created, but at least we were operationally efficient — we didn’t have developers just sitting around.

A few years later, I joined another company and was excited to try this again. I involved a cross-functional team in my iterating. We created “learning stories” to try to force some collaboration on discovery into the process. It definitely was an improvement. We discovered technical constraints earlier and got engineers to help us ideate which reduced some waste in the process. Yet the company was VERY obsessed with comprehensive documentation and I found myself spending 40% of my time just writing documentation on what the design was supposed to do & look like before developers built anything. It took us a year and a half of work before we were able to release anything to customers. It may have been collaborative and we were “Agile”(used Scrum), but it certainly wasn’t lean and we really weren’t practicing agility (little “a”).

Then finally, I took a job at an early-stage startup company where the head of engineering and product both were very interested in Lean and wanted a UX leader to come in and help get it off the ground. “Finally!” I thought. I’ll get to eliminate waste and deliver improve innovative outcomes to customers more efficiently. We had cross-functional teams. Eventually we got them to be focused around a single project (it took over a year) although the requirements of that project were shifted quite a bit so I’m not sure how much shared understanding we really built up. There were some major wins though. We worked on a couple “pilot” projects where the devs, pm, and I would brainstorm a user flow together. The devs would start building the infrastructure, while I flushed out the more complex interactions, and the PM helped manage the customer relationship and set up feedback sessions. Every day we met. I came up with ideas. The developer came up with ideas as he was working, implemented them in a front-end UI with a mocked backend, and showed me for feedback. Together we would make tweaks and then test them with clients. Working this way actually allowed us to discover a major inaccurate assumption that invalidated most of the design decisions we had made. Luckily we discovered it in time to pivot in time to finish the UI prototype before a conference our management wanted to demo it at.

That prototype project was such a success that we were encouraged to keep evolving our lean process with all our product teams. What we found was that while this rapid, learning-based, collaborative model works well for prototypes and consumer applications (as demonstrated by the Nordstrom Innovation Lab Case Study), it doesn’t work so well for international, enterprise-level software. Part of the reason for this is that the back end for such platforms is very complex and takes months to build. There simply isn’t time to keep iterating on the back end. Also, the cadence identified in Lean UX (see below) breaks down if you try to include back end developers in it since they simply can’t keep up.

Image credit: “Lean UX”, Jeff Gothelf & Josh Seiden, O’Reilly publishing, 2013.

SUGGESTIONS FOR IMPLEMENTING LEAN UX “IN REAL LIFE”

These experiences helped me come to some realizations that were eye opening. They led me through experimentation to learn a few key discoveries that are absolutely necessary for Lean UX to stand any chance of being implemented successfully at Enterprise Software-As-A-Service (SaaS) companies. In the time since, I have come to learn that there are 5 keys to overcome the obstacles that often prevent Lean UX from getting off the ground.

1. Implement a design system (or at least a component library)

A living design system is absolutely critical if you want to stand any realistic chance at moving quickly enough to be able to learn from customers regularly and release small batches of functionality to customers on a regular basis.

Often you’ll hear the words “Design System”, “Component Library”, “Style Guide”, and “Design Language” used interchangeably, but they’re actually not the same thing.

A “Component Library” is a set of pre-built components (also sometimes called “Atoms” in Brad Frost’s “Atomic Design”) that can be pulled in to create a design or user interface. These essentially are the building blocks from which layouts and interfaces are built. By standardizing components, both you as the designer and your developer colleagues can be on the same page and create designs and interfaces very quickly. It takes a bit of work to set up but once you do, they save you a TON of time in both design and development. That frees you up to focus on learning from the customer instead of spending weeks designing, prototyping, and building software before you can get it into someone’s hands.

A “Style Guide” is the standards for how to use the the components. When should you use the primary button vs secondary button vs ghost button for example. Or what grid do you use when? Or what should the standard margin/padding be between different kinds of components. Etc.

“Design Language” is all around the information architecture and content of your product. What tense should you use? Should you use playful or technical copy? What accessibility standards are enforced? etc.

Style Guides and Design Languages are very valuable, but they are not as crucial to Lean UX as a component library. So if you have to start somewhere, start with a component library.

Something else to mention about component libraries is that they are a product for products. Like any product you can build or buy. If you are going to build your own make sure your company is big enough to justify the investment. To be done right, a custom design system or component library needs its own product team. It needs a PM, UX Designer, and developers. You need to do research, and follow the same lean process you would on a product being released to customers. Too many companies think it’s a “set it and leave it” project. So they build components to very specific requirements and then paint themselves into a corner later. Then later it either becomes a bottleneck where you need a developer to add a new component but they don’t have time, or else it ends up not having the components designers need to design so they don’t use components from the library and in no time half your code is using the library and half are not.

My recommendation would be that unless you work at a large company that is willing to create a “Design System Team”, that you go the second route: buy. Actually, you don’t even need to buy. There are excellent 3rd party open source component libraries that have been thoroughly researched, built, and tested that you can use. This is actually the route I have always gone since most of the companies I’ve worked at have been small to mid-size companies with relatively small product teams. Here are some of my favorites:

Ant Design Web Component Library

Ant Design is one of my personal favorites. At first glance it looks just like bootstrap, but under the hood it is very powerful (especially for the flexibility it gives developers). The styles are very easily overwritable and they even support internationalization, Typscript, and have React, Angular, and Vue versions. It is also very easy to get up and running and has excellent design resources (Sketch asset library) that matches the web components.

https://ant.design/

IBM Carbon Design System Web Component Library

IBM’s Carbon Design System is also excellent. It is very thorough and has had multiple teams dedicated to it for many years. It supports vanilla JS, Angular, React, and Vue but has workarounds for other frameworks as well. Carbon has great design assets although overwriting the actual styles of the web components is quite a bit more complicated (though definitely possible).

https://www.carbondesignsystem.com/

NativeBase Mobile Component Library

NativeBase is a great mobile component library built for ReactNative and VueNative that are compatible with both iOS and Android. It also recently started supporting web components though I’m not sure how thoroughly those have been tested. It is very easy to overwrite the styles as well and even has a super easy way to do theming built in.

https://nativebase.io/

Other component libraries

There are many other 3rd party component libraries available. There is a great list available at https://adele.uxpin.com/

https://adele.uxpin.com/

2. Decouple front-end and back-end code

One of the things that really sets many Lean UX attempts back from my observation is how long back-end development takes. Yet this doesn’t need to apply to Front-End code. Often, though, the front-end and the back-end are so tightly coupled together that all developers are forced to become “full stack” developers. Even with a web component library in place this really slows down the agility of your team because back-end work doesn’t have the luxury of iterating multiple times. One other side effect is that in “full stack” environments, often management hires back-end developers and forces them to also implement the front end even though most back end devs hate the front end. On the flip side front end developers have to learn back end which often isn’t their cup of tea. The two types of development are actually very different and there are very very few developers who are equally good at both. It requires very different skills to be an excellent front end dev than a back end dev and vice versa.

But, if you loosely couple the front end and back end code, and link them via an API with a shared data contract, this enables you to hire dedicated front end developers who can use that shared component library to quickly spin up UI code by pulling various components together. This can be done with a mocked back end as long as the data contract is agreed upon between front end and back end which allows the front end team, product, and UX to iterate together quickly based on customer feedback (following Lean UX principles), while the back end is built out.

3. Establish a user research practice first

One of the biggest blockers to Lean UX I have found is your ability to learn quickly enough from your users and customers. Part of that is having a component library in place so that you are spending time on solving problems rather than designing/building components on every project. The other part is being able to get your designs in front of customers quickly and efficiently. If you’re building consumer software, you can just go hit a mall, park, or plaza and stop people on the street whenever you need insights or use services like UserTesting.com to quickly get the insights you need. With enterprise software, however, that doesn’t always give you accurate results. The jobs to be done in some environments are so specific that you really need actual customers (or perspective customers in your space) to learn from. This can be a challenge that isn’t going to go away just because you’ve formed your Lean Team and implemented a component library.

My recommendation would be that establishing a user research practice should be one of the first things you do if you want to help your team work in a more lean way. This doesn’t necessarily mean that you have to go out and hire a dedicated user researcher. The biggest challenge to establishing a user research practice usually is finding participants. The other great thing about establishing a user research practice is that you don’t need to wait until you have a Lean Team to do it. Just talking to and validating ideas with customers can go a long way to helping you to be more lean as a company even if you are not able to implement any of the other Lean UX principles. The key is to get to the point that you are speaking with customers on a regular cadence (at least weekly is a good goal). Here are 5 suggestions of how to establish a user research practice that can help shift the focus from gut hunches to learning.

1. Start small, but start

It’s really tempting to want to build out a robust user research program complete with quantitative and qualitative techniques balanced across all 7 areas of usability, but start small. The truth is that the vast majority of companies today never get past the 80% worst usability problems, and all you have to do to discover those is just to get your ideas in front of someone. You don’t even need to be good at user research techniques, just get your ideas in front of users and the rest will take care of itself. It’s far more important to get some feedback regularly than to get methodologically-strict insights occasionally. As you progress in your UX Maturity, naturally you will want to focus on refining your research moderating skills, incorporate more quantitative research, etc. But for now, just do something. Until you get past the 80% worst usability issues, how good you are at research techniques doesn’t matter a whole lot.

If you would like more info on what this might look like when you start out, or how a research practice should scale as both maturity and the company grow, check out the excellent presentation by Danielle Greene at the 2019 Front Utah conference, “Scrapping your scrappy research process for scale”.

I would emphasize, though, before you can “scrap your scrappy research process”, you have to have one. So start small. Get research happening regularly, then worry about scaling it and making it more methodologically strict.

2. Involve cross-functional team members in your research

Even if you can’t form a cross-functional team to work with day-to-day, start to bring other people into your process. One fantastic way to do this is to make sure any time you are doing research you have at least 1 person in a role different from you involved or at least observing the research. Jared Spool recommends that all stakeholders should be exposed to real people using real designs for at least 2 hours once every 6 weeks. I think this is a great goal.

One other suggestion I have found to work very well is to involve stakeholders in selecting participants, planning the research, and debriefing after the conclusion of the research. Naturally, it’s best if they participate in the actual sessions as well, but if they can’t at least involve them before/after.

3. Create a research plan

While you don’t need to be overly concerned with technique at the beginning of your user research journey, one thing I have found extremely helpful to start doing after your research program gets up and running (that many design teams neglect to do) is to create an actual user research plan. Forcing yourself and stakeholders to sit down and define your objective, questions, method, etc can really give clarity and focus to your research and helps you to demonstrate ROI better to management if needed. It also helps you to focus on learning. There are various ways to go about creating a user research plan. The process I use (“DECISION”) is outlined below:

Decide on the main goal or objective of the research
Explore questions & assumptions (what is it you want to find out)
Choose a method (interviews, demos, usability testing, etc)
Identify participants (employees and clients)
Script or tasks
Identify schedule & budget (time, recruiting, & equipment)
Outline responsibilities
Nail the schedule down

It is also helpful to succinctly summarize your plan to be distributed to team members or stakeholders as needed. This can be especially helpful if you are wanting to take an out-of-state trip to visit customers in their natural habitat. For example, I use this 1-page summary. You can download an editable pdf or sketch file to help get you started if you like.

4. Create a User Research Panel

It can be extremely difficult if not impossible to schedule research participants once a week if you have to manually curate a list, work with support or sales to manually contact them, explain what you’re doing, then try to schedule the sessions with interested parties. It can take weeks just to schedule a single study. This doesn’t work in a Lean environment. You will have to do this at first, but your goal should be building up a user research panel of people who have expressed willingness to provide feedback in the future. At the end of every research appointment you do, ask if they would be willing to provide feedback again sometime or if it would be ok if you reach out to them with follow up questions. Often, you will get access to participants through other departments, but asking participants to join your user research panel will open the door for you to contact them directly in the future. Over time you will build up a group of people who you know are willing to help you which greatly speeds up the recruitment process. AirTable is a fantastic tool to keep track of everything. They even have some templates to help get you started.

5. Automate the recruitment process

One game changer for me in my quest to speed up the recruitment process to enable Lean UX, was when I found this article on the AirTable blog around automating the recruitment process. It was a gamechanger and while I haven’t got it to run as smoothly as I would like yet, it is extremely helpful in speeding up the process.

How to build a UX research system that runs on autopilot

The basic summary is to use NPS surveys (or some other survey type) to fill up the potential user research funnel, then at the end of the survey send an email to a segment of respondents asking if they would like to participate in a user research study. If they click the “yes” button in the email, you can then use a calendar-scheduling service like Calendly to automatically schedule research appointments based on your team’s availability. (You could set availability for every Thursday from 1pm–5pm for example). Once appointments are set, you can then follow up with details or instructions on what to expect.

If you’d like more information, check out the article. It has lots of great suggestions.

4. OKRs

Something else that can really help pave the way for Lean UX is to start to get the company (and especially the executive team) focused on outcomes instead of output. One of the best ways I have found to do this is to help them deliver your team “problems to solve” instead of “solutions to implement”. Most executive teams are very goal-oriented. They make and track revenue goals, EBITDA, and are very conscious of the roadmap. One of the tricky things, though is that roadmaps are typically linear commitments of features to be delivered by a certain date. Yet, software projects are almost NEVER linear. There are bumps in the road, detours, and ideally learning that cause us to need to pivot. All this causes “delays” when your measure of success is output.

To help shift the focus to outcomes, one thing I’ve found a surprising amount of success with is getting executives excited about Objectives and Key Results (OKRs). OKR is a goal-setting methodology originally perfected by Google and used by hundreds of other companies today. There are entire software products just to help companies implement and transition to OKRs.

The basic idea is that teams and individuals identify Objectives (problems to solve) aligned with Strategic Themes identified by the executive team, and Key Results (metrics that measure progress toward the objective). The how is left up to the team. Key results are like sign posts with a distance marker. They show progress and how far you currently are away from your objective. In short, they help you move from doubt to certainty.

For example:

Objective
Increase performance of product by Q4

Key Results
Eliminate 95% of bugs
Processing time reduced by 35%
UI job completion time reduced by 50%

The team is then free to figure out how they are going to eliminate the bugs, reduce processing time, and shorten job completion time. Every sprint or month the team can then report back to management on progress. With each small batch release, progress can be shown towards the key results instead of just outputting features. There is a lot of precedence for OKRs. Google and hundreds of other companies use it and have found success. Just Google “OKR” and you will find hundreds of great resources. If you need a jump to get you started, Perdoo has a lot of great information/resources at https://www.perdoo.com/resources/. They even have an overview spreadsheet you can check out with instructions, and examples of company, team, and individual OKRs.

This is all great, you tell me, but what about roadmaps? What does a OKR roadmap look like? Well, something like this:

Credit: Jeff Gothelf, What Does An Agile Roadmap Look Like

As soon as the executive team has identified the strategic theme, you can set quarterly OKR goals for your team. Then, clearly label any features that have come up as ideas “Features we are considering”. This helps put the focus on the fact that these features are HYPOTHESES. They may be right or they may be wrong, and that’s ok — and 100% up to the team based on their learning. You will also notice that the farther out you get, the fewer feature hypothesis you should have. That is because you will learn a lot between Q1 and Q4 so it doesn’t do much good to even brainstorm the how since all your work up until then will inform (and likely completely change) how you approach solving your Q4 OKRs.

So, then at the end of the quarter you evaluate your objective against your key results and decide whether you are good to move on to your Q2 OKRs. For example, let’s say at the end of Q4 we haven’t quite eliminated 95% of bugs using the example above. But we have eliminated 75%. Then looking at what we need to accomplish in Q1 of the next year we might decide that is good enough for now. So we move on to the next problem. Or, maybe we decide that we really HAVE to get to 95% and we’ve made a lot of progress but we’re not quite there. So we decide to bump Q1’s OKRs to Q2 and work on eliminating bugs for one more quarter. Now THAT is agile. It gives enough visibility to the executive team and board while still allowing the team to solve the problems and measure problems by outcomes and not output alone.

5. Show, don’t tell

Now, there are 2 ways I’ve found to go about a Lean transformation. You can evangelize the process and try to convince executives to change and let you do this new amazing process. Or you can SHOW them how it works and prove the value with your results. While it might be possible in small companies to do the former, the latter is almost always more effective. Changing culture and process is not an overnight thing. Be lean about implementing lean. Pick the very next thing you need to do to move towards the outcome you desire. Don’t forget:

This applies just as much to process and culture change as it does to UI projects. Just starting working more collaboratively and in a learning-focused way and people will follow you. Eventually you’ll get enough traction to propose doing a pilot with a cross-functional, autonomous, problem-focused team on 1 project. Then you show results from that. Then you take it to the next stage, and the next. I’ve even created roadmaps of process change before just so I can put my mind at ease that we are making progress and to plan out what the next phase(s) are.

PUTTING IT ALL TOGETHER

Ok. With all of that out of the way, now I want to bring it all together. This is a diagram of how I’ve seen Lean UX work in the real world after all the struggles and learnings I’ve had. I’m not saying that this process will work for everyone but, this is what has worked for me.

It all starts with a quarterly OKR. You break each OKR down into a theme (also called “initiative”) based on the progress you want to deliver to customers. For example, “Reduce purchase-to-delivery time on furniture deliveries by 25%”. Then you get the entire team together at the beginning of each new initiative to get on the same page and brainstorm assumptions you have around target users, their characteristics, pain points they are encountering, and how you might be able to help. The goal at the end of this is to create a vision board for what problem you’re solving and how you plan to validate your assumptions.

You then write out your stories and/or tasks for who needs to do what to validate those assumptions. For example, the PM might conduct some stakeholder interviews to better understand the business problem. The UXer might set up some customer interviews, contextual inquiry visits, or sending out a survey. The Developers might start pulling data and looking through logs to see what pertinent information they can find that can illuminate/validate the problem. Get all of these tasks clearly outlined in your tool of choice. Then everyone gets to work preparing what they need to do to validate the problem. Each day you meet together and go over your progress. If help is needed, ask for it. At the end of the sprint, the goal is that everyone has learned something either directly from users or from their data.

At the beginning of the following sprint, you meet together briefly again to plan what needs to be done to learn from customers. As you move from doubt to certainty and from problems toward solutions, the focus of the sprint planning meeting will be on brainstorming ideas that can be built and tested with customers.

For example, you might schedule a 2-hour brainstorming session or design studio to sketch out ideas or user flows on how furniture delivery dispatchers might more quickly create schedules. Then the developer (front-end, remember) might work with the back-end dev team to identify what changes to the data contract are needed & then start building out the new structure using the component library with a mocked back end. The UX Designer might start looking into the more complex interactions and if changes to the visual hierarchy or affordance/feedback of interactions are needed. Etc. Each day everyone meets together to show how far they’ve got and identify any changes that are needed. Then you get the UI in front of customers and test it out and iterate based on their feedback.

At some point (around half way through) the front-end and back-end team have to agree on a final data contract where no more changes to the back end can be made. This is so the back end team has time to finish their work while the Lean Team keeps iterating on the front end.

Then, when the back end is in a good spot, you removed the mocked back-end, hook up the real back-end, test it, and release it. Then you either move on to the next theme or keep iterating if the outcomes doesn’t end up being quite what you thought it should be. The key here is that working this way you are able to iterate quickly based on feedback with the front-end team while the back end team is plugging ahead with their work. By the time you release, you will have validated your decisions with customers multiple times and iterated based on their feedback.

One other note. In the diagram above, the Lean Team was working in 1-week sprints while the back end team was working in 2–week sprints. This is very deliberate. By working in quicker intervals on the Lean Team, you put the focus on minimizing waste and getting to a state where you can validate your assumptions ASAP. The exact time intervals can vary, but the goal should be to reduce the “time to learning” in each sprint.

ONE MORE THING

There is just one more thing I want to mention that can have a dramatic effect on your ability to move quickly, eliminate waste, and make decisions based on learning. That is continuous delivery.

If you can work with your engineering or dev ops team and get them to build a way for code to be deployed in a continuous way by the product manager or engineering team, it can greatly speed up the process. One of the main tenets of Lean UX is eliminating external dependencies and this is one of the biggest external dependencies I’ve seen. You have something ready, you want to roll it out, but it has to go to a dev ops team to roll everything out manually. One way to do this are the “release trains” used by Spotify. Another way is the “Blue Green Deployment” model. Whatever the approach, the goal is to be able to automate the deployment process while still being able to easily roll back code if a problem exists without any external dependencies or downtime. For more information check out Spotify Engineering Culture, part 1, Spotify Engineering Culture, part 2, this article on BlueGreen deployment by Martin Fowler, and this one on Using BlueGreen Deployment to Reduce Downtime and Risk by Cloud Foundry.

CONCLUSION

I hope I have said something in here that you have found to be useful. My goal was not to overwhelm you, but to give you some ideas that can help you implement Lean UX principles in the real world. It can be tough to be sure, but as long as you remember that it’s a process, a road map, not all-or-nothing, I am confident you will be successful.

One last thing to remember as you think about these solutions and consider how you can apply lean principles at your organization.

There is no single, correct way to do ANYTHING. Take the pieces from multiple approaches that work for YOUR situation, YOUR users, YOUR client, YOUR organization and jettison everything else.
— Joe Natoli

Have something to add? Need a product leader to help shape your organization’s UX maturity? Connect with me on LinkedIn to join the conversation or check out my portfolio to learn more about my work.