Essential UX Layers for Agile and Lean Design Teams

It was puzzling to see how our team was so wrong in this design. At the time, it had seemed like the team made all the right decisions. But now, seeing the real users interacting with it, our only excuse is we just didn’t know what we were doing.

This little piece of the design wasn’t really important in the scope of things. It’s just a piece of functionality the team threw in, practically at the last minute before launch.

Yet now, before our very eyes, this little piece of design was frustrating the shop owner. In the past week, we’d seen five shop owners frustrated by basically the same piece of design. It was hard for the team members to watch, yet even harder to take our eyes away from it.

The problem to solve is simple: The owner of this tiny shop, which sells fewer than 100 items on its shelves, has just received a new shipment of products. The owner’s task is to enter the items into the system, updating the inventory, so the cashiers can ring up charges as customers buy the stuff.

However, it was complicated to add the 15 new products in this box. Click here, type that, verify this, dismiss that other thing. The owner has to enter the order in separately from receiving it, turning a simple process into 2 steps. Most owners we watched didn’t do that, instead twiddling the inventory stock values, often incorrectly, making the balance sheet inaccurate.

What should be a five minute process was now 15 minutes. Even worse, we saw several shop owners skip the process altogether. Their future reports and dashboard readings were incorrect which, in turn, was making their cashier’s life more difficult and error prone.

This little piece of the design needed an overhaul. And this time, the team would do a much better job.

Working UX Into an Agile World

In the shift from a waterfall project management style to something more agile and lean, we saw the elimination of the Big Design Up Front stage, where we thought everything through. Truth is, that stage never got us great results anyways, so good riddance.

But the void left by eliminating Big Design Up Front is that it’s harder for the team members to get the big picture they need. The result is a deconstructed design process where everything is broken down into such little pieces, which, when reassembled into the final experience, becomes frustrated by the users.

While many teams have struggled with the move to these new processes, some teams have made the jump successfully, producing experiences that are really delightful and productive for their users. We’ve been studying these teams to learn what they’re doing differently.

The User Story Layer

Most agile processes center their design on the user story. Often, to make the design better, teams adopt a format for these stories that looks similar to “As a {user}, I want to {task}.” For example, a typical story might read, “As a shop owner, I want to enter new products into inventory.” The team members working on the inventory check-in functionality would go off and create a design to do just that.

We discovered that teams need to be thinking about the user story. Turns out, we found that many teams had other layers they were also considering.

The Scenario Layer

The user story could be one of many stories that fit into a larger layer of user scenarios. Scenarios are specific stories that happen to users. For example, a scenario might read,

“Armando, our shop owner, has ordered 10 packages of vitamin supplements to replenish the stock from existing sales. He ordered them directly from his distributor’s web site, paying with his company credit card. Two days later the order comes in and he wants to get them on the shelf as soon as possible, both to sell them and because it irks him having unpacked boxes sitting around.”

A scenario, like this one, could have several user stories, including discovering that the items are running out, creating alerts, and producing reports. Ideally, the scenario isn’t something the team just imagines. Instead, it’s something the team members commonly saw when they were out doing their research with real users, packaged up neat and tidy to make it easy to extract the user stories.

The Persona Layer

In the story above, we talk about Armando, the shop owner. Armando represents one of several types of people who had issues with the inventory system during our research. We didn’t actually meet someone named Armando—he’s an amalgamation of several shop owners we did meet.

Armando is a persona the team might create to capture the scenarios for those users. A given project may have several personas the team is designing for, each with several scenarios for the project.

(There’s a school of thought that says you don’t need to create amalgamated prototypical users with fictitious names and stories, just describe real users. In our research, we’ve found both techniques can produce great outcomes. It’s just two subtle approaches, like the difference between a salad fork and a regular fork. You pick the one that works easiest in that instant. Choosing the wrong one probably won’t have noticeable effects.)

Personas, like scenarios, work best when they’re based on real research. Ideally, everyone on the team has met many of the real people who influenced each persona, seeing them work with the design, which, of course, feeds into the scenarios. Because they know the real people and activities behind the personas and scenarios, they can easily translate the research into the design decisions.

The UX Principle Layer

In the case of the inventory check-in problem, there were some key patterns the team identified about the existing design. First, the original design focused on a big-company-style solution of issuing purchase orders separate from checking in inventory, while nobody we visited ever issued purchase orders. Second, the design didn’t accommodate the busy life of the shop owner very well, making them go through unnecessary steps. Finally, the design of the forms involved weren’t organized in a logical fashion and had many fields that most users would never need.

From these three key patterns, the team could establish some simple, yet effective UX principles to guide the upcoming redesign efforts. These could be:

1. Think small and fast. Don’t force big company business company processes on a small business.
2. Allow for interruptions and quick entry. Let the user stop in the middle without losing their place.
3. Put the most important stuff up front. Use progressive disclosure techniques to reveal less important or infrequent functionality only when the user desires it.

The team would create these principles directly out of their research with users and the problems they observed. However, it’s likely that similar principles would keep reappearing in different projects. That’s because, at this layer, we’re looking across lots of different personas, scenarios, and user stories to create a coherent overall experience.

The UX Vision Layer

As the most general of the layers, the UX Vision looks at the biggest picture: what could the user’s experience be like in the future, say five years from now. It’s this vision that would help the team choose the principles, hone in on the specific personas and scenarios, and craft the right user stories to get the best design.

Ideally, like the other layers, the vision is borne from research. As the team meets a range of users and sees the sum of those users’ activities, they’ll get a good sense of the most delightful and most frustrating parts of the current experience. The team can create their UX vision by looking beyond current constraints of legacy systems and their gnarly code base, to a time where the frustrating parts could be converted into additional delightful experiences (or removed completely).

By ironing out the frustration, what would the resulting delightful experience look like? What would be the core attributes behind it? This is what drives the UX Vision for the team.

Everyone on the Same Page

As we studied the differences between successful and struggling teams, we saw a big difference came with how they approached the different layers. The struggling team might discuss the other layers briefly, often at the outset of the project, but focuses most of its time managing the user stories as a way to rush through development.

However, we frequently saw the successful teams talking about these other layers all through development. When a team member would produce a deliverable or design sketch that wasn’t quite matching the direction that the other team members imagined, the team would step back and talk about the other layers, trying to figure out where the disconnect came from. Because the team established the layers together, based on research they jointly conducted, they found it easy to collaborate on creating coherent experiences that regularly delighted their users.