I previously wrote about my experience attending a one-week Design Thinking Boot Camp at the Stanford Design School (aka d.school). I was amazed with all the responses and comments I received through Twitter, LinkedIn and Facebook where people asked me to write more. It was even picked up and syndicated by Wired.com! Boot Camp was a really fabulous experience, so I’m excited to share more.
My first article centered on the art of empathizing with your user in order to really understand their needs. I told the story of d.school mentor Doug Dietz and how he redesigned scary MRI scanners to take kids on a fun adventure, and how in our own Boot Camp experience we were asked to “redesign the airport experience” at San Francisco International (SFO). In this article, I’m going to dive deeper into how we attacked the airport problem and what I learned from it.
To recap, after being dropped off at SFO, my partner Amy and I interviewed dozens of people about their feelings for the airport. Many of these interviews went nowhere – until we decided to visit the car rental plaza. There we found frustrated people who wanted to share their feelings! One of the most memorable was a New Yorker named Ray who had been waiting for almost an hour to pick up his car. He was so frustrated by the experience that he never wanted to use SFO again. Ray was angry and in a mood to share how he felt – complete with the kind of colorful language I’ve come to expect from native New Yorkers! We talked to Ray, and other users much like him, in depth before hopping on the bus to return to Stanford.
Upon returning to d.school, we met in a group of six students, plus our mentor Rich, and “unpacked” all of our observations. Each team of two interviewers shared a couple of their most interesting subjects. There were some really cool characters that people met, but after some discussion, the whole team decided that Raging Ray was a really compelling user to design for.
Now that we had a target user in mind, and an understanding of their story to help us empathize, we were asked to use a key Design Thinking tool. We had to create our Point of View statement. These generally take the form of:
- We met….
- We were amazed to realize…
- What if we….
Our point of view to kick off the next phase of the process became:
- We met Raging Ray, a deeply frustrated customer trying to rent a car
- We were amazed to realize that this last bit of his travel day had ruined his entire journey
- What if we could make the car rental experience a way to relieve the stress of his journey and welcome him to his destination
Once we had our point of view statement we were ready to start brainstorming. Our team spent an hour jotting down ideas about how we might make Ray’s experience better. Just a few of these included:
- Coffee and snack machines in the pavilion
- A “San Francisco” concierge desk to give you insider info on the city while you waited
- A central check-in desk instead of a line at each rental desk
- A restaurant-style pager that would go off when it was your turn
- An automated check-in kiosk that would page your phone when it was your turn
- A VIP lounge area
- Supersized touchscreens on the walls that would let you browse info about the city
- A system that would automatically deliver your luggage direct from the plane to the car
- And many, many more
We were all really excited. There were clearly so many things we could do here that we were sure we could make the world a better place for Ray! But, before we could continue on with our airport design project, we all participated in an exercise to help us get ready for the next step in the Design Thinking process.
The Marshmallow Challenge
We all moved to another room and were split up into teams of four. Each group was given a set of materials:
- 20 pieces of uncooked spaghetti
- 1 meter of masking take
- 1 meter of string
- 1 marshmallow
We were then given a challenge. We had 18 minutes to work as a team, with a new group we had never met, and build a tower that would hold the marshmallow as high off the table as possible. There were no further instructions. We were off to the races!
Our group quickly agreed that a pyramid structure was a good way to go. We started with a square base, but quickly changed to a triangular base for our pyramid. We debated about where we needed two pieces of spaghetti taped together for strength or whether we could risk a single piece in a key area so we’d have more material to build higher. As the clock ticked down, we looked at the other towers growing around the room. Some teams were looking nearly complete, and other teams seemed to be barely off the ground.
With about a minute left we put our marshmallow onto a spire at the top of our pyramid. It looked pretty good. With less than 30 seconds to go, we started to hear cries of anguish around the room as some structures collapsed under the weight of the marshmallow. When time was called, a judge circulated to measure each tower.
We were one of the first teams to have our tower measured and we were the tallest on the scoreboard – at least at first. As the judges walked around, we were eventually bested and started to fall down in the rankings. However, an interesting pattern emerged. Almost half of the teams scored zero! Their towers had fully collapsed right as the clock ticked down to the final seconds. They had waited until the last moment to put their marshmallow on top and had no time to recover when things went wrong. These teams completely failed the challenge!
After the final rankings were posted, everyone applauded the winning team, we lost by about 4 inches, and the mentors started to talk about what we could learn from this challenge.
It turns out this particular exercise, called the Marshmallow Challenge, has been deeply studied. We were shown a chart like the one above. It was no surprise that a group of trained architects would do better than business school graduates. But there was another category that was studied where the results were almost as good as the trained architects. Can you guess what it was? It was Kindergarteners!
Studies have found that a key to success at this challenge is iteration. Teams that spent too much time, organizing, planning and designing were prone to the problem we’d seen just play out. Their structure went untested until they were nearly out of time. If it wasn’t perfect the first time, they might completely fail. On the other hand, the kindergarteners generally start by putting up a structure of some sort, seeing the results, modifying the structure. Its naturally part of how they play. The kindergarteners were almost guaranteed decent results simply because they were iterating and getting better as they went. They might not match a group of trained architects, but they were blowing away other groups of high-IQ adults!
Our mantra for the rest of the week became: “put that marshmallow on the tower early and often!” This would deeply impact the next part of our project. We could not suffer from analysis-paralysis if we were going to succeed in this pressure cooker environment.
Our Prototype and the Guinea Pigs
It was time to start making! We cordoned off a corner of a design studio and started building our new car rental pavilion. We were only given 20 minutes to build. There was no time for fancy prototypes. We had materials like construction paper, pipe cleaners, cardboard, glue sticks, foam cubes and the like. Actually, it was kinda like all the stuff you expect to find in a Kindergarten classroom. Coincidence? Probably not!
We quickly sketched out a blueprint for our pavilion. It included a centralized check-in desk with wireless pagers, an automated check-in kiosk, a VIP lounge, a San Francisco concierge desk, high-tech touchscreens, free wi-fi and food and beverage vending machines. We constructed all of this out of a pair of wheeled desks, a spare couch and a bunch of construction paper over the course of just a few minutes. It was awesome. We were pretty impressed with ourselves.
Then it came time for the rubber to meet the road. We were told there was a pool of volunteer “users” outside who were ready to trial our experience. On our team, we quickly agreed to play various roles. Amy ran the check-in desk, while I manned the concierge desk. Joe was designated to take notes about how our users liked the various amenities.
After our super-quick build, we brought in our first users – one-by-one. We had time to run about five users through our prototype. In general, the rough nature of our prototype experience was no issue at all. Everyone understood what we were trying to do. After a brief role-play, we interviewed them (using our new empathy techniques!) to find what they thought. Most found something to like, but many were overwhelmed by all the options. While everyone was polite, we weren’t getting the delighted feedback we were expecting.
After running our users through, we sat down as a team to debrief. We generally agreed we had failed at our design. We though back to Ray and tried to figure out what he’d say about it. What did he need? He didn’t need all these fancy amenities. He needed a shorter line and a human touch. That’s all! We’d lost touch with our target user and these brief, informal user tests had shown that up immediately. What if we’d just spent weeks and thousands of dollars building a “real” prototype of this environment? What a waste that would have been!
Our Final Solution: The Rental Genius
We were given some time to modify our design before presenting it to the other teams, and a group of airport executives. Armed with more data, we threw out our whole concept and slimmed it down to bare bones. We threw out all the desks and all the amenities! When you entered the pavilion you were instead greeted by a car rental genius with a wireless tablet (hat tip to the Apple Store). Your genius would swipe your driver’s license or credit card and look up your reservation. You could pick insurance options and your car right on the tablet and sign all your paperwork. You were ready to go. It was much simpler and it felt like Ray would have liked it.
Due to the rapid-fire nature of the week, we didn’t get a second round of user tests — which would have been an obvious next step. However, we did construct a new, simpler prototype (in only about 5 minutes) and demonstrated it to the group. It felt like a good answer, and we’d clearly come a long way. Feedback from the airport executives was really positive.
Moral of the story: Get that marshmallow up on top of your tower early and often! Design, test, repeat.
Steve is the VP of Cloud Products at Citrix where his team builds software products such as Citrix XenServer, Citrix CloudPlatform and Citrix CloudPortal Business Manager. His team is currently using Design Thinking techniques to build an all-new software product scheduled to ship in early 2015. He’s pretty excited about it.
Follow @virtualsteve on Twitter