Lean UX and the Language of Change

Claire Jaycock, Senior UX Designer, BNZ, @deksinspace
Anthony Boobier, Lead Practices coach, BNZ,@antboobier

As a senior UX designer and agile coach, Claire and I would often talk about ‘what’ we did and ‘how’ we did it, but rarely stepped back to ask, ‘why?’ Why do we do Agile or Lean? Why do we do a particular practice or framework? Why do we decide to build a particular feature?

The easiest way to enact change is to get people to move to a place where they always wanted to be; the message we used to show that shared place was Lean UX [1]. This is about how we came together to introduce Lean UX at BNZ and how our biggest insight was the power of the language and the vocabulary we use. How language has a massive impact on our mental models and the way we view the world. Language can inspire and unite, it can also confuse and alienate. The vocabulary we used as part of Lean UX worked on a tribal level to empower teams to make better decisions through getting people to unite behind the ‘why’ not ‘how’ or ‘what’

Language of change

When Claire and I first started working together at BNZ Digital, the delivery teams were doing agile, the UX designers were all lean, except for those product owners (POs) and the UX researchers that were doing human centered design… hang on! Because we were focusing on our own set of practices and how we did things, a lot of time was spent in philosophical debates with each other over what was better: ‘Agile’ or ‘the Lean process’.

Trying to convince people that ‘your way of working’ is ‘better’ than ‘their way of working’, is stressful. Like Simon Sinek’s Golden Circle’ [2]. We realized we were all too busy focusing on ‘how’ we do things, rather than ‘why’ we did them.

We agreed that agile is not about practices, it is not about stand-ups, velocity and flow. It is about people. When we start to communicate with the “why?”, it inspires others and enables positive collaboration and change to occur. The core ‘why’ vocabulary we used and focused on were:

• Customer
• Problem
• Opportunity
• Assumption
• (In)validate
• Not now
• Experiment
• Outcome

This was the language we already used, but what we did was amplify it. We focused on this core set of ‘Why’ words that we could all agree on. These words are fundamentally the reason we do agile, lean, or any customer centric, people oriented approach. It is an empirical process of Build-Measure-Learn that enables us to both deliver value and discover what is valued.

There is a customer that we want to solve a problem for, or deliver a valuable opportunity to. So we start with some assumptions as to what may successfully achieve that outcome, we then run rapid experiments and measure the feedback to validate or invalidate them and ensure we are making progress toward achieving it.

Language is tribal

Language creates a shared identity and unity [3]. But that identity while bringing people together can confuse and alienate people who aren’t part of that core group. We found that by introducing a new vocabulary focused on the ‘why’, rather than ‘how’ and ‘what’ we build, we could create a shared understanding among our teams. We could empower them to articulate customer problems rather than software requirements

By doing this, we shifted our focus from the practice and framework (the what and how) to the outcomes and success for our users (the why). the things that our teams were passionate about and motivated to achieve.

Lean UX the vehicle for change

What we needed was a vehicle for change, something that would give us a shared identity as a group. Enter Lean UX and the opportunity canvas [4]. This was an approach we could all get behind and were enthusiastic about. It encapsulated the essence of ‘why’ we all did ‘what’ we did.

The most profound thing we found when we embarked on our Lean UX experiment was that language drives change. If we use the language of ‘why’, we can unite and bring people together.

Customer

Customers are at the heart of everything we do. This seems obvious, right? Yet all too often we assume shared understanding of who our customer or users are. What their needs are, why we’re building a feature for them - and that they even care about it. We have to remember we are not our customer. The focus needs to remain steadfast on the difference we hope to make for them - not on how we are building the feature.

By understanding and building a relationship with our customers, we can better understand their needs and the root cause of their problems. It allows us to create a better solution, rather than become entangled in what might be the best framework or technology.

Our customers don’t care about how we do it, they don’t care if we do use Agile or Lean. They care about the value we deliver, or the problem we solve for them that makes their life easier.

This enables the product delivery team to embrace a mindset of experimentation; of rapid feedback loops of Build-Measure-Learn feedback loops. A mechanism to challenge our opinions about the people we are delivering to, and ensure they are getting the best outcomes.

Problem (or Opportunity!)

We encourage teams to feel passionate about a problem or opportunity, not features. By getting the team to hone in on the problem or opportunity we were looking to seize, it sets the scene and provides context. It also shifts the emphasis from being a ‘feature factory’ to adding value in new ways.

Software may not always be the best solution. Part of our role as coaches and leaders is making sure teams don’t feel like frauds if they come up with an idea that isn’t software related. We are ‘value teams’ looking to solve a problem, not ‘technical teams’ looking merely to optimize delivery of a feature. This is much more motivating for the teams.

Assumption

This was our most empowering word, and formed the bedrock of our change. The first thing we do on any new piece of work is get the wider team to explicitly declare and prioritize some assumptions by impact and uncertainty [5], classifying them as follows [6]:

• Problem (does the need exist)?
• Solution (does our idea solve the problem/realize the opportunity)?
• Implementation (can we actually build the solution)?

Following these classifications the top two assumptions we call out first are:

1. Our customers need this opportunity or care about this problem
2. We need to build a technical solution

That means the first thing we do is ‘Learn’ rather than ‘Build’. This was hugely liberating for the team because were not relying on someone’s confidently delivered opinion as fact, a best guess wrapped up as a given (often referred to as a requirement). It is easy to take a confidently delivered opinion as fact, especially when that person has authority.

