Day 3: Outlining a detailed to-be

After a brief break last week we’re back to the #EnterpriseDesignSprints series. We left off at the end of Day 2: High-Level To-Be and now it’s time to jump into Day 3: Detailed To-Be.

This is the day when the team will transition from strategic to tactical, from dreaming to building. You’ll take the customer journey(s) you created the day before and add more detail to each step.

Depending on the problem you’re solving that could mean that this is the day when you’re sketching out website or application screens, promotional materials, sub-systems, product components, adjusting call scripts, or outlining potential new service transactions. Regardless of what you’re building, you’ll want to make sure you end the day with one storyboard representing a minimum viable product (MVP) and another one representing a longer term state (if you can’t execute the vision all at once).

Why not jump straight to coding, building, or experimenting? Here’s how it helps the team:

Mistakes are cheaper: Before you spend a lot of time getting a widget to work, you can explore different widget designs in the context of the broader experience. Hours of work could be avoided with a 10-second sketch. You might realize that the design should be completely different from what you originally thought. Or that you don’t need that widget at all.
Efficiently divide and conquer: By agreeing on the end-to-end experience ahead of time, the team members can spend the following day individually cranking out their part of the prototype. This helps avoid the moment when you try to combine sub-components of the prototype and realize that nothing fits together smoothly.
Capture more ideas for the backlog and roadmap: Unless you version your prototypes well, they’re not the best way to capture ideas that you can save, organize, and reference later on. The sketches and notes created today can be added to the ones created earlier in the week and managed in a similar way so that they’re accessible for future iterations.

Note: I learned about the storyboarding exercise from Jake Knapp over at Google Ventures and found it to be a really great way to get a lot of ideas from a variety of people. I recommend an adjustment to the review and voting portion at the end though to work better in situations where there is no final and completely informed decision maker (which can happen often in complex systems.) We’ll also talk about alternative activities that you can do if your solution ends up requiring a relatively straight-forward user interface but a complicated backend.

Outline of the day

A sample agenda for a full-day meeting about the detailed to-be state:

Day 3: Detailed To-Be

Agenda overview and exercise explanation (20 min)
Storyboarding exercise: Round 1 (1.5 hrs)
Lunch break (1 hr)
Group discussion (2 hrs)
Storyboarding exercise: Round 2 OR Detailed system design (2 hrs)
Final storyboard creation (1.5 hrs)
Prototype assignments (15 min)
Wrap-up (5 min)

Agenda overview

Kick off the day with an overview of the agenda, the exercises that you’ll complete, and the expected output of the day. Clarity about the objective will be helpful to keep everyone on track so that you end the day with a completed storyboard to build prototypes from.

Storyboarding exercise

Step 1) Note taking

Encourage people to refresh their memories by silently reviewing the work you all did the two days before. That information may still be up on the walls, in photos on a wiki, or sent via email to remote participants. Provide some scratch paper to help people take notes and give them about 10 minutes to complete this step.

Step 2) Mind mapping

In this step, people can organize their notes into however they see fit. Maybe it’s a mind map, list, customer journey, process model or drawing. This paper won’t be shown to anyone, it’s just a way to help them organize their thoughts. Provide 10-15 minutes.

Step 3) Crazy Eights

This is a fun exercise that usually makes people a little nervous and excited at the same time. Ask everyone to grab an 8.5″ x 11″ sheet of paper and fold it in half three times, creating eight rectangles. Then tell them that they will have 30 seconds to sketch in the first box, followed by a 10-second break, and so on until all eight boxes are filled.

The sketches could show a progression in a sequence or be completely unrelated. As for the level of detail, they don’t need to show every last detail but they should start to show what the user will see. Assure everyone that no one will see these sketches either.

Keep a timer visible so people know how much time is left. I like using the Interval Timer at Online-Stopwatch.com because it’s free, virtual, and you can set up your sketching and break intervals ahead of time. You can also set different sounds to mark the end of each interval type.

After the first round, take a brief break and see how people are feeling. Then repeat the cycle with another 8 sketches.

Step 4) Mini-storyboards

Now each team member has 16 sketches plus their original notes. It’s time to organize the sketches into mini-storyboards.

You can download a free template down below that includes squares that will fit standard 3″x3″ sticky notes. Put a sticky note in each square to draw on. That way you can easily move them around later if you decide to include just one of the drawings in your final storyboard. Add a description of each step to the right of the drawing and a title for the mini-storyboard at the top of the page.

Encourage people to make as many mini-storyboards as needed to visualize their ideas. If you have remote participants, ask them to snap a photo of their mini-storyboard and send it to you. If you have a webcam set up they’ll be able to follow along with people in the room for the rest of the day.

Group discussion

As people finish their mini-storyboards, ask them to post them up on the wall and read all of the storyboards silently.

This is where my recommended process diverges from the one outlined by Google Ventures. Rather than moving next to silent dot voting, we found it to be more effective to start a group conversation about the areas of group agreement vs. disagreement and to spend the rest of the day working on the final detailed design together.

