How user story mapping helps teams stop relying on old designs
Help your team avoid the temptation of going with the first reasonable design.
“Let’s take a step back and ignore what they built.”
That’s what I told my mentee, echoing advice about re-designs my mentor had told me several years back.
Re-designs can mean many different things, and not all re-designs are the same. For example, the idealized re-design might be the second version of an existing Minimal Viable Product (MVP), which continues work that Designers initially did with minor improvements along the way.
However, re-design can also mean re-doing a project that a team built with no UX involvement. When you’re improving an MVP, looking at previous design sketches, annotations, and notes from the past designer might be fine.
You can’t take the approach when Design hasn’t been involved up until now. UX Designers would probably want to work from scratch, which can be hard for teams since there’s something else they can point to.
One of my projects started with a Proof of Concept two years ago, which the developers fully built out (beyond simply feasibility) to get a rough idea of how everything would work.
It was only after Developers fully built the Proof of Concept (POC) that design got involved, which led to problems. The Proof of Concept was the elephant in the room throughout almost all of our introductory sessions.
When UX Designers take notes and make private sketches to understand the requirements, it would be all too easy for team members to open up the POC and point to something. After all, it’s much easier to point to something visual than try and describe the requirements through words.
However, that led to several misunderstandings. For example, one of the initial assumptions about our UX team was that we’d update what the Developers built with better design patterns.
We couldn’t take that approach for two reasons:
Ultimately, the way the project was designed would be largely by Developers
Our team would fall into the Satisificing trap
Don’t make me think, and its downsides
In Steve Krug’s famous book Don’t Make Me Think, he defines the concept of Satisficing in the following way:
“Most of the time we don’t choose the best option — we choose the first reasonable option.” — Steve Krug
Our brains are made to conserve mental resources, so we often go with that when the first reasonable option presents itself. Unfortunately, this sometimes leads to problems in re-designs. An existing prototype, Proof of Concept, or a particular design sketch may seem reasonable enough to most of the team (with you included). As a result, there’s a temptation to cut corners around your design process. Rather than spending time and brainpower doing divergent thinking, where you can question everything about how the website is set up, you might spend most of your time doing convergent thinking. After all, it’s easier to make changes to an existing template than to start with a blank design canvas. You might tweak this with a droplist here, turning mandatory options into optional there or other minor changes.
The problem with this is that ultimately, the way developers (or others) initially thought about it is mostly how it remains. That can be a dangerous assumption to make, and thinking deeper about the entire website, including questioning how these things are set up, is a crucial step of the process.
The team could have the right idea on how users should use the website, but that doesn’t mean they know how it should be designed. For example, the site could be designed based on the first reasonable option that the team stumbled upon, which might be the worst idea.
We know it’s worth it not to be lazy and explore other design ideas. But how can you keep the conversation from turning back to the old prototype when you haven’t had the chance to build anything yet?
To do that, we can enlist the help of an unlikely ally: the Agile user story.
Creating the high-level UX user story
I’ve slowly come to appreciate how Agile user stories are set up.
It seemed like busywork when I first got started with the design process, but it’s been instrumental in helping to get the team on board with making fundamental changes when necessary.
Agile documents and ‘products’ are supposed to be living documents: stories are organized by releases and are essentially crossed off as they are completed.
This organization system means that it’s one of the easiest places to point at to say that your old prototypes (and Proof of Concepts) are outdated. With this organization system, you can easily say, “Yes, this Proof of Concept is a useful visual. But this was built for different requirements two years ago.”
This is a useful reminder to the team that visuals are outdated and that if our requirements have changed, the existing visuals won’t work anymore. However, we often still need to provide something to reference if we want to make sure teams aren’t referring to the old prototype.
This is where UX can create their own high-level UX user stories to keep things in line. I wouldn’t say I liked doing this when I started, but it turns out that high-level UX user stories are pretty easy to put together.
The reason why is because, at its core, high-level UX stories are basically design prompts.
High-level UX stories are like design prompts
https://designercize.com/
In case it’s been a while since you’ve thought about design prompts, they’re basically to get you to think and talk about your process. Some of you might have used tools like Designercize (above) to practice talking about your process for UX interviews.
We should think of user stories in a similar way. The typical format of a user story, in a single sentence, is:
“As a [type of user], I want to [goal], so that [benefit].”
This takes a format similar to design prompts already. The only additional parts of user stories are:
Story points: a relative measure of how much effort is required, and
Acceptance criteria: What a story needs to be considered “complete.”
You don’t know everything when you first start a re-design, and you don’t need to.
Instead, thinking about user stories allows you to create a user-story map of the process, which is a low-effort way of laying out how things might change between what currently exists and the re-design.
User story maps consist of three parts:
Activities: High-level tasks users do in the product
Steps: Steps users go through to complete the activity
Details: Discrete interactions users take to complete a step
Laying this out to the best of your ability is a way of having productive conversations about the re-design without focusing on design elements.
For example, if the re-design is adding new functionality, there might be a new Activity that you need to plan out. Or, if it turns out that the process users use to complete a task isn’t as straightforward as the activity is laid out, there might be steps that need to be changed.
Even though all the parts were the same, we’ve done something important by mapping out these user stories: abstracting the design. For example, team members often refer to the old prototype to talk about a certain feature, how the back end is supposed to work, or other things unrelated to the design.
However, because they see the design in the meantime, they become more familiar with that than what UX Design is creating. As a result, they may often gravitate towards the familiar and ‘reasonable’ (if badly designed) option of the old design rather than anything new.
These user story maps allow us to refer to the process without using the old design. Of course, we might not even know anything about certain Steps and Details, other than what we’d title it at this stage, but doing this allows us to talk about the process with others at a high level.
It also provides us with a Design prompt to help us generate ideas without thinking about what exists. For example, a statement like this sounds like a design prompt:
“As a 50–65-year-old computer novice, I want to find my Search Results, so that I don’t have to waste time navigating through sub-menus to find something.”
We can take those actions and turn them into many different design options. That can be a whole lot easier than looking at an existing design and trying to parse what it’s trying to do and how you can approach this differently.
This also allows us to approach the design with a blank slate instead of thinking about existing design elements, limiting how broad you can design early on.
In this way, our design mockups and sketches have the freedom to explore different ideas, and it allows something to occupy the space for your team to talk about in the meantime.
User stories as an in-between
It can be tough to re-design something, especially if the rest of the team's current design is easily accessible. On the one hand, you have a fully designed prototype or Proof of Concept, even if it’s badly designed.
On the other hand, you might have next to nothing when you’re starting. Unfortunately, this makes it too easy for your team to lean on the ‘reasonable’ option of only making minor updates to the visuals.
User stories can help prevent that. The best user stories are design prompts for divergent thinking and keep the team informed about what you’re doing in this release (instead of looking at old prototypes).
If you’re running into the satisficing trap, try making user stories to help provide a point of comparison and act as design prompts for creating the right design.
Kai Wong is a UX Specialist, Design Writer, and Data Visualization advocate. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.