Our flag in the sand — How to escape the desert of user needs by integrating agile and user experience

In 2021 I attended a series of online webinars by Jared Spool called Taking Control of Agile UX. I have long been an advocate of agile ways of working. One of the things that originally drew me to user experience was the opportunity to have evidence-based ways of understanding the changes you need to make.

So I was surprised whenever I encountered people who believed that user experience methods ran counter to the principles of agile. It is a consistently hot topic that causes unnecessary frustration for everyone concerned. So I was keen to see what Jared Spool had to say on the topic, and what I could share with my colleagues.

I found this webinar series inspiring. It gave me new ways to describe the opportunities I see in integrating user experience principles with an agile approach.

During the webinars I took 18,254 words of notes, which I later condensed to 4,516 words. Then I turned it into a 100 slide, hour-long presentation, synthesising and reworking about 8 hours of webinar content, mixing in a lot of my own perspectives along with some other sources of inspiration. The result was a story about using user experience approaches to escape the desert of user needs.

I have presented it to colleagues in my previous two jobs, and have received positive feedback about it. So I am now sharing it more widely, as a 2,527 word blog post.

To reiterate: This reflects my own perspective and opinions about the opportunities of agile and user experience. But it was heavily influenced by 8 hours of webinar content delivered three years ago by Jared Spool. But I took a huge amount away from the series, and if you want to dive deeper I would highly recommend attending Taking Control of Agile UX for yourself to learn directly from Jared Spool.

The sections about the Kano model have also been heavily influenced by Sophie Dennis’s 2015 conference presentation, The art of things not done.

---

Welcome to the desert of user needs

We have all been there as user experience practitioners, working on a project but finding it difficult to advocate for users and their needs. As a project team, we find ourselves in a desert of user needs.

Hill charts show that we all plan our work, then we do it

This sand dune is actually a hill chart. Some web developers work with hill charts as a way of showing the progress of their tasks.

The idea is that there are two core phases of a work task. You first need to spend time figuring out your approach, and how to solve the unknowns in the problem you face. Once you have figured it out, you are standing at the top of the hill. Then you enter the second phase of work, and begin to execute.

In other words, you start by researching and planning your work, and then you do it.

We work with unknowns and knowns

There are two sides of the hill.

On the left side, we are working with unknowns.

On the right side, we are working with knowns.

As we start from the left and climb up the hill, we are figuring things out.

Climbing back down the hill towards the right, we are making things happen.

Progress is not always linear. As we make things happen, we might discover new information we hadn’t considered, requiring us to go back and do a bit more planning. But eventually, we will execute the task and reach the bottom of the hill on the other side. Then the task is done.

Do the right thing and do the thing right

To me, hill charts clearly align with the double diamond design process. The first diamond is thought of as understanding how to do the right thing. The second diamond is about how to do the thing right.

In other words, you start by researching and planning your work, and then you do it. Just like hill charts.

Shared understanding of the definition of done

The problem comes when people don’t have a shared understanding of what done is. Not everyone may agree that we have reached the bottom of the other side of the hill.

In many engineering-focused teams, done is understood from a strictly technical perspective.

But to user experience practitioners, done must also be understood from users’ perspective.

Focus on outcomes

We understand done from the users’ perspective by focusing on outcomes. In user experience, we are seeking to improve someone’s life. For our work to be considered done, we must see that improvement in someone’s life.

We understand the outcomes our users need through conducting user research.

This cannot be done by squeezing research into a sprint.

Structure of an agile project

In our desert — or agile project — there are many of these hill chart sand dunes. Each of these represents a task.

These tasks are part of a sprint.

Each sprint is a subset of a release. There will normally be multiple sprints within a release.

A release is part of the roadmap.

The roadmap leads us to our vision.

Our vision is our flag in the sand.

Adapting to shifting sands