As you look through the drawings you’ll probably see variations on a handful of core concepts. For every step in the process, I would write down the name of the step on a colored sticky note. These steps usually map to steps in the customer journey but sometimes the mini-storyboards reveal completely new ideas, so add those as well. For example, you might use “apply” or “manage” as headings from your customer journey, and then add something like “view history” as a new category if it wasn’t in your original journey.

Then grab different colored sticky notes and write down ways the team had come up with to address that step. For example, if we were considering showing family relationships in a table or a family tree I would write down “table” or draw a picture on the sticky note. If questions are raised about the feasibility or the details of something, capture those as well, using a different color to differentiate them.

The higher level notes will end up being the modules that you want to have in your storyboard. Those could be a single screen or product component, or a set of multiple screens. The notes beneath them will indicate what those steps could look like. If there’s an existing sticky note from a storyboard that perfectly represents what you’d like in the final storyboard, then move it below the corresponding step.

By this point, you’ll have an outline of what you want to include in your final storyboard. Review where the team agrees and where you have completely different ideas of how to realize the steps in the experience. If there’s disagreement then the team may need to discuss further and pick one, or decide to prototype and get feedback on multiple ideas.

Refer back to the customer profiles and success criteria that you made on the first day to make sure that you covered the main concerns and goals that were originally identified. Use that information to prioritize. Mark the steps or the design ideas that you definitely need to prototype with a star or colored dot. Mark the screens that will be part of the MVP vs. vision prototypes with separate colors. Also, refer back to your assumptions and see if sharing prototypes of any of your sketches will help resolve risky unknowns. Mark those as well. All of the screens you marked will be what the team focuses on during the prototyping day. You can leave the rest as “nice to haves” to prototype if you have extra time.

Storyboarding round 2 OR Detailed system design

At the end of the day you’ll define the final storyboard, but in the time leading up to that you have a few options. If there are still user experiences to consider, you might want to spend the time in another round of sketching and storyboarding. For example, if you realized that you have no sketches of an interaction that was deemed highly important to the stakeholders then you’ll want to go back to the storyboarding exercise.

On the other hand, sometimes the user interface is relatively clear because there are industry patterns or style guides to follow. In complex systems sometimes the biggest hurdle is sorting out what could be feasible in the short-term vs. the long-term. Without that information, your prototypes probably won’t accurately reflect what can be delivered. That means they’ll need to be reworked and reviewed by stakeholders again to make sure that what is delivered meets their needs. If you find yourself in that scenario, working in a complex system, it might make more sense to spend the rest of the afternoon drawing business process or technical models of the detailed to-be state to help get everyone on the same page.

Some questions to consider while you work through the models:

Is your MVP truly minimum and viable given user, business, and technical perspectives?
Could certain features that you thought would be longer term actually be feasible now? Vice versa?
Are there any risks that should be addressed in the prototype? For example, if you know that certain data will be returned that will cause a negative customer experience, consider including it in your mock-up instead of using generic lorem ipsum text. Same thing if you identified an opportunity for a positive experience that wouldn’t be immediately apparent from the interface design.

Knowing what people will experience and why once the change goes live will be helpful when communicating with stakeholders and partners. It will be especially informative if there is strong pressure to deliver something by a certain date. It will clearly show what the experience would be if delivered without support from other teams, vs. what it could be if further planning and coordination was implemented, or if the changes were split out over phases. It’s also going to be a crucial input for the roadmap.

Final storyboard

At the end of the day, draw out squares on a whiteboard representing each screen you’d all like to prototype. I like to then ask the team “What will users see first?” and draw out each screen in order.

Keep filling out all of the screens. Make sure you have the major design elements and key text like headers. If you reach areas with alternative ideas of how the experience could be represented, draw them out in separate squares. Number the steps, using modifiers like 2a and 2b to highlight alternative flows. This will help when you share the prototype with stakeholders on the last day of the sprint.

Prototype assignments

Ask team members to volunteer to prototype each step in the final storyboard. This doesn’t have to be only your user experience team. Try to have each team member working on something related to the prototype. Sometimes people will have a vision for a particular idea and want to prototype it themselves. Other times there will be a natural fit, like having a business analyst create a page that describes the business rules of the interaction.

If anyone doesn’t have a prototype assignment they can get started on other detailed documentation like draft requirements documents, technical documents, risk assessments and so on during the prototyping day. Don’t forget to account for some time creating the business model playbook and roadmap.

Wrap-up

To close out the day do a quick recap of what the team accomplished and a preview of what’s to come in the following prototyping day. Make sure notes are captured and shared either via a wiki or email so that everyone has copies to review.

Next steps

You’ve learned about why Enterprise Design Sprints are useful, how to pick a great topic, and what to expect on the first three days. The next post in the series will be about the fourth day of the sprint, “Prototyping.”

Update: This blog series about Enterprise Design Sprints has been expanded into a guide for facilitators with all of the content, plus 50+ worksheets and some other surprises. Check it out in the store.