by Jake Knapp
As you might guess, we used Keynote to mock up the reports. We split into three teams of two. On each team, one person was responsible for designing a slide formatted to be the same size as an 8.5-by-11-inch sheet of paper. (A paper prototype is appropriate when—and only when—your final product will also be made of paper.) The other person was responsible for making the information—the genomic data, the recommended therapies, and the rest of the oncology details—realistic and accurate.
If we wanted honest reactions from oncologists, the data had to look legitimate. Of course, testing with real patient data would be unethical. But Foundation Medicine had some realistic-but-not-real test results on hand that they used internally. And the sprint team included experts who could make up more realistic details when needed.
By the end of the day, we had three prototype reports. Each was just one or two pages, printed out from Keynote, on top of a stack of pages from an old, pre-sprint report—a new façade, with an old village in the background. When Foundation Medicine showed the report prototypes to oncologists during the test, they looked just like the real thing.
SAVIOKE
Question:
How will hotel guests react to a robot with personality?
Format:
Physical robot with iPad touch screen.
Tools:
Keynote, sound effects library, iPad, robot, remote control, hotel room, acting.
Savioke was one of the most complex prototyping challenges we’ve encountered. We were testing the Relay robot’s behavior and personality as it made a delivery: the touch-screen interaction on the robot’s face, its movements, its soundtrack of beeps and chimes, and even the timing and script of an automated phone call. That’s a lot of moving parts, and some of them were literally moving parts.
When a team has an extraordinary prototyping challenge, they often have the extraordinary skills and tools to make it happen. Savioke already had the robot, and most of the behaviors and components already worked. We could build our prototype on top of what they already had. It’s like filming a Western in a picturesque ghost town instead of a backlot.
However, there were still four important elements for us to prototype on Thursday. First was the robot’s happy dance. Writing code for the perfect choreography would take too long, so CTO Tessa Lau and engineer Allison Tse decided to use remote control instead. On Thursday, they practiced the delivery by driving the Relay robot around using a PlayStation video game controller.
The second challenge was the robot’s screen, but Adrian Canoso, Savioke’s design lead, had the answer. We could temporarily replace the robot’s screen with an iPad mini. The robot’s eyes and several simple touch-screen interactions could be faked with a series of slides.
Next, the robot needed a new soundtrack. Adrian had experience as a sound designer. He put on a pair of giant headphones and went to work, using a library of free sound effects.
Finally, we needed to fake an automated phone call when the robot arrived at the guest room. Eventually, this call would be triggered by sophisticated software that tracked the robot’s location. For our test, Allison could just watch the robot, then duck out of sight and place the call herself. She just needed to use a stilted voice that sounded like a recording.
Now, most teams can’t prototype a working robot in a single day. But most teams don’t need to—because they aren’t in the robot business at all. With the fully operational Relay robot, Savioke had a foundation for their prototype. They needed to make some challenging additions to it, but they had all of the engineering and design expertise required to get it done. By the end of the day, the robot could dance, whistle, and smile.
ONE MEDICAL GROUP
Question:
Can a doctor’s office for professionals adapt to families with kids?
Format:
A medical clinic that’s only open for one night.
Tools:
Doctor’s office, medical staff, bananas, crayons.
One Medical was off to a great start on a bold mission: to offer better health care to everyone. They’d established a network of primary care clinics with locations across the United States—in San Francisco; New York; Boston; Chicago; Washington, D.C.; Phoenix; and Los Angeles. Same-day appointments, treatment via mobile app, more time with patients, and beautiful office interiors had earned them thousands of dedicated patients.
Most of those customers were young, tech-savvy professionals—the kind of folks to whom “treatment via mobile app” sounds like a good idea. That customer base was growing fast, but One Medical wanted to open their service up to more kinds of patients. With plenty of customers starting to have children, the company figured the sensible next step was family care—for the babies, children, and teenagers of its existing patients.
One Medical hoped to serve both families and grown-ups in the same locations. They already had many physicians on staff who were trained in family medicine. But before the first of these new clinics opened, they wanted to be sure patients would have a great experience.
How do you prototype an entire doctor’s office? Like Savioke and Slack, One Medical built on top of what they had. Chris Waugh, One Medical’s vice president of design, hatched a plan: For one evening, One Medical would simulate a real family clinic in one of their existing offices.
At 6 p.m., the Hayes Valley office in San Francisco closed its doors. Chris and his team went to work. They had several ideas for setting up the office so that it would keep its sophisticated aesthetic—popular with the grown-ups—while adding appeal for children.
They brought in crayons and paper. They set out bananas, apples, fruit bars, and coconut water. They also had a treasure chest filled with toys, but, not wanting to make the lobby feel too childish, they tucked it behind the desk. Two family care physicians were on-site, and two more One Medical employees took charge of the lobby. Everyone had a script to follow. It was time for the prototype.
Then the children started to arrive. Chris had recruited five families to come in for visits. Right away, the test ran into a bump—literally. The doorway at the Hayes Valley clinic had a small ledge that was navigable by wheelchairs but tricky for strollers. “Kids were nearly bouncing out of their seats,” Chris said.
The next surprise was how much was in those strollers. “Families come prepared. They’ve got toys, they’ve got extra clothes, they’ve got snacks. They bring siblings, grandparents, nannies.” The lobby, optimized for individual adults, became crowded. The One Medical team realized they’d need a slightly different lobby design for the family clinic.
The One Medical team had also underestimated the importance of the front desk staff. Kids were nervous as they came in. The clinic was a new place, and young children associate the doctor’s office with painful vaccination shots. “We lucked out with our prototype staff. Taleen and Rachel [two of One Medical’s office managers] switched into this super-welcoming mode, greeting kids, putting them at ease. It wasn’t in the script, but it saved the day.”
The exam rooms provided their own challenges. One Medical has their doctors sit behind a desk, encouraging a more natural conversation with the patient than the usual exam bed and rolling chair. But with kids in the room, the desk became an obstacle. “Everything the kids could touch, they touched. Every drawer was opened.”
Still, the kids were having fun, so the desks didn’t seem like a huge problem. Then Chris and his team interviewed the families. It turned out it was the parents—more than the kids—who were bothered by the exam room setup. The parents themselves needed reassurance from the doctor, but the exam room chaos made communication difficult. It was a subtle point, but crucial for putting parents at ease. Luckily, it was easy to fix.
When One Medical opened their first family clinic a few months later, they could see both adults and kids in the same location, and they could staff the office with family medicine doctors from the One Medical team. But there was more room in the lobby, no awkward desks in the exam ro
oms—and no ledge in the doorway.
14
Prototype
Thursday is a bit different from other parts of the sprint. Every prototype is different, so there’s no exact step-by-step process we can share. But after making hundreds of our own prototypes, we’ve come up with four exercises that always set us on the right path:
1. Pick the right tools
2. Divide and conquer
3. Stitch it together
4. Do a trial run
We’ll explain why each exercise is important, and show you how we do each one.
First, we need to talk about your tools—the objects and devices your team uses every day, the software and processes and methods they use to create high-quality experiences for your customers. Here’s the challenge: You probably can’t use them for your prototype.
Sorry. It doesn’t matter whether you work with designers, engineers, architects, marketers, or other creative professionals—or whether you run a store, provide client services, or build physical products. There’s a good chance that your team’s regular tools are not the right tools for prototyping.
The trouble with your team’s regular tools is that they’re too perfect—and too slow. Remember: Your prototype isn’t a real product, it just needs to appear real. You don’t need to worry about supply chains, brand guidelines, or sales training. You don’t need to make every pixel perfect.
The good news is that we were in this same situation not long ago. As designers of software such as apps and websites, we were comfortable with tools like Photoshop and programming languages like HTML and JavaScript. And then we discovered Keynote. Originally intended for making presentation slides, Keynote is a perfect prototyping tool. It has easy-to-use layout tools, so you can quickly make things look pretty nice. It’s organized around “slides,” which are a lot like frames in a storyboard. You can put in text, lines, and shapes; paste in photos and other images; then add clickable hotspots, animation, and other interactivity. You can even drop video and audio into Keynote when necessary.
We know it sounds crazy, but we’re 90 percent sure you should use Keynote to make your prototype. How can we suggest that when we don’t even know what you’re prototyping? Good question. Of course we can’t be completely sure—but in our 100+ sprints, Keynote has only come up short a handful of times.
(And yes, if you’re on Windows, PowerPoint also makes a fine prototyping tool. It’s not quite as nice as Keynote, but a quick web search will yield a number of template libraries you can use to make realistic prototypes in PowerPoint.)
Granted, most of the time, we’re prototyping software products such as apps or websites. For these prototypes, we use Keynote to create the individual screens. Sometimes, we run those slide shows full screen, and that’s good enough. Sometimes, we use specialized prototyping softwareI (yes, there is such a thing!) to string the screens together and load them in a web browser or on a mobile phone.
But it’s not all software. You read on page 176 about Foundation Medicine, a cancer diagnostics company whose product is a paper medical report. We designed their report in Keynote, then printed it out and showed it to oncologists. (Again, this kind of paper prototype actually makes sense.)
For physical products, Keynote will be less useful. You may need to use 3D printing or make modifications to your existing product. But then again, many hardware devices have a software interface. Recall the story of Savioke, where part of our prototype involved attaching an iPad to their robot. And what, you may ask, was on that iPad? Keynote. The hits continue.
Plus, for many physical-product sprints, you may not need to prototype the product at all. One of our favorite shortcuts is the Brochure Façade: Instead of prototyping the device, prototype the website, video, brochure, or slide deck that will be used to sell the device. After all, many purchase decisions are made (or at least heavily informed) online or in a sales call. This marketing material will give you a great start on understanding how customers will react to the promise of your product—which features are important, whether the price is right, and so on. And guess what: Keynote is the perfect tool for prototyping that kind of marketing.
We’ll admit we’re not experts on how to prototype everything. And Keynote is not always the perfect tool, especially if you’re working on industrial products or in-person services such as One Medical’s family clinic. But we have picked up some shortcuts over the years. Here’s a quick guide you can use to pick the right tools.
Pick the right tools
If you’re not sure how to build your prototype, start here:
• If it’s on a screen (website, app, software, etc.)—use Keynote, PowerPoint, or a website-building tool like Squarespace.
• If it’s on paper (report, brochure, flyer, etc.)—use Keynote, PowerPoint, or word processing software like Microsoft Word.
• If it’s a service (customer support, client service, medical care, etc.)—write a script and use your sprint team as actors.
• If it’s a physical space (store, office lobby, etc.)—modify an existing space.
• If it’s an object (physical product, machinery, etc.)—modify an existing object, 3D print a prototype, or prototype the marketing using Keynote or PowerPoint and photos or renderings of the object.
Building a prototype in one day sounds daunting, but when you put together a diverse sprint team you’ll have all the right expertise in the room. Chances are, a few people in your sprint will do most of the work, but we’ve found time and again that there’s a role for everyone. Once you’ve selected your tools, it’ll be time to assign some jobs.
Divide and conquer
The Facilitator should help the sprint team divvy up these jobs:
• Makers (2 or more)
• Stitcher (1)
• Writer (1)
• Asset Collector (1 or more)
• Interviewer (1)
Makers create the individual components (screens, pages, pieces, and so on) of your prototype. These are typically designers or engineers, but they could include anyone on your sprint team who likes to feel the force of creation flow through his or her fingers.
You’ll want at least two Makers on Thursday. We’ve told you some wild stories about robots and medical reports and videos, but just remember—the people on your team probably already have the skills to make prototypes for your business.
The Stitcher is responsible for collecting components from the Makers and combining them in a seamless fashion. This person is usually a designer or engineer, but can be almost anyone, depending on the format of your prototype. The best Stitcher is detail-oriented. He or she will probably give everyone some style guides to follow in the morning, then start stitching after lunch as the Makers complete their components.
Every sprint team needs a Writer, and it’s one of the most important roles. In Chapter 9 on page 103, we talked about the importance of words in your sketches. And earlier in this chapter we told you that your prototype must appear real. It’s impossible to make a realistic prototype with unrealistic text.
A dedicated Writer becomes extra important if you work in a scientific, technical, or other specialized industry. Think back to Foundation Medicine’s prototype of a cancer genomics report: It would have been tough for just anyone to write medically realistic text, so we relied on a product manager with domain expertise to act as Writer during the sprint.
You’ll want at least one Asset Collector on Thursday. It’s not a glamorous role (although “asset collector” does sound glamorous), but it’s one of the keys to rapid prototyping. Your prototype will likely include photos, icons, or sample content that you don’t need to make from scratch. Your Asset Collectors will scour the web, image libraries, your own products, and any other conceivable place to find these elements. This speeds up the work of your Makers, who don’t have to pause and go collect every bit and piece they need for the prototype.
Finally, there’s the Interviewer, who will use the finished prototype
to conduct Friday’s customer interviews. On Thursday, he should write an interview script. (We’ll go into detail about the structure of this script in Chapter 16 on page 201.) It’s best if the Interviewer doesn’t work on the prototype. This way, he won’t be emotionally invested in Friday’s test, and won’t betray any hurt feelings or glee to the customer.
After assigning roles, you should also divide up the storyboard. Let’s say your storyboard calls for a customer to see an ad, visit your website, and download your app. You can assign one Maker to create the ad, one to mock up the fake website, and a third to handle the app download screens.
Don’t forget the opening scene—the realistic moment that happens before the central experience begins. Be sure to assign a Maker and a Writer to your opening scene, just as with every other part of the prototype. For Blue Bottle Coffee, the opening scene was an article in the New York Times, and we needed someone to write a plausible article. (We’re not up for any Pulitzers, but faking one short article isn’t so hard.)
It’s important to give your opening scene enough time to be credible and set the stage. Don’t spend half your day working on it, but do make it believable.
* * *
As individual sections of the prototype near completion, the Stitcher moves in. It’s the Stitcher’s job to make the prototype consistent from beginning to end—and ensure that every step is as realistic as possible.
In FitStar’s sprint, John was the Stitcher. To ensure consistency, he pasted everyone’s Keynote slides into the same file, and then tweaked the fonts and colors so that the slides appeared to be one seamless app. To turn up the realism, he added detail to the sign-up screen, adding a slide with a screenshot of the iPad’s on-screen keyboard, to make it look as though the user was really typing.