Day 1: Surveying the as-is landscape

You’ve picked a sprint topic and have gotten people excited about it. This week we’re going to talk about the first phase of the Enterprise Design Sprint, “As-Is.” This is where everyone focuses on what currently exists in the system, from a people, process, and technology perspective. You’ll learn more about the players involved, the processes they’re a part of and the role that technology plays in the system.

Why start with the as-is? Why not jump to the to-be?

The as-is grounds us in what customers are dealing with right now and how well the system currently meets their needs and desires. It can reveal unknown or forgotten players, needs, processes, or technologies. That info will help in the design of a future system that doesn’t adversely impact other systems or processes.

Having knowledge about the current landscape will also be useful later when defining a minimum viable product (MVP) and roadmap to the future state. It’s similar to how civil engineers consult land surveys before designing new structures. You could end up with an ok solution without understanding the current state, but it’s a costly bet.

Scheduling options

There are different scheduling options for this phase. The best choice will depend on how much time you have to dig into the details and how much has already been documented. If very little user feedback has been gathered or if there are no existing documented business processes then you might want to spread out this phase to up to a week before the rest of the activities. That will also give your technical team time to dig into the system documentation (or create their own via system owner interviews).

The goal of this stage is not to document everything that you could possibly need to know, but to gather enough information to inform brainstorming for the creation of draft prototypes and roadmaps to share with stakeholders.

Here are some examples of how you could structure your as-is phase:

A 2-hour session covering goals, user needs, and success criteria with follow-up meetings for the rest of the as-is details. This is good for a kick-off with brand new stakeholders to make sure that everyone is on the same page about what customers need, your goals, and the direction you’re trying to go in. Scheduling follow-ups for later in the week gives stakeholders some time to share existing documentation if they have it.
A half day covering goals, user needs, success criteria, and as-is state. This is a good amount of time if you’re in knowledge sharing mode vs. knowledge collection/generation mode. Business analysts or stakeholders could do presentations about key business rules or processes that other participants should understand to have enough context for ideation.
A full day covering goals, user needs, success criteria, and as-is state. This is the best option if you have a full group of people (including stakeholders who can speak to the processes and systems) who are able to work together throughout the day. This is the structure that we’ll cover in more depth below.

Outline of the full day

A sample agenda for a full-day meeting about the as-is state:

Day 1: As-Is

Introduction: Sprint goals (30 min)
User needs (2 hrs)
Break (10 min)
Business needs (1.5 hrs)
Lunch break (1 hr)
Success criteria (30 min)
As-is customer journey (1.5 hrs)
Break (10 min)
As-is system (1.5 hrs)
Wrap-up (15 min)

Introduction: Sprint goals

The introduction to the sprint is a way to set the expectations of everyone involved so that they know what the group will aim to accomplish and when certain conversations or activities will occur.

Here’s a sample outline for what you could cover in your sprint intro:

Do introductions if the participants don’t know each other yet.
Describe the design sprint process.
Outline some objectives of the sprint. You could expand upon the following list:
- Artifacts outlining the as-is and to-be state from a user, business, and technical perspective
- Prototypes for the vision and a minimum viable product (MVP)
- Roadmap for moving from the MVP to the vision in phases
- Feedback on the prototypes and roadmap
- List of questions and action items for other subject matter experts and partners
- Plan moving forward for the team
Outline how the activities will be split out across the week.
Share a detailed agenda for the day, broken down into increments no longer than 1.5 – 2 hrs. People start getting restless after that if there are no breaks or shifts in activities.
After outlining the process and plan, now it’s time to give any important background or justification behind the topic that was picked for the sprint. Here are some examples of content you could include:
- Why this topic matters to customers or the business
- Known pain points and goals that you want to make sure are considered in the conversation
- A reference to any stated vision, mission, or initiative if it exists

User needs

The first activity of the day will be focused on end users, customers or external stakeholders. These will be the main users of your business, product, or service. They may be internal employees but are most likely outside of your organization.

A quick terminology break. You’ll see these three terms used:

