3 Day Design Sprint: UX Triage

Focused 3 days of design goodness.

The desired outcome of any design sprint is to produce a focused set of work around a set of features for development. We will step thru a few activities that will help us work down a thought process funnel.

These methods are developed to help us work through the scope and end with understood, actionable designs.

Scope the Feature


  1. Idea Dump — The first activity is to dump every possible idea about a feature into a pool. This can be stickies on a board, whiteboard list, trello list, or any method that allows the entire team to see all of the ideas in one spot. Encourage any idea to be captured from the generic to very specific requirements.
  2. Idea Categorization — After all ideas are captured group the ideas by similarities. It can be any type of category, based on where, how, what, when or who. A few examples could be ideas relative to back end, relating to interactions, or around a common theme.
  3. Idea Prioritization — Put the categories or ideas in priority. Usual priority is based on need for first users over relation to the end goal.
Here is where you use the literal groups of Must/Should/Could. Use these to separate the ideas based on these.
  • Must — critical to v1 release
  • Should — highly desired for v1
  • Could — could wait for v1.1

Understand the workflow

Look at the experience, not the screens

These maps are meant to help visualize the connections between what a user can see and what they can do. Here we use only general terms for what they see and action verbs to describe what they can do.

Users can’t “login” as a Do, they “submit valid info”. As we don’t know at this step what the requirements are for the submission of the valid info. We define this later.

See|Do Map — This map is not a site map it is a workflow map. We design the connections between the objects here. Don’t forget sad paths.

Atom Gathering — After the map is defined, we need to list the requirements for each See or Do. Take the time to be very specific in what is needed to accomplish each interaction.

Layout the feature


Component based systems really show their power when you layout out features with Grays. These should be in low-fi. No color, no font types, only use boxes and lines to allow for rapid interation.

  1. Low-Fi — We use only the simplest designs to allow the team to experiment with layout options quickly. The team should understand the components you are using to design this feature. This step isn’t defining the feautre, its designing where it’s parts and interactions will exist.
  2. Component based designs— We focus on UI toolsets over individual screen designs. We want to ensure you product can scale, extend beyond the first features, and be highly reusable across your product. Check out “Atomic Design” we closely follow it’s prinicples.
  3. Reds — You will not need to provide UI Reds for most of your features. In the case you have new componets you will need to develop the Reds for them. We normally don’t cover UI in a design sprint, but occasionally hit will be touched upon here.

Feature Documentation

Keep track of and prepare your features

Not only is the feature documentation the end game of the design sprint, it will also enable the team to completely understand the scope, effort and cost of each feature. When a feature is thoroughly documented, it can remove the ambiguity in the product, and help create more realistic timelines.

The feature documentation is commonly held in a public area for anyone on the team to consume, anytime, any place.

The scope of the document should contain, but not limited to:

  1. A comprehensive description of the feature and why it exists.
  2. See|Do map to scope the interactions.
  3. Feature Aspects which define the components.
  4. Grays to illustrate structure.
  5. Limitations & Expectations to flesh out the whole picture.
  6. Connection and Data information.

Remember the goal is a holistic document, or one stop shop of any developer or team member to pick up and understand the feature enough to carry it to full development.

This is a living document and will go through many revisions, updates, and changes. A strong reason a connected document management tool like Google Docs.

Client Expectations

Before the chaos ensues

The client is expected to have a firm collective grasp on what they want built. The design sprint will uncover the holes, gaps, and mis-understandings with in the team.

  1. Most critical decision makers attention and time.
  2. A room with a whiteboard or if remote a strong, reliable connection for all team members.
  3. An open mind ready to challenge and consider any solution.
  4. Focused mind set to not get stuck in the weeds. We will move fast and drop any discussion that derails forward progress in defining the features.

Design Sprint Deliverables

What you get for your time

After 3 full days of talking about features and scope we will have prepared for you these helpful tools you can use to develop your product.

End of day 3

  1. Prioritized Feature Set for v1 and further.
  2. v1 “Feature Documents”.
  3. Links to images, google drive, trello, and invision project.
  4. Defined list of needed research spikes.
  5. A vetted scope and product direction.
  6. Confidence your team understands what you are building.

After design team huddle

  1. Link to a click thru gray prototype.
  2. Further “Feature Document” revisions.

Design Team Tools

Whiteboard — We use whiteboards to quickly iterate ideas. When remote, we will use Sketch or Google Draw.

Trell0/Google Draw — To prioritize and keep track of features.

Google Docs/Connected Drive — Feature Documents go here.

Invision — All project See|do’s, Grays, and prototypes.