My Golden Rule of Teaching Prototyping
Hint: everything is feedback
This is a reflection on teaching prototyping, based on a corporate design workshop. Some details of the brief, work, people, comments have been changed. Absolutely no knock-off Legos were harmed.
The climax of a workshop for a facilitator often happens at the end, a dramatic reveal to see if the participants really understood what was taught.
Not long ago, I had an insightful reveal myself. I was about to wrap up a 3-hour prototyping session with twenty plus people at a tech company that represented sales, construction, IT, accounting, administration, design, marketing, HR. Half wore navy blue polo embossed with a gold corporate logo and half chilled comfortably in business casual attire appropriate for the summer heat in Bangkok.
All sat at attention in their teams with a set of knock-off Legos in front of them. I sent one lucky person outside the room and gave the remaining six teams five minutes a challenge: build me a prototype of a gas station.
The exercise was my way of preparing a cohort of inter-departmental corporate officers to make physical mock-ups that they would later that week. Prototypes of what, you say? Of their colleague’s new office space.
The workshop was part of a series workshops teaching design thinking through a hands-on brief of redesigning their colleagues’ office space. Up until this point, the team had already made observations and interviewed their colleagues, framed a POV statement, and brainstormed possible (and impossible!) solutions. They are ready to meet their esteemed users to check their ideas.
I had told them that a good prototype should be recognizable without you being there / much explanation. Made sense, right? If the users don’t know what they’re seeing, how will they know how to interact with it? So I asked that the teams remain silent to test this criteria, when the “outsider” member came back in.
“It’s a gas station!” she exclaimed, as if she had just won the lottery. The whole room roared in celebration, and Lego-like bricks were flying everywhere like confetti at the finale of a pop concert.
Upon closer inspection, the facilitators (moi) saw that one of the teams had spelled out the name of a brand of gas station next to a few blocks of LEGO that resemble cars and trucks, and called it a day.
Smart move. During the debrief, we had a very serious discussion about it. Building a quick and recognizable prototype that represents an idea’s main feature(s) is a great first step. The second, arguably more important step, is to listen to the users as they interact with that prototype to see what they think about it. Ask why! Capiche? Heads nodded.
“Do you know what I’m trying to prototype?”
Next week rolled around and every team brought in their prototype office space. As I went around the room asking for the feedback they got, it dawned on me that the “build a gas station” exercise was a little too sticky. A few teams got some insightful thoughts, but most stopped at the “I recognize it” and “I like it” comments without meaningful, substantiated insights.
A good prototype became one that looked good to the users, a nice object rather than an excuse to talk about a pain point. Of course, the prototype must be recognizable but that is never the end goal.
The night before my memorable “gas station” workshop and after the umpteenth update of Google Slides, I settled on real estate-related examples to share what a prototype is meant to do for potential users: a floor plan of a house to address allocation of space, 3D rendering to address external look & feel, and a sales gallery to stimulate a live-in experience.
The customized examples did not land. And I had a learning moment.
In design mindsets parlance, a prototype is a way of building to learn, of bias-ing towards action, and of showing (not telling!). It is not a solution, but a low-fidelity mock-up that users can interact with in order to give us feedback. Feedback that tells us: what is working, what doesn’t, and most importantly, does it really satisfy a need?
In a well-crafted repertoire like The Wallet Exercise, I might teach prototyping by discussing its specific instances:
- Physical prototypes e.g. using paper to make a wallet that doubles as a family photo album
- Experiential prototypes e.g. playacting the use of a wristwatch-wallet to pay for street food
- Digital prototypes e.g. a wireframe for a cryptocurrency marketplace for Millennials
A new solution might require a combination of these and/or other delineations of prototypes not mentioned here. What is important is that a prototype sparks a conversation and tells you if you are on the right track.
Is there a rule to keep in mind when teaching prototyping? Glad you asked.
The Promised Golden Rule
There are many catchy phrases reminding us to prototoype — our old friends show don’t tell, bias towards action, fail forward, or build to learn. But once you have a prototype, what do you do?
If I could go back in time and re-do the presentation slides, I would probably make a concluding slide that briefly but boldly state in modern sans-serif font:
Every response is feedback.
Once you cross over into “prototype land”, each and every piece of feedback from your user should be taken as an insight that you can act on. Let’s try a thought experiment with the office space redesign — so in this case we’re talking about a physical prototype.
There were several learning moments that the team faced. Here are a few user response/designer action pairs that I could recall from the project:
Response: If your users don’t know that you are presenting a bedroom vs. a living room, that means the fidelity (level of detail) is too low.
Action: Update your prototype or build/sketch/render a new one that clearly shows the room, label with words if you have to.
Response: If your users don’t like where a piece of furniture (a chair, table, storage) is positioned, that means they don’t like it!
Action: Let them move it (by sketching or physically moving it if they can) and ask them: Why?
Response: If your users say, what a beautiful kitchen!
Action: Say: “Thanks! Is that all?” Remember, you are there to learn whether your idea will help your user — not to get affirmation.
It is possible that it looks “too nice” and your user doesn’t want to play with it, fearing they might “break it”. If that’s the case, you can lower the level of detail e.g. use a sketch!
It is also possible that they want to please you, say, if you’re their boss. In that case, let someone else present or have them submit feedback anonymously. Or bribe them with the lottery. (We haven’t tried so let us know if that works.)
Keeping this mantra in mind has since helped me become less defensive about prototyping while keeping a curious mindset about learning as much as I can.
Learn first, sell later
Teaching prototyping is never easy. (Is teaching anything easy? We wrote before about designing a learning journey with the Rasch model. Thank you to all the teachers Zooming from home and taking care of their kids during this pandemic).
So maybe we can start with the idea that we prototype to learn and take all responses as learnings in disguise. Every response is feedback should tell you that you don’t need to “sell” your prototype to your users. Show them what you made in response to what you heard about their pains, aspirations, stories. Does this prototype of a shiny new product/service help them do what they want to do?
Does it, really? If you are really designing for your users, you will make doubly sure. If not, then you get a low-guilt, minimal-investment re-do: after all, you’ve only wasted some paper and maybe a few hours right? Prototype again. Iterate. Complete the design hexa-cycle.
And remember: it’s always a gas station!
Just kidding.
Every response is feedback.