User: A person who uses or operates something, especially a computer or a machine.
Customer: A person or user who buys something from a business or organization
Stakeholder: A person with an interest and concern in something, especially a business.

They all have slightly different meanings but for the purpose of this exercise you’re looking to understand the needs of people who will be most impacted by the system. They may be users of a particular product or application, customers of your business, or just general stakeholders.

You’ll see the terms users or customers typically used in product design documents, customers or stakeholders in business documents, and generally stakeholders in the political, non-profit, or systems engineering space. For the purpose of this explanation, they may be used interchangeably but feel free to swap in the words your organization uses (ex. client, consumer, etc.) It all boils down to the people you are trying to help and others who have a concern about the outcome.

Back to the exercise. Here’s an outline of activities that work really well in both face-to-face and virtual settings:

Step 1) List customer segments

Make a list of customer segments. To save time, pre-make this list beforehand and ask the group to confirm or modify it. Discuss whether certain customer types can be grouped or if they need to be further split apart, given the goals of the sprint. Think about if the needs, business processes, or technology involved is likely to be different for those groups in relation to the sprint topic.

Ex. Moms and Dads could be combined as a “Parents” segment. Or they could both be split into three more groups, “Stay at home”, “Work at home” or “Work away from home.” Depending on your sprint goals, that differentiation could be redundant or in contrast, yield new insights.

Step 2) Prioritize customer segments

Highlight the most important customer groups to address with star or sticker. Try to limit the choice to one or two for now so that you have time to complete the customer profile. These will mark the customer segments that you’ll start the next exercise with. You can always run another sprint later that looks into the needs of your other customer segments.

Step 3) Create customer profiles

The next activities covered in Steps 3 &4 are a really fast way to outline information about your users. I first learned about this particular customer profile technique after reading “Value Proposition Design” by Strategyzer.com. They offer a great canvas that you can download and use in your projects to map your current or future value propositions to customer needs. I definitely recommend grabbing a copy of the book and if you create an account on their site you can get access to a lot of great free resources like templates and tips.

In the Strategyzer.com process, for each customer segment, you’ll want to write down insights related to their jobs, pains, and gains.

Jobs: What users are trying to accomplish in their work and lives
Pains: Bad outcomes, risks, and obstacles related to customer jobs
Gains: Outcomes customers want to achieve or the concrete benefits they are seeking

Step 4) Prioritize jobs, pains, and gains

Have the group rank the sticky notes in each category along its respective axis. This activity should be led by whoever is closest to the user point of view, whether it’s an actual user, representative, agent, or UX researcher. (Note: This activity is also from Strategyzer.com.)

The rating scales for each category:

Jobs: Important <—> Insignificant
Pains: Extreme <—> Moderate
Gains: Essential <—> Nice to have

Step 5) Discuss reasoning and assumptions

If you had your real users in the room during this exercise that’s great. If you didn’t, it’s especially important to discuss as a group the evidence or reasoning behind these choices.

Write down the assumptions that you are making.
Write down ways to test those assumptions. Ex. via an interview, prototype, job shadowing, experiment, email, data pull, or market research.

Repeat the process with other customer types until the main segments are covered or you run out of time.

Business needs

Repeat the entire process (Steps 1-5) above with internal stakeholders such as on-the-ground employees, managers, decision makers or executives. This would include anyone else who doesn’t directly use the solution but has a stake in it either because they are in charge of the process or operating within it.

Success criteria

This is the point in the process where we pause and look at what exactly we want to accomplish. What measurements would we expect to change as we move towards a potential solution? How do they map to the relative ranking of customer jobs, pains, and gains? How do we know that the outcome was successful?

While this success criteria is by no means set in stone, it will help guide the conversation and prioritization of ideas. It helps communicate a quantitive objective to complement the qualitative understanding of the system. Think of it as a guiding light that the team can refer back to when needed to make sure that the conversation stays on track. It gives the team freedom to explore the space without getting completely lost for days.

Here are some steps you can follow to define the success criteria of your effort:

Step 1) Write down the problem

This could come straight from one of the user or business jobs, pains, or gains. Ex. Users need to be able to accomplish X and are unable to, users are encountering pain point Y, or there is a lack of users experiencing gain Z.

