Nothing felt out of the ordinary. It was a normal Monday, and we were presented with the roadmap for the next three months. It was filled with no surprises; everything was rolled forward from the previous quarter or pulled from the backlog. But one of the ideas intrigued me.
“What’s this feature?” I asked the product manager.
“Oh, I’m excited we’re finally getting to this,” he responded. “It’s been highly requested and will greatly improve our product.”
I nodded and got to work doing my normal background research before diving into designs. I started by spelling out the problem statement and what kinds of users had this issue. But then it got a little interesting. When I started doing the user flows, I quickly realized this problem was a tiny piece of a much greater problem.
I went back to the product manager with my thoughts. “This opens a can of worms”, I told him.
I proceeded to show him that if we were going to rebuild the user flow for this feature, there were a dozen other features we’d decided to postpone as well that we could solve at the same time.
In other words, we had a much bigger question to answer: was it really worth pulling this one little problem out, or was it time to start thinking about all of the facets surrounding it? Because if we were to take the user flows seriously, we’d have had to tackle much larger issues that would have required more people and time to consider: UX, product, and developers all collaborating and considering the ramifications.
“Let’s look at the user feedback that drove getting this feature on the roadmap”, I said.
It didn’t take long for us to realize that this wasn’t as highly requested as we’d first thought. In fact, the requests were over a year old and from specialists, not the average user. Half an hour later, we closed the ticket and decided it would be included in a later, much larger discussion.
Conversations like these save a company tens of thousands of dollars, if not hundreds of thousands. Imagine if I’d gone through the steps of creating a design and had developers build it, only to realize it was solving a tiny bit of a larger problem that we would have had to eventually redo any way. Not to mention it wasn’t even that highly requested in the first place!
It saved us months of precious development time, as well as UX resources, and it all came about because of doing a proper user flow.
On another project, I was asked to come in and give an hour of quick advice for something already built and in use. It was a training tool for developers to grow in their skillset. I looked it over. The design was clean. It followed modern guidelines and looked usable. No problems there. I sat down with the developer and said, “Let’s do a story map and see what we can improve.”
Never having done one before, the developer watched as I shared my screen and used a tablet and stylus to whiteboard a basic user flow, constantly checking in to make sure it was on track. It was a simple one, with only five steps and a loop. In the end, I asked him, “How does our current design help people go through this?”
The answer? It didn’t. Instead of going from A to B to C to D to E, then back to A, the user was going from A to B, then back to A to C, then back to A to D. At E, rather than having an incentive to go back to A, they felt like they finished.
“Look,” I said. “What other things have you used that have this same flow? How can we clean up this design to match this user flow?” In less than a minute we came to a realization: it was the same user flow as a lot of simple video games. If we were to use gamification, we could vastly improve the design and make it more fun and interactive as well.
Red Ball 4
We left the session inspired and eager to get back to designing and improving the app.
User flows were all that were needed to turn that project from a clean but stuffy design into something appealing with a flow that kept users engaged.
So, what exactly is a user flow and how do we leverage them?
Begin with the end in mind
Don’t start working on a project until you have the complete picture of where it is headed. If we fail to do this, we can make some major architectural mistakes early on that are gnarly to fix. Why build the system on a complex data structure that requires expensive server speeds when the whole thing could be delivered in a simple interface in the browser’s memory?
I see this often when I come into projects halfway. Sadly, this is oftentimes when UX is brought in. The way of thinking goes something like this: all that backend architecture stuff can be worked on immediately. Let’s bring in the front-end designers when we’re ready to start on the front-end development.
The challenge with this thinking is UX isn’t just about an interface, it’s about the entire system design. A challenge can be solved in a wide number of ways. Here’s an example, not a real one but reflective of what I see happen all the time.
The company wants to develop an app for monitoring weather stations. They proceed to develop a robust database that stores historical weather information and a map interface to drill into any region. The bonus with this infrastructure is that the user can generate helpful reports to make sense of the data over time.
If we were to all just jump in and start working on this, right now, we’ve made our first crucial mistake. What do the users really need? Did anyone ask? A quick poll finds out the 95% use of the app is purely to see what the weather is in different spots at once. No need for historical data. Not that we can’t store that by sending it somewhere else in the future, but the app can be pared down to essentially a simple weather station app like you’d find for free on your phone.
Ambient Weather app
This kind of insight is priceless. It completely changes what the backend developers work on. And it saves a ton of money from building unnecessary features.
If everyone working on a project has a picture of where it’s headed, then chances are much higher that the end product will get there. In order to do that, UX designers use a tool called story maps.
These are commonly used in the film industry where someone sketches out cartoon panels for a scene.
Story map of Ant Man
The same needs to be done in software. What is the user’s end goal and what are the steps to get them there? It’s important to keep this general and not dictate a certain design or feature. The power of this tool is immense. It gets the entire team on the same page for where a product is headed.
At its basic level, a story map doesn’t need drawings or anything fancy. Sticky notes with text on a whiteboard (or the digital version) are good enough. It’s a good exercise to try out with regular, everyday things to get a feel for it.
Jeff Patton is the UX guru for story mapping. His book User Story Mapping has influenced designers around the world. One of the exercises he encourages is to do a story map of your morning routine. I did this in a workshop with him and mine had twenty-five steps. Some did theirs in less than ten and some more than thirty. But they all had a handful of things in common.
Here is a simplified story map of my morning routine.
You can see I kept it general. Going into greater depth is ok, but keeping it general is great because it can capture more users. You can always get into more specifics later. I showed this by adding a sticky note below another one because I often do them simultaneously: I take time to reflect and prepare for my day while I’m stretching and exercising. And someone may not do any of those, but most people will do some sort of mental/physical thing to get their day going, so it’s a valid card to leave on there.
Likewise, under “clean up”, I could add a dozen steps like brush teeth, shower, and any other grooming I do. When getting into the nitty-gritty of an app flow, it’s good to spell out all those details, but initially, I always find it better to keep it simple; to cover a wider range of different types of users.
At its basic, doing a quick five-minute story map with someone on a project can suddenly inspire a wide range of changes and improvements to a design direction. At the very least, it can show how a design is disjointed when things should flow from one step to the next easily.
User flows are different from development flow diagrams. A developer’s focus is on the logic and steps to accomplish a task. These are critical to building good software and they have a completely different purpose. They should be done later after the basic flow has been fleshed out.
Here’s an example of a developer flow diagram.
Here you can see the developer is concerned about the same kinds of things but is focused on making a design functional, not on making the user flow more efficient and simple. Here’s the flow diagram but now from the UX perspective.
You can see that the UX focus is on the flow of the user as they enter the app and try to accomplish their task. It brings to focus key ideas like how easy it is for the user to find what they’re looking for and how to enable them to purchase it immediately. Granted the developer flow was only for a piece of that story map: the aspect of doing a search and seeing which one is greatest. But it’s very clearly a very different goal.
The developer, in this case, is concerned with how to make the software work most efficiently. The UX designer is more focused on making sure the user understands how to get in and out as quickly as possible with a new stapler in their hands.
One time I was working with a team to launch a full enterprise software solution. I said: “What we need is a monster, mega-sized story map.” We took over a huge hallway and used large sticky paper and big sticky notes to map out over a dozen story maps that made up the entire larger story map.
Then, three different times we brought in experts in the field. Each one went through the gigantic story map with us and added, changed, and helped prioritize it. In the end, we looked back and proudly said we knew what we needed to do. Our deadline was less than a year, and this exercise showed us what we needed to build immediately, what could wait a year, and what could be done later down the road.
The thing about this exercise is, while it’s not hard, it takes a lot of work, brainpower, intentionality, and collaboration. The end result was that everyone who worked on the project picked up a clearly defined picture of what they were building, what purpose it had, and where it fit in the bigger picture.
If someone ever questioned whether we were building things in the right sequence then we could always go back and get more data from real users. But that session minimized the need to do that significantly. We were set up for success and the team delivered a sellable product within our time constraints.
Sometimes the story map is a lifesaver you didn’t know you needed.
I worked on a software project where the product manager had pinpointed a user need and the developers were halfway through building a solution. The flow was simple, but because I was confused by it, I went through it with him.
The problem was the users (attorneys in this case) needed to ask the same kinds of questions to their clients for the same types of legal documents time and again. It would be better to save time by saying: “this user falls into this category and they all have answered these questions a certain way.” Their solution was to create “scenarios” which could be used to reapply the same question settings to the next document or folder.
The problem is, this was just one of the user flows: adding a scenario to a document or folder. There was a second user flow, which was to create the scenario in the first place. And then there was a third user flow, where the user would want to manage them, the basic CRUD (create, read, update, delete) you would expect for anything that is a ‘thing’ in the UI.
User testing showed the entire design was full of holes. 100% of users were confused. Part of the issue was educating them about a new concept, but the biggest factor was the multiple user flows, which made for a convoluted user experience.
We tried a number of ideation sessions and came up with some other potential solutions. I created a few lightweight prototypes; very sketchy so users wouldn’t get drawn into the visual designs. They tested better but again were full of the need to educate and hold the users’ hands.
Then, at the next ideation session, the epitome hit us. What if we ditched scenarios completely? We instantly figured out how to get rid of two entire user story maps by using a star system. If users could star their favorite documents and folders, they could instantly reuse them whenever they wanted. No need for templates or scenarios. A simple and common design was all that was needed to solve what had appeared as a complicated problem.
We tested the new ideas on users and 100% of them instantly grokked the new approach. User flows saved the day!
Conclusion
User flows are a vital and critical tool in the UX product design toolbelt. A basic understanding of them will go a long way to improving product designs to have the best possible flows for users to accomplish core tasks.
They also have the benefit of ensuring everyone on the team has a shared understanding. The worst-case scenario is a developer begins coding the software without knowing what the end goal is. Software becomes disjointed and confusing; with no sense of flow or how to accomplish a task from A to Z.
When the entire team understands the user flow, it allows some wiggle room in the designs. A developer can say: “I know you designed it this way, but if this is our user flow, can we simplify it further and do this?” I am always impressed with how developers come up with better designs in the midst of coding. Frankly, they’re the ones looking at it most closely and testing out all the edge cases. They won’t have the same level of feedback if they don’t understand the big picture of what the user is trying to accomplish.
Sometimes design challenges are big and hairy and they require a lot more thought and multiple story maps. Even if it takes a couple of days and many minds, it’s worth the time! The entire exercise never fails to add value to a development effort. Even if the flow diagrams that come out of it haven’t changed, now everyone on the team can be assured that it is a good design and they can all agree on it.
It’s easy to start creating story maps. All it takes is some sticky notes and a whiteboard. And the results will always be worth the effort.