Integrating a Lean UX Process
By: Chris Compston
Tags: Design, Process, Lean Startup, UX, Agile

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