Step 2) Write down the opposite scenario

If you’re trying to avoid a negative situation, what would a positive situation look like? If you’re trying to create a positive situation, what would a negative situation look like? Ex. Users completing a task vs. failing a task.

Step 3) Define indicators

Write down indicators that the negative outcomes are decreasing or that positive outcomes are improving. What change could you observe? How can you measure that change?

Step 4) Evaluate

Will the metric help anyone make a future decision (ex. selecting what to build next or whether to continue funding) or is it a vanity metric? Can you change it to make it more actionable?

Step 5) Repeat the process if you have multiple high-priority problems.

As-is customer journey

We covered the people angle, so now it’s time for the process angle. A good way to ease into this is to start with a customer journey map, which will inform a business process model, which will eventually be drilled down further to include technical systems and any automated steps.

A customer journey map is a way to visualize what the customer experiences before, during, and after his interaction with the product, business, or system and what he is thinking and feeling.

Here’s a quick exercise for creating a customer journey map during your as-is day:

Step 1) Form teams

Break up the team into groups if you have enough people with relevant background. Otherwise stick with one group but the smaller the better, no more than five people, so there is a chance for everyone to participate.

Step 2) Outline process steps

Hand out sticky notes of one color and ask people to write down key process steps in the journey. Write out a separate process step per note and have them place the steps in order.

Step 3) Add insights

Have the team write down their thoughts and insights on different color sticky notes. Ask them to place the insights next to the corresponding process step.

Step 4) Write down questions

Ask the team to write down their questions on a third color of sticky note. These will be added to the question bank later.

Step 5) Mark pain points & delighters

Have them mark painful points in the journey with a red dot sticker or marker and happy points with a green dot.

Step 6) Identify make or break events

Ask people to highlight “make or break events” such as events that could cause someone to recommend your product or business to others or avoid it and tell other people to do the same. You could also look for extreme failures or opportunities.

Step 7) Discuss with group

Ask the teams to share their results out loud with the rest of the group. Refer back to the customer profiles. Did the team uncover any new insights to add to the profile? Are there any clusters of unanswered questions about the process or customer reactions? That might be a sign that extra research is needed.

You can easily use the process steps in the customer journey as a starting point for your process model by adding extra swimlanes to represent the business players and systems involved. These models may already exist or your team may need to spend some time creating them in the as-is phase.

As-is system

While the customer profiles, journeys, and process models can give you a slice of information about the as-is system, a systems map can provide a bird’s-eye view of the complexity involved. They are not ideal for showing scenarios but can be extremely helpful in cases where different people in the system may be interacting with different technologies. Gaps in information sharing or channels can become painfully obvious.

Most are high-level visuals with a handful of icons that are tailored to the industry and represent the major components of the system. The icons are connected with arrows to represent flows of information or materials. The ultimate goal of these one-page graphics is to describe how the components of the system work together to deliver value to the participants or complete the system’s mission.

A systems map is a view of the as-is system which can be further complemented by other artifacts. As before with the process models, other documents may already exist or your team may need to spend some extra time working on them in the as-is phase. If the amount of research is overwhelming for one week, no worries. Your team probably already knows a lot to be able to move forward with a first prototype and since the sprint only takes one week, you can easily break up the as-is analysis over a few sprints as you learn more about the highest value places to look.

Wrap-up

At this point, you’ve all probably run out of time and energy. It’s time to do a quick recap of what you accomplished and a review of the next day’s agenda. It’s a good idea to separate out the as-is and to-be days to give everyone at least a night to let the information marinate and so they’ll be energized for ideation.

At the end of the day, you’ll have walls full of sticky notes and thoughts which can be overwhelming. Make sure that you cover the main points, reiterating the most important needs, pains, and gains, your success criteria, the “make it or break it moments”, and any other key insights that you learned about the system.

If there are questions that you can start assigning out as action items, this is also a good time to do that so people can fire off a few emails if needed before the end of the day.

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 day. Next week we’ll talk about the second day of the sprint, “High-Level To-Be.”

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.