Your software product is going through a major redesign.The user experience team needs to make interface design updates to all areas of the product. There is a tight timeline for the release, and scope is continuously expanding. Oh, and by the way, you will be working within an agile team. Yay!

This was the very scenario that the UX team was challenged with when I joined my current organization in 2010. We were tasked with delivering major updates and expansions to product functionality, working within a two-week iterative agile development process. Our team was struggling to balance user experience quality, quick turnaround, and functional completeness. We soon found ourselves spending considerable time iterating a single feature to its most perfect state instead of delivering a basic set of feature designs that formed a complete workflow. We needed to refocus our design priorities and use a different approach if we had any hope of delivering a meaningful user experience in the required timeframe.

Design mapping to the rescue! Applying the concepts from Jeff Patton’s story mapping tool (www.agileproductdesign.com), our team was able to identify and prioritize the most effective approach for feature design. Although story mapping is traditionally used to plan and prioritize scope at the product release level, because it integrates a persona (the user), their goal, and an associated workflow, it readily adapts to identifying options and planning a layered approach to the user experience design. Using the story mapping tool in a design context helped us successfully deliver the required features that formed a complete end-to-end user experience across the product.

Design Maps

Thankfully, the basics of design mapping are simple. As with story mapping, each design map has a persona that has a goal he/she wants to accomplish. There is a sequence of steps, or tasks, that make up a workflow the user will go through to accomplish that goal. These tasks are presented horizontally at the bottom of the map, left to right. Different approaches to accomplishing each task are posited by the design team. These design options are placed in columns above each task, ordered by simplicity. Once the framework is established, the result is a transparent, tangible artifact you can use in conversations about necessity and priority for each design option (see Figure 1).

To build out a design map for your project, you first establish the persona, goal, and workflow. This is usually done in consultation with the person on your team that represents the business needs; for example, a business analyst, product manager, or client. Then, the design team can start brainstorming different design solutions for the tasks in the workflow. Each brainstormed idea is represented by a block above the task column (the light grey blocks shown in Figure 1). Once there are at least three design ideas created for each task in the workflow, it’s time to prioritize. What is the simplest solution that would satisfy the task? Start by placing those ideas just above the task step, and work your way upward to more complex solutions. Your design effort then continues by choosing one design option for each of the task columns.

Let’s look at an example of a design map for making macaroni and cheese. The persona is a single mother who works full time, and her goal is to make macaroni and cheese for her children’s dinner. Her workflow might include things like, “Get a recipe,” “Gather ingredients,” and “Cook macaroni & cheese.” We could then brainstorm different ideas for how she could accomplish each task(see Figure 2). You can envision that for this persona, with her busy schedule and active children, the simplest thing that could possibly work may be the “blue box” prepared in the microwave oven! But what if she were making the macaroni and cheese for a dinner party? You might make different choices about the options. You’re on the right track as long as at least one option from each column is represented in the designs.

At ProQuest, we first used design mapping to approach a set of requirements for building new administration functionality. Among the user tasks that needed to be designed were accessing the application, assigning administrators, creating users in the system, and managing those users (edit/delete, assigning settings, etc.). The team was able to create a design map that presented options for each feature (see Figure 3 for a simplified version).

Once we had established the design map for our administration tasks, and prioritized by design simplicity, we invited the product team (business analysts, developers, and QA) to review it and help make choices about the level of support we wanted to adopt for each task. For example, while the simplest requirements layer may be good enough for some tasks (see Figures 4, 5, and 6), perhaps a more complex “enhancements” or “embellishments” level of design support is needed for other tasks (see Figure 7).

Often, the discussions among team members reveal factors that make one option more desirable than another. For example, there may be an option that makes the product more competitive. Other options may be more technically complex, potentially affecting delivery. There are many variables to consider when making these decisions, and there are no right answers. The most important thing is making sure that you have at least one design option from each column, forming a complete solution for the user workflow.

As you can see, although we started our design proposals with the simplest approach that could possibly work, there were cases where the business felt a more complex design was appropriate. In addition, what may begin as an enhancements-level design for a new product may, over time, become a required-level design as the product matures. As business and project needs change, the map will change, too. One of the most valuable aspects of creating a design map is the opportunity for continuous collaboration.

Cupcakes and Layers

When I teach this method, there is a story I like to tell about a party that I was asked to make cupcakes for. I only had an hour to put them together, and there were twenty guests on the list. When I looked at the list, the first person on it was my dear friend Mary. Now, Mary and I go way back, and are very close. I happen to know that Mary’s favorite kind of cupcake is vanilla cake with chocolate frosting and sprinkles. I really wanted to make this cupcake for her, and I wanted it to be perfect. So, I mixed enough vanilla cake mix for her cupcake and waited the twenty minutes for it to bake. I made the chocolate frosting, used a pastry bag to pipe it prettily onto the cooled cupcake, and took my time carefully placing sprinkles over the top. Things were going great! But, then, uh-oh! I checked the clock and discovered that I only had ten minutes left to make nineteen more cupcakes! I’d run out of time. It’s sometimes like that when we are working through design. We spend our entire time designing one feature up to the sprinkles, leaving other features in the workflow out of the party (see Figure 8).

This is where the design map and prioritized layering helps. If we had started off our baking project by making just a plain cupcake for everyone, each person would have gotten a cupcake and the most basic requirement would have been met. If we had extra time after the baking, we could go back and frost the cupcakes as an enhancement to the user experience. And, if really necessary, we could go back again and embellish them with sprinkles.

Agile design projects can be approached this same way. By mapping the user workflow, satisfying basic requirements across each of the tasks, and adding enhancements and embellishments as you have time (and/or budget), you can deliver the most basic and valuable end-to-end user experience right from the start.

Please, Hold the Sprinkles

While design mapping has been invaluable to our team in organizing and prioritizing our design efforts, there are a few caveats to watch out for when using it in your project. First, if your project doesn’t already have a persona, now is the time to create one. So much of the prioritization and workflow decisions depend on “who” is using the features, that design mapping will be much less effective without a basic persona.

Second, be careful about the differences between a user goal and a task. A user goal is “what” the user needs to accomplish, while the tasks are “how” they will accomplish it. For example, your goal may be to get cash from your savings account. The supporting tasks would be things like driving to the ATM, swiping your card, and entering your PIN number.

Third, make sure you are truly looking at the simplest design for each task. The idea is to create a basic experience that you can build on in future iterations. Agile design is about embracing simplicity and necessity over complexity and desirability.

Lastly, hold the sprinkles! As with many user experience professionals, I have had to learn to set aside my inner perfectionist and focus on the simplest thing that could possibly work for the user. User experience design doesn’t always need to be fancy, jazzy, or wonderfully elegant. Think first of what the user actually needs instead of embellishments that might wow, but ultimately do not satisfy. Embrace the cake, frost with care, and if someone on your team is insisting on iterations of sprinkles, tell them the story of Mary’s cupcake.

Topics: Agile, Requirements
Published in: August 2012 in Featured Articles