Agile Experience Design: Setting the Scene
- An agile experience design project
- Agile team structure and the role of the designer
- The agile project environment
- Agile project communication
- Agile project management
- In summary
- Coming next
This chapter is from the book
This chapter is from the book
This chapter is from the book
- “COMING TOGETHER IS A BEGINNING. KEEPING TOGETHER IS PROGRESS. WORKING TOGETHER IS SUCCESS.”
- —HENRY FORD
Let’s begin our journey into agile by understanding what makes agile different from other working methods and how all of this affects designers.
Success. Now there’s an interesting word. By definition, success means the accomplishment of desired aims or goals. Achieving success is the holy grail of any business or project. The pursuit of success is the reason businesses invest time and money; it’s the reason we take risks. This book is about design and we want to look not only at what makes design successful, but also how the involvement of designers on an agile project contributes to the overall project, and ultimately business success.
In this chapter, we’ll take an initial look at agile project management, communication styles, rituals, processes, and environments and then talk about ways to improve the chances of both design and project success by integrating design and designers into the agile project framework.
An agile experience design project
To get an idea of experience design on an agile project, let’s think about what’s needed to get us from the start to the finish. Creating a mental model for these activities makes them easier to understand and apply, so we’ve grouped them into the following five stages (4.1).
)
4.1. Iterative activities grouped together with the agile project framework.
Project activities not definitive gates
There are no hard and fast rules about where you should start or when you need to move on to the next set of activities. In fact, you might repeat some activities in each phase, iterating, testing, and building on previous learnings. Rather than being prescriptive about how long and when, we recommend a more lean and agile approach. Just do what you need to do and then move on. If you find you’re missing information at any given point, you can simply iterate through the activities again and build on your initial findings.
Discover—ask why
We look to gather customer, business, and technical insights that will provide us with the customer and business goals and identify opportunities for inspiration, improvement, and innovation. Often, you’ll find stakeholders entering the process assuming they already know the answers to the why and what questions. Great if they do! Your objective is to get their thinking out on the table to be understood and agreed to by all the stakeholders. Equally, there may be some scenarios where nobody has really stopped to ask why. The idea sounds good on paper, but why should anybody care? Who are the customers and why might they use it? What do they really want and need? If we can’t answer those questions, we’re not ready to think about the how. There’s no point in pulling together a plan if the fundamental proposition isn’t going to fly.
- Gather customer, business, and technical insights that provide insight into customer and business goals and identify opportunities for inspiration, improvement, and innovation.
Envision—ask what
Now that we’ve identified the customer and business goals, we can ask what we need to do to meet them. We don’t want just one solution at the start. We’re looking for a design vision, a direction for the product, with the full knowledge that this may change as the product evolves.
- We place the customer at the heart of our design thinking to produce a multitude of ideas to create different opportunities.
We rapidly test these ideas with the people whose lives will be touched by the product we build for them. Those that are promising we’ll elaborate on. Those that are duds we’ll kill early and cheaply.
The key to our approach is not to spend months thinking. The market is moving on. The decision on how far to go will depend on the context and the maturity of the business. If you’re a start-up, you don’t have the luxury of testing ideas in a closed environment. You want to get stuff to market as soon as possible and adapt as you go. If you have an established product in an established marketplace, you may wish to build a prototype to test your ideas before committing to costly development.
Elaborate—ask how
With a design vision in mind we now look to do just enough to start development. We elaborate on the vision and plan what we’ll need to do to get a product into production as quickly as possible. We’ll agree on a first cut of the project scope: what the desired customer journeys are, sketches to illustrate screens, and user stories that are estimated and prioritised.
Develop—let’s do it
Agile software development is a social activity. No longer does the designer throw artefacts over the fence in the hope that they may be delivered; in the agile process the designer is a member of the team. She works closely with the business analyst to clarify the stories just ahead of when the code is written. Indeed, sometimes the developers start coding before the design is done.
- We think about the critical path and, as in lean manufacturing, produce our design inventory just in time.
Clearly, we can’t always work in this way; we may need to iterate our ideas before coding starts. Alongside the development iterations we’re spiking design options, working up different options to test and validate in a safe environment outside the main development effort. Testing is key. Usability testing is not a formal procedure done at the end of the project; it’s baked in from the start.
Evolve—continue to improve
Once your product is in the hands of your customers, you can really start learning how to make it better. Up to this point you only have a bunch of hypotheses about how good it could be and how it should work. The idea is that you release the first cut of your product and then continuously enhance it, learning what works and what doesn’t, and evolve the product to make it ever better.
- IGNORANCE IS THE SINGLE GREATEST IMPEDIMENT TO THROUGHPUT.
- —Dan North, Agile troublemaker, developer, originator of BDD
Unlike the past, when software was brittle and the cost of change meant you had to get it right the first time, today software really is soft. Focus on what is important to your business and to your customers and get something to market fast and early, even if it’s just a pilot beta with a small, invited panel of trusted loyal customers, and let real behaviour and customer feedback inform your decisions.
- You then seek to continuously improve your product through a process of test and learn.
You can learn subjectively through usability tests, customer surveys, and the like, and objectively through analytics, split testing, and so on.
Removing uncertainty
Think of a time-boxed period where we do just enough to get the project started. Or changed. Or cancelled. We want to create models that we can test and validate at speed. We want to produce a design vision of where we want to go and elaborate on that vision to get us going.
When we start a project it looks something like this (4.2).
)
4.2 The line of uncertainty.
There’s a line of uncertainty. In fact, we can only really be sure of three things:
- Change is inevitable and things will go wrong.
- We can’t know what will change and what will go wrong.
- When things go wrong or change is required, it will cause us pain and suffering.
Rather than being oblivious to these truths, producing a watertight vision that everyone believes will be delivered in its entirety, or trying to second-guess how things might change or what might go wrong, we should create an environment in which we can explore areas where we have the greatest uncertainty and try to mitigate the risks. Based on this principle we have two options:
- Do just enough that is good enough to provide us with a direction that we all agree is the right one based on the information available today.
- Be ready to kill the idea early or change, pivot, when the available information tells us this is the right thing to do.
When thinking about a project, we need to be mindful of those three questions—why, what, and how—before we do or evolve. So let’s overlay those questions as a funnel on top of the line of uncertainty (4.3).
)
4.3. Using the model to reduce uncertainty through the product development life cycle.
Unlike the familiar approach to interface design, which can take a leisurely approach to what to build, and agile, which is quick to focus on doing the actual build, agile experience design brings together the best of these two approaches, providing a framework to remove uncertainty and do the right thing.
Activities, not a process
We use this framework of discover, envision, elaborate, deliver, evolve to reduce uncertainty. Don’t look at this as Gantt-chart-driven phases with deliverables due before the next phase can commence. These are activities to clarify thinking and product direction, not a prescriptive process. They may happen at the same time; you discover and envision new ideas as you develop. You may spend only a day in research, and a couple of days distilling your insights into a vision and elaborating requirements to start development. How you work will depend on the team and your environment. Take this framework as inspiration and adapt it to what works best for you, continuously improving as you evolve.
The last responsible moment
Whenever you start work on a project there are choices and options that you’ll make on the way. Of course you want to make the right decisions. But the right decisions will be based on having the right information, and at the beginning of the project, it’s unlikely this will be the case. It’s easy to give yourself a false sense of security by basing your design work in detail on assumptions.
Here’s an old joke: A man is driving in the countryside and is lost. He asks a farmer for directions and the farmer says, “If I were going there, I wouldn’t be starting here.”
People often think there is only a right decision or a wrong decision. What they miss is the no-decision option. Sometimes we don’t need to make a decision at that moment. It is possible to defer it to a later time, when you’ll know more and be able to make a more informed decision.
In his book The Toyota Way, Jeffrey Liker describes how Toyota developed the Prius. With a tight time frame and a vague goal of developing a “fuel-efficient, small-sized car,” the team:
- Tested over 20 different suspensions simultaneously.
- Worked on 80 different hybrid engines before whittling them down to one.
- Started with twenty designs and then, through a design competition, selected two that were revised based on feedback before a final design was chosen.
The point is that the team didn’t fixate on one particular solution too early. In fact, they simultaneously pursued a number of different options to rule out the bad and go with the good. Sure, there was a short-term cost, but greater rewards were reaped later.
It’s all too easy to decide on a particular direction and get fixated on it.
- Thinking about our process we could continue to explore different options and only decide which one to take at the last responsible moment.
Beyond that moment the option expires (4.4).
)
4.4. Defer the decision until the last responsible moment.
This is one of the most fundamental concepts in agile experience design. Don’t make decisions unless you have to. Don’t spec out the user interface in detail until that detail is required.