Integrating a Lean UX Process

A quick start guide to getting started with a Lean UX approach to product design and development

Introduction

When a design team first ventures into the Agile world of product development it can often feel like design is left by the wayside. It’s not uncommon for designers to struggle with understanding where their role, or the tasks they complete, fit into iterative product development.

Lean UX can help to solve that problem.

Alongside other user centred design methods, such as Design Thinking, and Agile Development, by using the Lean UX method a product team can utilise the benefits of an Agile philosophy while always ensuring customer and business value.

It’s important to point out that although these methods are often seen as overly complex terminology or just as industry buzzwords the processes do have real value and at their most basic are quite simple to conduct. Whether they’re called by the names above or some other name bears little relevance.

Design is a process of understanding, not an output. It’s the understanding gained from these design and development processes that’s important; feel free to call them what you want.

What this guide is

This is a kickstart guide to Lean UX which discusses some of the most important principles and actions to start with. A team can take this guide to integrate a Lean UX process in a practical and realistic manner, taking small steps to ensure that the team is not disrupted and the wider business accepts this new way of working.

New processes can be daunting to both understand and implement, the aim of this guide is to help kickstart this new process without feeling overwhelmed. It’s possible to use this guide both before and after reading the Lean UX book, as it in no way replaces that.

The guide is split in to four parts outlining the basics of Lean UX; including what it is, why a team might use it, who it’s for, how to use the process, a breakdown of the principles and why they matter, any challenges and risks the team might face and finally some tangible actions to start today.

What this guide isn’t

This guide is certainly not to replace the fantastic Lean UX book by Jeff Gotthelf and Josh Sneiden, nor will it ever be able to detail the process in the depth they have. Reading that book is essential to understanding the methods involved, others in the Lean Series and also Lean Experimentation by Maryam Aidini and Kylie Castellaw are equally insightful.

Some other processes will be mentioned in regards to Lean UX and how they interact. However this guide will not go into any detail about Design Thinking, Agile Development, Lean Startup, Lean Enterprise, Lean Experimentation or the Corporate UX Maturity Scale. It will also not explain any industry terms such as ‘iteration’ or ‘velocity’.

Who the guide is for

Lean UX is not just for designers and this guide will help teams to see the value of collaborative product design and development. The change to Lean UX might start with designers but this is a method for the whole product team and they need to understand and embrace it to be successful.

• For Designers or Design Teams that are starting out on their Agile design journey in a business that has already embraced Agile development, or those that are right at the beginning of their Agile transformation.
• For Design Leads that have dipped their toe in the water of Agile design processes with a ‘Sprint Zero’ method — soon realising that it’s just upfront design but in shorter iterations.
• For Product Owners, Scrum Masters, Business Analysts and Software Engineers that have endured the pain of transitioning from a Waterfall development process to Agile. Where they still have exhaustive upfront design supplied to them, when design is often seen as the blocker to development or design is too prescriptive and technically unfeasible.
• For Product Managers that have realised measuring the success of a product is best done by highlighting the value features bring to customers and therefore the business (outcomes) and not on how many (output), and the speed of which (velocity), features are built.
• For Business Leaders that are trying to move their company up the Corporate UX Maturity scale and are starting to realise the importance of a User Centred Design process and the team taking ownership of their decisions.

Part One: What, Why, Who, How

These are the basics of what Lean UX is, why companies are starting to use the process, who it works for and an overview of how to use it. This section is a top level view of Lean UX and as this is only a guide in how to integrate it into a team or business it’s best to read Lean UX by Jeff Gotthelf and Josh Sneiden for full details on the process and how to implement it.

What is Lean UX?
A process for obtaining customer feedback as early as possible, enabling the team to make quick decisions to improve the customer experience and provide business value. With less focus on detailed deliverables, by cutting waste, empowering small cross-functional teams to collaborate and focus on solving specific problems to deliver change that will improve the product for customers over time.

Lean UX follows the cadence of Agile development iterative cycles to ensure that customer feedback can be used in each iteration and delivery of improved customer experiences is continuous. The process also allows the whole team to be involved in product decision making, experimentation and early risk analysis and technical feasibility.

This is not the end point of so called ‘Agile design’ processes, it’s just the next step to a holistic approach to product design and development. As the team grows in confidence and ability they’ll undoubtedly start to question their own processes and possibly move past both Agile and Lean to something altogether new.