Our vision is a flag in the sand rather than being fixed because the sands might shift in our desert. Agile is partly about responding to change. So if the sands shift, we have to be able to pick up our flag and reposition it.

Giving direction to our velocity

Agile teams often talk about velocity. This is often thought of only in terms of speed.

But remember that velocity is actually speed + direction.

Our flag in the sand is what gives the direction to our velocity.

How our roadmap leads us to our flag

Each sprint is an adjustment towards our flag.

We must populate our roadmap with problems to solve, not features to build.

Feature focus will lead us to a dead end.

Solving problems and improving people’s lives will lead us towards our flag — our vision.

Metrics in the definition of done

Looking for evidence of the improvement in people’s lives is crucial in knowing if we are heading towards the flag, or going in the wrong direction.

Organisations often look towards traditional business metrics to measure success. Business metrics are about the engine of business. Things like retention, sales, new customers.

These are indicators that the business’s engine can keep going. But they are not often good at measuring quality.

User experience metrics instead look for and measure the improvement in someone’s life. Measuring this is key to our success at meeting people’s needs and improving the user experience.

User experience outcomes work best when they come from a deep, shared understanding of our users. We can’t just look at numbers to tell if we are successful. This has to start with qualitative research. This tells us what outcome is needed.

Measuring success and progress

There are different types of metrics we can use.

Success metrics tell us when we have achieved the desired outcome. This is the party moment.

Progress metrics tell us how we are moving towards the desired outcome. These are the milestones on the way to our flag.

This is like objectives and key results (OKRs).

Success metrics (or user experience outcomes) are our objectives.

Progress metrics are our key results.

This is now our tracking mechanism. These metrics are part of our definition of done.

Problem–value metrics

Problem–value metrics reflect a cost the organisation has. They are things like increased support costs, training costs, and costs spent on developing the wrong thing.

Can we make this ongoing cost disappear through improved user experience?

Will it be better to fix it rather than continue spending money on increased support and training costs?

These metrics can be part of our key results.

Journey maps help us prioritise

Journey maps show the touchpoints users encounter, plotting their experience from frustration to delight at each point of their interaction with our service.

Our job is to make things less frustrating, and more delightful.

This is the user experience outcome. When we do a great job on this work, we are improving someone’s life.

We therefore need to understand what is blocking us from making these improvements. What prevents us achieving the desired outcome? These are our problems to solve.

Identifying blockers with the Kano model

The Kano model helps us identify those blockers and our problems to solve.

It uses the same y-axis as the journey map, from frustration to delight.

But it takes a focus on product features, with the x-axis showing the level of investment in making these features.

There are three main different types of feature in the Kano model. These different types of feature have a different impact on the user experience based on the level of investment.

Understanding these different types of impact on the user experience tells us what we need to look for in our user research.

Satisfiers

Satisfiers are otherwise thought of as assumed expectations.

Investing more in these features makes the user experience gradually more delightful.

In a car this might be:

• Fuel efficiency
• Engine power
• Boot space

But with this type of feature you need to beware of feature creep.

If you add too many of these features, it becomes bloated, and detrimental to the user experience.

In a car this might be:

• Bubble dome
• Shag carpet
• Horn that plays La Cucaracha

This is Homer’s car.

User research has to look for evidence of feature creep to avoid our product becoming too bloated and hard to understand.

Basics

Then there are basics, otherwise known as universal expectations.

With this type of feature, investment starts high, and only creates at neutral satisfaction at best.

But if you are missing these features, your users will be frustrated.

You can’t win by focusing on these features. But you will screw up by not investing enough in them.

In a car this might be:

• Brakes
• Tyres

User research has to look for missing expectations — the basics we have left out — to make sure we are not screwing up the experience.

Delighters

These are the excitement generators.

Even unsophisticated versions of these features will produce delight quickly.

In a car this might be:

• Self-parking function

Delighters come in three forms:

• Pleasure
• Flow
• Meaning

Pleasure

