Day 4: Building prototypes

We’re continuing the week with Day 4: Prototyping. In Day 3 you created detailed sketches of what you want to build so it’s time to grab some coffee and crank out prototypes.

Types of prototypes

Before jumping into the schedule, let’s talk about the types of prototypes you could create. Essentially a prototype is anything that represents the final product to some degree and will help you reduce uncertainty at a fraction of the cost that building and releasing the full product would require.

Prototypes can have different levels of fidelity:

Low
- Quick, cheap, and easily changed
- Sketches, storyboards, post-its, paper, cardboard
Medium
- Simple model of the final product
- Simulated functionality and more robust materials
High
- More detailed
- Incorporates actual functions and final materials

In your first design sprint on a topic, you’ll probably want to stay in the low to medium fidelity range. During future sprints as you resolve more assumptions and hone in on the details of the design, you can move towards higher fidelity prototypes that may have components that are used in the final product.

Since there is limited prototyping time during the Enterprise Design Sprint, we’ll be looking at building cheap and fast prototypes or models that can provide enough information to test key assumptions and identify problems and opportunities. Digital presentation tools are great for quickly making something and getting feedback from stakeholders.

Tip: If you schedule the first three days of the sprint in the middle of one week and the reviews the following week, you’ll have extra time to build out more complicated or high-fidelity prototypes. This is useful if you already have some feedback on the general concepts and are looking to test more dynamic interactions.

Tools

Powerpoint or Keynote can be great tools for dividing up the work among multiple people. Most of your team members and stakeholders probably already have and frequently use the software. Keeping your prototypes in a simple format instead of a specialized design tool is a great way to promote co-creation. By leaving comments or changing content or layout themselves, your stakeholders can give you more feedback than verbal comments alone would provide.

If your organization allows it, you could also try creating a Google Slide deck. Set up a slide for each screen in advance, and mark each slide with the person assigned to create that part of the prototype. Everyone can work on the prototype at the same time, comment on each other’s work, and highlight inconsistencies in advance.

Regardless of the tool that you end up using, a huge time-saving tip is to share presentation templates with your team. It’s a lot easier to have everyone building with the same fonts, colors, design elements, and aspect ratio from the beginning. Otherwise, someone needs to go back in and reformat everything later to make it look cohesive, which could take a long time and defeat the purpose of splitting up the work in the first place. If you have a design or content style guide, share that as well.

Some elements to consider including in your template kit (aka Powerpoint or Keynote template), especially if you’re making digital or printed prototypes:

Images
- Logos
- Headers
- Icons
- Stock photos
Editable items
- Buttons
- Tables
- Headings
- Body text
- Forms
- Navigation
Fonts
Colors
User personas (ex. name and relevant profile details such as DOB, family members, etc.)

Product mock-ups can be a great way to give stakeholders an idea of what this product could look like in the real world. By basically embedding an image from your prototype into the scene, it can look like your app is on someone’s phone or computer screen. You could also easily mock up a booklet, poster, packaging, and so on. Designers are adding new templates every day so you’ll probably have no trouble finding something to represent your marketing materials or even the product itself.

Here are some places to find product mock-up templates:

Outline of the day

A sample agenda for a full-day meeting about prototyping:

Day 4: Prototyping

Agenda overview (5 min)
Prototyping: Round 1 (2 hrs)
Morning check-in (15 min)
Lunch break (1 hr)
Prototyping: Round 2 (1.5 hrs)
Afternoon check-in (30 min)
Prototyping: Round 3 (1 hr)
Prototype consolidation (20 min)
Final walkthrough (30 min)
Wrap-up (5 min)

Note: I’ve worked on a project where we completed all of the necessary prototypes in one morning so it’s not necessary to take up an entire day. This is the most flexible day, so team members could schedule their prototyping around other work commitments. However, having a shorter and dedicated amount of time to focus can be more effective than a longer day that involves context switching.

Agenda overview

Start with an overview of the agenda and the expected output of the day. Be clear about the format of the prototype or set of prototypes. Will you all be working in the same tool? Will you use a mix of tools? For example, maybe some people are creating JPEG images to be included in an Axure wireframe. Will your final set of prototypes include digital and physical items? Set expectations and resolve questions up front.