Why use Lean UX?
Due to the ever shifting nature of technology and constant changes in how we as people interact with digital products and hardware, designers are no longer bound by traditional methods. There is no need for multiple levels of sign-off before something goes to release; no longer are designers bound by physical constraints such as printed material or CD based software.

While this evolution in technology and user behaviour was increasing at a rapid pace there was little movement, from traditional design process, to the way digital products were designed. Agile development is now being broadly employed by development teams and designers haven’t quite follow the pace, introducing ‘Sprint Zero’ as a forerunner to Agile development sprints is a good step in the right direction but is by no means the most effective method.

With ‘Sprint Zero’ Developers still considered design a blocker, or too prescriptive, while not being involved early enough in the process to call out any risks or be included in decision making. On the flip side designers didn’t feel that design was being taken seriously or that they were given enough time to be creative, innovative or investigate real user problems.

Lean UX is that next step to a more effective, integrated and collaborative experience design process. Product teams need to be as reactive as possible, due to the ever shifting nature of technology and constant changes in how we interact with digital products. While working on small batch sizes and employing a process of continuous delivery designers can measure usage patterns and analytics to rapidly make changes to provide customer and business value.

Who is Lean UX for?
The short answer is… everyone!

The longer answer is that the whole design and development team will be involved: Product Owner, Product Manager, Heads of Department etc. User experience design is a collaborative effort and as detailed in the Lean UX book and as I have below; a shared understanding and cross-functional team are key factors.

If Business Executives want the company to move up the Corporate UX maturity scale and ensure a business that focuses on it’s customers, they should also have an understanding of the process. They’ll need to understand how to supply problems for teams to solve and how to measure with outcomes instead of output or velocity.

Integrating any new process, if it’s to be successfully adopted, will normally start from the ground up and with Lean UX that will most likely designers first (in comparison to Agile development that will most likely start with developers). Over time the process will grow to the rest of the product team and the Product Owners/Managers will need to gain the trust and influence with the wider business to make broader changes.

How to use Lean UX
Start with a business problem, using the Lean UX canvas; what problem has the business identified that needs solving? Consider what outcomes will validate the success of a potential solution; what metrics can be supplied by the business to show that?

Think about customers; are there any specific demographics that this problem affects? Are there any specific customer types that need help or have relatable experiences that could be improved? Consider what benefits they will gain from this; what is the customer value? Empathy maps, customer journey mapping and proto-personas will help with understanding customer needs.

With the business problem, outcomes and customer value outlined the team can run a cross-functional and problem focused ‘Design Studio’ (divergent and convergent ideation) to form potential solution ideas. This is a chance for the team to get creative and innovative! Members of the team that don’t often get the chance to be involved with product decision making can now have some influence and designers can also practice their workshop facilitation skills.

Up to this point the canvas has been laying the groundwork for creating hypotheses (testable scenarios). Everything up to this point should have brought out a number of assumptions about the potential solutions and how they try to solve the business problem.

Assumptions about the business outcomes, customer value and potential solution ideas are used as a basis for creating hypotheses for experimentation. Identify the riskiest assumption, the assumption that if wrong could cause the whole idea to fail, and run experiments to validate these assumptions.

Experiments can be quick and easy; it’s the smallest thing that can be built to validate assumptions. As mentioned in the Lean UX book, an experiment could simply be an email newsletter signup form, used to determine whether the business would go ahead with the time consuming and costly process of creating content, associated infrastructure and supporting processes.

This serves two purposes: understanding whether customers even want an email newsletter, and, if yes, could also be used to create a database of initial customers and maybe what they’re interested in to tailor that content for the most value.

Part Two: First steps to integrating Lean UX

There are fifteen principles to Lean UX and all are equally important. This part of the guide will focus on those principles but to make them more digestible they’ve been reorganised into three categories: ‘The Team’, ‘The Measurement’ and ‘The Process’.

The order of these categories is important, without the right team organisation or measures provided by the business in the right way the Lean UX process will never be truly effective.

The Team: Principles

• Principle 1: Cross-Functional Teams
• Principle 2: Small, Dedicated, Colocated
• Principle 9: Shared Understanding
• Principle 10: Anti Pattern: Rockstars