Create pleasure by taking the basic expectations and exceeding them, by making them work a little better.

An example might be a warm cookie when you arrive in your hotel room.

This is the easiest way to find delight.

But pleasure goes wrong when we don’t meet the basic expectations.

A cookie in your hotel room won’t delight you if the toilet is overflowing.

Flow

Flow is when users are spending more time doing something of value to them, and less time on tool time.

Tool time is time spent on using the interface, or a bureaucratic requirement.

Flow is the most common place to find delight.

Flow is the oasis in our desert of user needs!

But it goes wrong when when we don’t give users control.

Removing the wrong parts of the interface causes frustration.

Meaning

You add meaning when your product actually improves someone’s life through feeling a strong connection to the benefits your product creates for society.

This is the hardest way to find delight.

Meaning goes wrong when it is inauthentic.

You have to actually mean it, otherwise users will see through it.

Sands shift in the Kano model

Delightful features do not stay in the same category for long.

Over time, delighters become assumed expectations, which in turn become basic expectations.

In the past, sat-nav in a car was a delighter. Over time it became a basic expectation.

In the future, self-parking will become a basic expectation.

Think back also to the example of providing a cookie to hotel guests at check-in. If you then stop providing that cookie, your regular customers will become frustrated — because they had come to expect it.

Kano model inspires us to understand outcomes

The Kano model helps us see how our work actually improves people’s lives.

It also helps stop user research slipping into just aimlessly watching users.

Our user research should be focused on looking for:

• Feature creep
• Missing expectations
• Pleasure
• Flow
• Meaning

We can all make this happen

Everyone can become more human-centred. User research is a team sport.

Not everyone thinks they are a designer. But all of our decisions can impact the user experience.

It’s not just the job of a user experience team. We can all become more human-centred.

So let’s reach this outcome together!

Reaching mastery

Our job as user experience practitioners is to help our teams reach mastery in improving user experience.

We need to move our teams through three stages of competence.

Literacy

Literacy has us moving from unconscious incompetence to conscious incompetence.

In other words, we begin to understand what we don’t know.

This stage is about knowing the difference between good and bad design.

Fluency

Fluency has us moving from conscious incompetence to conscious competence.

At this stage, we are learning how to use tools and processes.

Mastery

Mastery has us moving from conscious competence to unconscious comptence.

This stage is sees us producing great outcomes by going beyond established best practices.

We have the tools in our toolkit

We have everything we need to help our teams become masters at improving user experience.

Exposure to users

We can put our work in front of users, watch them and understand them.

Critique

We learn from other team members how they got from point A to point B in their work.

Comparison

We can pull apart other organisations’ designs to understand them.

Stand-ups

Where people talk about their work, and what they did differently the day before.

Collaborative sketching

Where everyone sketches their ideas to have a conversation and share a vision.

Review the rationale of designs

When we talk about why we make the decisions we make. These rationales become our principles.

All of these activities can be built into a sprint.

Spend 30 minutes a day helping your team make more human-centred decisions.

5 mindset shifts for successful agile user experience

1. Agile user experience strategy is a long-term game

User research cannot be squeezed into a sprint.

Sprints are adjustments to our long-term vision.

2. Strong user research is central

Exposure time is key. Get the team watching users for 2 hours every 6 weeks.

Tie every story back to research, so there’s a shared understanding of what’s going on.

3. Research is continuous

Don’t just research in little spurts for the sake of fitting it into a sprint.

Work with stakeholders to understand the highest-risk decisions that need a human-centred focus.

4. Put human needs into the definition of done

Go beyond the typical user story.

We need to ask ourselves: If we do a great job, how will we improve someone’s life?

Measure the cost of frustration — remember those problem–value metrics.

5. The whole team can become more human-centred

Anyone can carry out user experience work.

The whole team can become more literate and fluent at producing great designs.

So let’s escape the desert and head for the flag!

Then, we can have our party moment.