Prototyping

Most of the day will be heads down work time dedicated to building prototypes. Some people may want to work together in the same room, others may want to work individually in their own offices with dual monitors. You may also choose to split up into smaller groups and work in separate conference rooms. Whatever you decide to do, remind everyone to focus on the screens that you identified the day before as “need to haves.” By the end of the day, you should end up with prototypes representing both the minimum viable product (MVP) and the long-term vision.

While part of the team is creating prototypes to represent the new user experience, other members of the team will be working on creating new documents from the week’s notes such as a business model playbook and roadmap. They’ll also be making cleaner digital versions of past diagrams, like the customer journeys and system maps.

Making a business model playbook

The storyboards and prototypes on Days 3 and 4 focus on the details of a few specific experiences. In contrast, the business model playbook zooms back out. It’s a way to organize all the concepts you’ve explored in the previous days into a set of business model “plays” that you can get feedback on. Check out How to build a business model playbook for more information about how to create your own playbook. Your MVP and vision solution will make up two plays in the playbook and you’ll sort through the rest of the week’s notes to identify more.

Making a roadmap

With the business model playbook, the MVP, and vision prototype defined you’re well on your way to building out a roadmap. This draft roadmap will be useful for making sure that everyone including business stakeholders, technical teams, and project managers are on board about the potential sequence of changes over time. Check out How to create a roadmap from scratch for a step-by-step guide to help you build a draft roadmap.

Other digital documents

You’ll also want to spend time on the prototyping day creating digital versions of some of the diagrams you made earlier in the week. I know what you’re wondering: why bother if the point of the one-week sprint is to be fast and agile?

With a small team, you might be ok with keeping your photos of sticky notes as is. However, in complex systems, you’ll be dealing with larger groups and longer project timelines. That means there will probably be employee turnover before the roadmap is completed. It’s impossible to make sure that everyone knows all of the details about what was discussed, tried, and decided upon during the sprint. The photos and notes will be stored in a wiki but no one’s going to have time to read through everything, decipher handwriting, and pull out the core findings and messages.

Think of these digital documents as the executive summary of the work you’ve done during the week. This is the package of information that you’ll want handy to share with team members, stakeholders, and decision makers who weren’t present during the sprint. You can also use these materials to build out a sprint portfolio. That way you’ll have some samples to share when pitching the value of future sprints.

Your final summary could be compiled in a Powerpoint deck or whichever form of communication your organization prefers. The key is to keep it lightweight but professional and useful enough to be read and referenced. A brief presentation (< 20 slides) tends to get more mileage with busy decision makers but creating a white paper template for your design sprint outcomes might be a worthwhile investment. Create or reference your stakeholder analysis chart to identify the best communication format for your stakeholders.

The package you create could include the following:

User profiles
Success criteria
Customer journey (as-is)
System map (as-is)
Customer journey (to-be)
System map (to-be)
Business model playbook
Draft roadmap
Prototype(s)
Important user and stakeholder feedback (to be filled in after the reviews)
Summary of key findings and risks (you can start this now and finalize after the reviews)
Call to action (to be discussed more in a future post)

Group check-ins

Complete regular check-ins throughout the day to give people time to share progress, ask questions, and obtain feedback from the rest of the team. Ask everyone to share what they’ve created so far and what they have left to complete.

Final consolidation & walkthrough

Elect someone to be the person who will consolidate all of the prototypes. Since you created the storyboard the day before and all used the same template to create your prototypes, this step should be relatively quick. Ask people to send over their prototypes or upload them to a wiki as soon as they complete them.

Gather the group together for an end-to-end walkthrough. Identify any comments or questions that you anticipate coming up during the reviews and prepare a response. For example, if someone asks why a particular design decision was made, be prepared to point back to a user profile, success criteria, system map, or assumption to support the decision.

Wrap-up

To close out the day, do a quick recap of what the team accomplished and discuss the plan for the following review day. Make sure that the prototype and other documents are accessible to everyone on the team.

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 four days. The next post in the series will be about the fifth day of the sprint, “Reviews.”

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.