Getting the right team in place is the most important part of any product design and development process and it’s at the core of a successful Lean UX process. To ensure the shared understanding (9) the team has to include not only various disciplines (1) but people from different backgrounds, experiences and interests.

As much as possible the team should be diverse. Consider building a team of people from different countries, ethic and religious backgrounds, sexes, orientation and disabilities. The real world is made up of these people so to effectively tackle their problems the team should be too.

Equally important is team size — it should be small (2). Four to six people would be ideal, ten to twelve would be the maximum. I’ve seen teams as large as thirty and teams that are smaller but are heavily weighted towards a particular discipline and neither are truly effective.

Smaller teams are better able to communicate and are more creative generally, if the team is dedicated on a specific task they’re able to converge on the problem quicker and more effectively. The larger the team size the more difficult it becomes to communicate across the whole group or make vital decisions. Think about some past experiences or current working practices; is it easier to chat with two close colleagues about how to solve a problem or with twenty people?

Colocation (2) isn’t quite as vital. Don’t get me wrong. It is better if the team are all in the same room. If a part of the team is located on another floor or office building, then make the effort to move everyone to a shared space permanently. However, with today’s modern workforce and global businesses that’s not always possible. There’s also many positives to distributed teams beyond cost. Teams can work around the clock on projects, there’s the potential for more diverse insight, timezone crossovers can provide true focus, and, if the team is multi-disciplined in both locations, dispersed locations allows for the possibility of communicating any outstanding actions over at the end of each day.

Building a Lean UX team is all about getting the right people (10), there should be no ‘rock stars’, ‘ninjas’ or ‘gurus’. There should be no stubbornness and no people on the team that are more focused on themselves and showcasing their own work than the team and it’s progress in business solving problems to the benefit of the customer.

This is all about collaboration, the best user experiences are not made by individual designers they’re made by teams of ambitious people that collaborate together to solve problems. Subjective opinions should be left at the door and instead the focus should be on what’s right for the customer and not the individual.

The Team: Key points

• Teams need to be small for effective communication and collaboration.
• Shared understanding comes from cross functional, dedicated teams.
• There’s no place for ‘out for themselves’ individuals.

The Team: Actions

• If the team is large (more than ten), start by creating a smaller group with just a designer and a business analyst. Allow them to focus on a specific feature and work together to understand what the experience should be.
• If this step is successful on an initial feature then add two developers to work with them on the next. Give this smaller sub-team a feature to work on, a two week timeframe and the space to work without distractions.
• Conduct a retrospective at the end to determine if the team setup was successful. If it works, let this smaller team stay together for future iterations and slowly scale it to the rest of the team based on these learnings.

The Measurement: Principles

• Principle 3: Progress = Outcomes, Not Output
• Principle 4: Problem Focused Teams
• Principle 14: Permission to Fail
• Principle 15: Getting Out of the Deliverables Business

This is the most challenging set of principles as it means a change not only to the delivery team but also to the mindset of the management and, possibly more importantly but even more challenging, the executives running the business.

Without making some of these measurement improvements to the current design and development process it won’t be possible to utilise the full power of Lean UX, or any Lean process for that matter. As I’ve mentioned previously, this process can start from the ground up but executive buy in is essential to ensure it’s prolonged success.

Only when the team has been reorganised to allow at least some of the larger team to work in a smaller, more focused sub-teams that are dedicated to one or more features the process of looking at how the progress is measured can begin.

Taking it slow is an important factor to the success of Lean UX. Introducing new measures with the current oversized none dedicated team will only be a struggle and without successful examples buy in from execs will be tedious. The team will also be confused and the integration of the process could fail as quickly as it’s started.

Once those sub-teams are in place instead of working on a specific predetermined feature they should work on solving a problem (4). Business problems are easier to start with as they should have been supplied with success metrics to validate the outcomes (3). These business metrics, ideally supplied by management or stakeholders, allow the team to focus on the outcomes (3) of what they create rather than how quickly they do it (velocity) or by how much they create (output).

Agile favours ‘Working software over comprehensive documentation’ and Lean UX has a similar principle (15). Design artifacts are certainly useful; wireframes, prototypes, visual assets, research data, process flows, empathy maps and so on all provide the team with a level of understanding or practicality. However, these are not the elements by which the team should be measured. ‘Documents don’t solve customer problems-good products do.’

