The art of the demo

Issue 099: Show, don't tell is dead. Long live show AND tell

Jul 3

Demonstration: The action or process of showing the existence or truth of something by giving proof or evidence. The demo is the amalgam of your proof of concept.

In 2015, I was in San Francisco with other Black Pixel team members. We were there to pitch working on a project with a large client—a product I love. We met at a Starbucks across the street to prep for the meeting. This was a project I wanted to win so bad that I went a little extra beyond our pitch decks. I built a prototype of a mobile app in Origami Studio. For me, this wasn’t speculative work, it was part of the story. I hoped for a “whoa” moment in the demo to get the decision-makers excited about working with us.

We conducted our usual routine in the meeting of intros, sharing a bit of previous work, and running through our pitch deck. We blocked a few minutes to do a quick demonstration of the prototype. I launched the prototype on my phone and connected it to a TV screen. I conducted a demonstration of a key moment in the product experience.

The silence of the room was broken with one word…”whoa.” We ended up winning the project and the product lead told me several years later, "it laid the foundation for how we ran and marketed that project end-to-end!"

That’s the power of the demonstration (demo for short). The demo is the amagalm of every department’s hard work manifested in a walkthrough of the experience. There is no method of storytelling in product development. If Helen of Troy was the face that launched a thousand ships, Doug Englebart's "Mother of Demos" was the demo that launched a thousand ideas.

Englebart’s 90 minute demo in 1968 sparked inspiration of key software concepts people are still working on today. The demo is not a sales tool, it’s a storytelling tool. Let’s look at the power of the demo, how you can use it in iteration cycles in the very beginning, elements of what makes a good demo, and fostering a culture of show and tell on your teams.

Demos are the finish line of an iteration cycle

A common missed opporunity in demos is people feel it's something done once the product is built for the purpose of sales. The opportunity lies in every iteration cycle, whether it's a two-week sprint or another method you use. Ken Kocienda is an engineer at Humane, but most known for being the creator of autocorrect and multiple iterations of the keyboard for the iPhone. In his book Creative Selection, Kocienda tells stories about the multiple iterations of keyboards for the iPhone and how the infamous Cupertino company used demos as a way to align and get feedback. In Sachin Rekhi's blog post, he sums it up very nicely:

Ken describes the process by which they would prepare product demos for their own team and then for various leaders, use that demo as the primary avenue for feedback, and then continue to iterate to the next demo, followed by more rounds of demo feedback, and so on. He calls this process creative selection. While at the surface this may sound like a typical product review process that many companies have, there was so much that was different about it.
First, demos were done early and often, even at the prototype stage. These were not just reviews at the end of the process to get final approval, but instead they were done to show early progress, determine viability of the project, and make fundamental design decisions. The goal was to produce an initial prototype to demo as quickly as possible and then continually refine the prototype through subsequent feedback sessions. These demo sessions with senior leaders happened on a weekly basis, not months apart.

The end of every good sprint cycle should be an array of demos by product, engineering, and design. Demos are great for soliciting feedback. Most importantly, it gets people excited and is an opportunity to share work.

I worked with an ex-Apple engineer on a startup idea—someone who'd become a great friend and mentor. He is one of those rare talents who knew product, design, and engineering equally as well. As I'd work on design concepts, he'd take the assets, put it in Xcode, and run a build. With a little bit of functionality added, he handed the phone to me. We started playing around with it. Much of the interface were rough boxes of interface objects, but it forced us to start using it, talking about what's wrong, and most importantly, where we can improve.

The elements of a memorable demo

Poorly conducted demos can create the opposite desired result. If you don’t craft a compelling story, people will be disengaged like being at a bad movie. I found four useful focus areas to conduct better demos: information fidelity, linear, story arcs, voiceover, and visual affordances.

Information fidelity

For the love of god, stop putting the same woman in the red shirt in your app mockups. When you're building a product, it's natural to put funny names or locations. Sometimes it's for security reasons. For example, we made profiles at One Medical that was obviously fake to ensure it wasn't perceived as breaking any HIPAA compliance. However, at the demo level, you want a story that people can believe this is a real person, or them. In the demo I mentioned in the beginning, I put the profile photos of the stakeholders I met with so they can get a sense that it's their experience vs. one I fabricated. When Ha Phan was leading design at GoPro, she spoke a lot about the storytelling tools they built. In user testing, they would use footage based on the person's interest, or their actual footage if they opted in. The information presented in a demo needs to be relatable. If you show placeholder data, it becomes less relevant to the person.

Linear story arcs

This is not the time to get fancy and have a story like Pulp Fiction where you start at the end (spoilers). Linear story arcs are predictable. When you are predictable, it reduces moments of confusion. Don't flail around your Figma file and focus on one moment at a time. We'll talk about how you can use visual affordances to address those things.

Voiceover

Voiceover is your best friend. The most common mistake people make is talking through everything that is in front of the slide. The visual presentation should aide in what you're saying.

Avoid talking through ever single detail on screen of the demo. Imagine a sports commentator calling out what every single player is doing. It'd be information overload and doesn't focus on the most important thing. Instead, they call out the primary action that's happening.

Visual affordances

This is the semiotics of your story and interface. Including visual queues to the demo help articulate the rest of the story instead of having to voice over every single detail. This may come in the form of additional metadata, showing other features in clear view without covering it. The

Fostering a culture of demos

Never think the design will speak for itself, as you'll be extremely disappointed when people don't engage with what you've created. "Show, don't tell" is a great start, but strive for "show and tell." When we were kids, there was no greater day for everyone in the class to share something and talk about it. One day, I brought my pet giant lop rabbit and it was game over.

There's the famous saying, "A Prototype is worth 1000 Meetings." The demo is the way to get feedback on the entire experience. Gadzhi Kharkharov, Design Engineer at Retool and former Webflow Designer, is one of the best in conducting demos. He'd record a Loom video, walking through the demo, and share a working prototype that people can play around with.

Demos and prototypes don't answer every question, but they address a lot of them. It’s the checkpoint everyone can react to and align on—cutting through the noise of confusion and misinterpretation. In your next team ceremony, take your work you want to share and make it a demo. I assure you it'll be productive and fun.