It creates the startling realization that the team starts with imperfect knowledge, that it is OK not to know everything up front. It removes the perception that there is certainty where none exists. Using the word assumption, makes people relax, and creates a supportive environment for a product team. We are on the journey of discovery together. There is no criticizing someone’s work or idea, we are treating everything as a set of assumptions that are worthy of further investigation. We don’t start a new idea by sizing up the work; we start by weighing up assumptions.

(in)validate

Assumptions empower everybody to respectfully challenge everything we do. Assumption give the team permission to test an idea, to validate or invalidate it. This enables the team to ask the question ‘what would an experiment look like?’ We tend to categorize our experiments into one or more of these areas [7]:

1. Talk to a customer
2. Prototype something
3. Gather some data
4. Put it in production!

We don’t expect to validate everything because in theory 50% of our experiments should be wrong and invalidated. The key for us is to balance the speed of learning with delivering of value to our customers -

Speed of learning

vs

Value to customer

Not now

There is no rush to get one big thing done. By using the language of ‘assumptions’ which need to be ‘(in)validated’ through feedback, it gives the team permission to pause while they gather data. It allows them to move onto something else in the meantime.

Experiment

This is where the word ‘experiment’ comes in. The word frightened the bank’s risk team at first, because it implied uncertainty. It was an unfamiliar word with its own baggage and connotations. We had to explain to them (and prove over time) that an ‘experiment’ was a controlled, low risk, scientific approach to learning.

This enables to team to think about what the minimum amount of work they can undertake, to learn something or deliver enough value. Teams now ask ‘what would an experiment look like?’

Measure

A word that struck fear into people was ‘measures’. It became emotive and got people got very defensive. We came to realize that when we talked ‘measures’ we needed to categorize them into two broad areas; ‘Delivery health’ and ‘Outcomes’ and reiterate it was not about the individual, or the story points.

Delivery Health

This covers our delivery capability, how predictable is the way we deliver, the quality of what we deliver, how do our people feel and is our way of working sustainable. It also covers outputs and features delivered. The core measure for us though is always the outcomes we are looking to achieve [8].

Outcomes

We communicate and focus our language around outcomes, rather than outputs. Outcomes are the most important as there is no point in us going faster if we are going in completely the wrong direction.

Measuring our customer’s behavior and what they do with our products, drives our feedback and what we should focus on building next. Once we know we are onto something, then we can look to invest in scaling it. This distinction helped get the teams to own their own measures linked to their mission statements. It ties in with ‘why’ they exist as a team as what was their purpose is. After all a team is a ‘goal oriented social unit’

Stories

This language created a connection for us as a group, and once we had success with Lean UX we could tell stories using this vocabulary. Stories of successful outcomes using Lean UX that reinforced ‘why’ we do ‘what’ we do. One such story that resonated was:

“The most exciting outcome we have seen, is where a piece of work gets canned, downsized, or put on hold until we can get more information. We experienced this when an audit logging feature that had been sized at around 12 months work was shelved when we called out an assumption of ‘our customers want this’. It sounds simple right? But all too often we could have charged ahead and built that feature in an efficient way. Delivering it iteratively and incrementally and then patted ourselves on the back, without ever questioning if it was the right thing to do. That isn’t very ‘agile’. It turned out customers weren’t bothered about that feature, they were just as happy to receive a simple PDF report. The team saved 12 months and quickly moved on to delivering value to our customers elsewhere”

Stories of success, that use a common language, are a great way to inspire and spread the change even further.

Powerful Questions

Powerful language leads to powerful questions. By using this vocabulary, we have heard less questions like; ‘what is your velocity?’ or ‘how many features can we deliver before we release?’ Now we hear more of:

• What is the problem you are looking to solve?
• Who is your customer and what do you think they need?
• What assumptions do you have?
• What is your measures of success?
• What does your next experiment look like?

The whole team cares - not just about the technology, quality and framework we use - but also about the customer, the outcome, and the product they build. Teams have input into what we build and how we build it.

Conclusion

The core vocabulary we introduced as part of Lean UX is about the language of relationships. Not only to our customers and to the products that bring value to them, but also the relationships that connects different delivery disciplines to ‘Why’ we all do what we do. This has resulted in the wider team working much more closely together, becoming much more empowered, and more accepting of each other ideas; overall it has been a great outcome!

References:

1. Jeff Gothelf http://www.jeffgothelf.com/lean-ux-book/
2. Simon Sinek https://startwithwhy.com
3. "Tribes: We Need You to Lead Us", Seth Godin, Portfolio, ISBN-13: 978-1591842330
4. Jeff Patton http://jpattonassociates.com/opportunity-canvas/
5. https://blog.revelate.de/uncovering-your-riskiest-assumptions-21e7a9cecd1a
6. https://medium.com/@evie/the-power-of-the-assumptions-workshop-74c60e48d093
7. Dual-track development https://nomad8.com/dual-track-development/
8. Gojko Adzic https://gojko.net/2013/02/13/the-february-revolution/

---

Related software development articles

Lean UX in Public Sector? - Part 1: Deciding Our Way of Working

Lean UX in Public Sector? - Part 2: Getting our Facts Straight Before Implementation

The UX Runway - Integrating UX, Lean and Scrum Cohesively

---

Click here to view the complete list of Methods & Tools articles

This article was originally published in July 2017