The team is at it’s most creative and productive when solving problems (4), instead of just designing and building features. It allows them control over what they create which in turn gives the team ownership and pride in their work.

Failure is a vital tool for learning (14) and both the delivery team and management need to realise that failure, if aiding continued learning, is an acceptable step towards understanding what the customer really needs and how they use the product, rather than just what they say they want.

If something doesn’t work how it was assumed and expected to then that’s a learning, it allows the team to progress it’s understanding and head in the right direction, continually modifying and measuring the product for the most customer value.

The Measurement: Key points

• This is the hardest set of principles to implement and it takes time.
• Build trust and gain influence with stakeholders before changing measurements.
• Measure success based on outcomes, not output or velocity.
• To be at their most creative the team must focus on solving problems.
• Failure is a tool for learning and should be accepted as such.

The Measurement: Actions

• Starting defining some assumptions about your next feature, use the Lean UX canvas to help. Validate your assumptions with usability testing and make changes in the design and analysis phases before going to development.
• Ask business stakeholders or management to provide you with metrics to measure the success of the feature. If they’re not able to provide any then use your customer analytics to determine your own.
• Allow the sub-team to solve a business problem rather than design a specific feature. Make sure the team know that validating the outcomes of a business metric is more important than showcasing design deliverables.

The Process

• Principle 5: Removing Waste
• Principle 6: Small Batch Size
• Principle 7: Continuous Discovery
• Principle 8: Get Out Of the Building
• Principle 11: Externalising Your Work
• Principle 12: Making over Analysis
• Principle 13: Learning over Growth

The majority of Lean UX principles fall into the ‘process’ category. Lean UX is all about building, measuring and learning so while the other two categories are important to lay the groundwork it’s really here that implementation will take place.

Many of these principles are self-explanatory; the first three (5, 6, 7) are focused on efficiency while providing a base for the final two (12, 13), the ‘build, measure, learn’ philosophy principles, to be at their most effective.

The remaining two principles (8, 11), that might seem rather basic, are actually very powerful and underpin much of what Lean UX is about.

Collaboration is the key to a successful Lean UX process, not only that, it’s the key to creating great products that customers want to use while bringing the business validated success.

One very easy but effective way to engage others and thus forcing collaboration is to get design work out in the open (11). When the team’s work is out on the wall for all to see it starts healthy discussion, raises questions and creates further assumptions the team can test and validate.

This, however, will all be in vain if the team don’t do what is probably one of the most important principles; speaking to customers (8). Actively seeking out real customers can be tricky, especially if the product is new or has a niche market. Finding real customers and conducting monitored usability testing is not the only way to go and just speaking to people is going to bring some level of value.

There is a sliding scale of valuable feedback; speaking to people who work in the same office will only provide limited usability or interaction design feedback. Speaking to real people outside the building will provide more valuable feedback, however it might not help to explain all of the real customer needs, only what people expect to happen.

The Process: Key points

• Increase efficiency by only focusing on design work that will have an affect on the measured outcome.
• Follow the ‘build, measure, learn’ philosophy for greater results.
• To increase collaboration get design work out for all to see and discuss.
• Speak to real customers early and often to ensure the team are building the right product for them.

The Process: Actions

• Print your design work and get it on the walls to aid discussion, force questions and highlight avenues of interest to investigate. Better still discuss your work around a whiteboard and sketch only what is necessary to get towards the desired outcome.
• Test your assumptions with real customers if possible, if that’s not an option then at least get real people outside of your office building to provide you with feedback. Experimenting with real customers can be done in the live product, however you must ensure that measurement of the feedback and the associated learnings actually evolve the product.
• Start small and learn as you progress; use your assumptions created with the Lean UX canvas to define a hypothesis and experiments to validate it. Defining and creating a minimum viable product can be very useful, but be careful when setting expectations with management and stakeholders as they may have a different understanding of the term.

Part Three: Challenges and Risks

Battling terminology and buzzwords
With every new process comes a barrage of terminology to understand and buzzwords to trip over. These can cause confusion and problems, not only within the team but also with business stakeholders that care little about the meaning behind the jargon and just want to see progress.

Shield stakeholders from this confusing, albeit valuable terminology, until the team fully understands them, has experience implementing them and can show examples of how they work to support the conversation.

These are important for the team to understand, along with the Product Owner and Product Manager, but above and beyond that there is little use anyone knowing the terminology. All it will achieve is confusion, overuse and eventual misuse (just think about how misunderstood MVP is!).

To build trust with stakeholders show them real examples of success, to gain influence with them speak their own language and build a s0lid relationship with mutual respect.

Knowing when to use a Minimum Viable Product
Until this point I’ve not mentioned minimum viable products (MVPs) and there’s good reason for that. Designing and building MVPs for experimentation is a crucial part of a great product design and development process and yet the term feels like it’s been hijacked. It’s been taken by the uninformed and assimilated into the acronym heavy business world by executives that know no better.

MVPs can be used in two different ways; based on the hypotheses created they can either be used to validate assumptions by understanding what the market wants. Or they can be used to deliver a limited functionality feature or product to start delivering customer and business value straight away. Getting to market quickly is an honourable endeavour and if done correctly this second way can still produce valid learnings.

Both ways of utilising MVPs are perfectly good, but understanding the difference and when to use each method is important. They should be utilised primarily as a tactic to aid a practical build, measure, learn process.

Use a vision to keep design iteration on track
Designers need to understand the value they can bring to an Agile development team. Design iteration using the Lean UX process is great if there’s a product vision for the team to pin their flag to and designers are crucial to that.

Without a design vision the product could end up with a mess of confused and often contradictory design patterns, interactions and experiences. It might not sound particularly ‘Agile’ to do design work up front, however creating a tangible product goal can allow the design and development team to keep on track and focus decisions while continually iterating towards that goal.

Slow progress can feel frustrating but it’s important
It can take some time to implement a truly Lean process and at first it might seem to be slower than a traditional waterfall process as members of the team acclimatise and try to understand what is expected of them as different stages.

Take an iterative approach to implementing this process, take small steps and measure the change, learn from it and continue to progress. Applying a ‘build, measure, learn’ philosophy to process implementation, team and product management takes time but as with good product design the value is higher than rushing ahead.

Getting the right infrastructure and tools
Implementing a radical new approach to product design and development is difficult enough but even more so without the right infrastructure in place to conduct that process.

Some of the crucial elements to put in place, while not an exhaustive list, are: unlimited wall space, collaborative open office space, a continuous flow of pens and post it notes, numerous whiteboards, the right computers, high quality video conferencing, a shared file system, a thorough and evolving pattern and interaction library and possibly a living style guide.

All of this takes time and money to implement but they are often integral to the adoption of a new process and the overall value they bring should outweigh the cost overtime.

Part Four: Even quicker actions you can take today!

Integrating a Lean UX process is no quick and easy task, there will often be blockers inside and outside of the team. However using these three actions on the next feature, product or project can be done without even uttering ‘Lean UX’ or the adoption of a new process to anyone.

• Action 1: Get around the whiteboard
  With the next feature the Product Owner/Manager/Stakeholder asks you to work on, instead of sketching ideas and working them up on a laptop as an individual activity, get people from different disciplines around a whiteboard to discuss how the feature should work. This will help not only with creating a shared understanding but with externalising your work to kickstart meaningful team discussion and collaboration.
• Action 2: Ask what the business problem is
  To ensure you’re able to validate the outcome when the feature is live, ask the Product Owner/Manager/Stakeholder for a measurable success metric. Getting one from the business will help you provide real world examples in the future to build trust, however if they aren’t forthcoming you can define your own metrics based on usage data.
• Action 3: Write down some assumptions
  When the Product Owner/Manager/Stakeholder gives your next feature to design, simply write down some of the assumptions you have about how customers might use it. Doing this will give you the focus in usability testing sessions, allow you to validate your thinking and make changes to the feature based on real user feedback.

Final Thoughts

To get a more thorough holistic understanding of Lean processes and principles my advice is to read the Lean UX book and others in the Lean series. It’s important to note that this guide is to help take those first steps towards a more Lean approach, that’s hard and can be slow. It’s not easy to integrate a whole process right from the get go.

Based on some of my experiences attempting to integrate a Lean UX process I’ve written this guide as a way to make it easier to digest as a concept, to provide some practical actions to start today and in the early stages of that integration.

I’m a Product Enablement & Ops Consultant with over a decade working in technology organisations, enabling product leadership to maximise their performance and impact.

Visit chriscompston.com to find out more.