7 tips for better design demos
How to confidently convey your work in any situation
Over the years I’ve been working as a designer in very different domains. From static graphic design to interactive product design. Despite the obvious differences, one of the similarities is having to effectively present your work.
I’ve been evolving how I do this for more than 13 years, and as a product designer demoing is super important. You do it at all stages of product design and development. It creates alignment and lets you share relevant context, along with a pressure to deliver. I would even say that it can be good for team pride, as these are moments for your team members to show off their great work.
Demos can take many forms, from a low-stakes walkthrough with a colleague to a high-stakes presentation to a C-level executive. There isn’t a solution that fits all, but there are some tips that can help you assess what to prepare and how to deliver it. That’s what this is about.
1. Understand purpose & audience
Before you even start thinking about preparing a demo, it’s key that you have a solid understanding of its purpose and your audience. These will heavily define what your demo looks like.
Ask yourself, what is the goal of my demo?
You may be trying to share progress or get alignment with your team, or maybe you’re just looking for feedback. You could even be looking to get buy-in from a group of stakeholders, so you can move forward with a particular direction.
It varies and, depending on the answer, what you have to prepare will also vary. This isn’t the only variable — you also have to consider the audience.
If you’re trying to get alignment, you’ll be doing that with the team you work with on a daily basis, which likely means they’ll share tons of context with you. If you’re looking for buy-in, that probably requires the involvement of high-level stakeholders, who often come with less project context, but more context on a strategic level. So you can see that purpose and audience are very connected.
My general rule of thumb is the higher the stakes, the more preparation you need and the more well thought-out the demo needs to be. When you thoroughly understand your goal and your audience, you’ll have a good starting point.
2. Follow the user journey
As you’re demoing the experience you’ve designed, don’t focus so much on the feature set or capabilities that you’re adding. Instead put yourself and your audience in the shoes of a user, and walk through it the same way a user would experience the product.
If you can, be specific. You can start by saying something like “Let’s imagine I’m a [name or role] and I want to be able to [what they’re trying to do] so I can [their actual goal]”. By doing this you’re not just embodying your user, you’re embodying their needs.
It’s all about storytelling, and in this case you’re telling the story of a user. This not only grounds your demo in something that could actually be real, but it’s also easier to follow, relate to, and understand the value of.
A good reference to plan how to tell your story is the hero’s journey, where the call to adventure is basically the task they’re trying to perform. Follow that by outlining the problems they encounter in their normal journey until they get to the revelation, which hopefully is your design solution.
3. Show more than you tell
Is there a better way to demo that isn’t actually showing the thing? No.
This is where understanding your audience really helps. Whatever you show needs to meet their expectations and the level of context they have. Bear in mind though, even when someone’s context level is low, it’s always easier for them to pick things up as they follow along with a prototype — so avoid the temptation of spending the beginning of the session doing a preamble before you actually show the thing.
If you’re sharing something within your team, it’s perfectly acceptable to share low-fi designs that are enough to get the idea across. On the other hand, if you’re sharing something with stakeholders that will need to make a decision after your demo, it’s best to get as close to high-fidelity as possible. Showing the actual experience is less ambiguous and requires less from your audience.
Keep your demo “clean” — focus on the content you’re delivering and remove embellishments. If we’re talking about a slide deck, keep it simple and only have what you need to make your point. Sometimes you might need a visual that illustrates what you’re saying to make your point, which is totally fine. What you don’t need is to have the exact thing you’re saying typed out on a slide. It’s all about going for something that is complementary rather than redundant.
On the other hand, if your demo consists of going through a prototype, it’s important to stay “on script”. Don’t over-explain or worry about showing all the cool things you’ve built, you can always let the audience play and interact with the prototype.
Stick with your story and cover only what is actually relevant for the purpose of the demo and, as much as possible, try to let the experience do the talking.
4. Be prepared
Never start a demo by apologizing. You’re not just lowering expectations, you’re telling your audience that you should have something better than what you’re about to demo. You should start the demo by setting expectations and telling your audience what is expected from them. If you don’t, you’ll have a much harder time keeping your audience on track.
Be prepared to deal with deviations though. For instance, even when you ask for no interruptions, I can guarantee that you’ll be interrupted. How you deal with it will define the success of your demo.
Being prepared means:
Preparing the narrative: What are the key beats from your user journey? Try to turn that into a guideline. This can take the form of a script or speaker notes — anything that helps you prepare what you’re going to demo and what you’re going to say.
Most of the time you’ll realize that you’re saying too much or that you’re rambling a bit in a certain part, so you can address those before the demo.
Doing a dry run: I do this by setting a timer and going through the demo in my head, or even saying it out loud if there isn’t anyone around. This helps you prepare your narrative even better and assess whether or not you’re taking too much time. My rule of thumb is that the demo should take, at the most, one-third of the time of the session, to reserve the other two-thirds for discussion.
Sharing it often: Make sure that you have some of the audience already “on your side”, the more the merrier. You can do this by simply sharing your work as you progress. Not only will people be able to digest things with time, but also you’ll get questions and comments that will likely come up during the demo. By doing this in advance you give yourself time to prepare for all of those questions.
Last but not least, be prepared to say “I don’t know”, or “I’ll have to think about it”. The point of the demo is sharing the work at one specific point in time. You don’t have to know the answer to all the questions in the world, nor do you have to answer them in the moment.
This can save you from derailing your demo, and even beyond that can save you from jumping into bad solutioning before even having time to understand the question. That said, if you do say “I don’t know”, tell the people you’re presenting to when you will get back to them, and don’t pick a timeframe that is too onerous. Other stuff will come up!
5. Start strong, but end stronger
The beginning and end are the most important moments, so make sure you hammer down on your key points in that part of your demo. Start with contextualizing why your team is doing what you’re doing, but make it short. You can give more context as you’re showing the thing, as I mentioned above, so don’t fall for the temptation of telling too much.
You can also use the end of your demo to emphasize what you said, or even to add a bit more. Just be conscious of your audience’s attention span.
Even if your story is engaging, people have a limited memory, and they tend to lose a bit of focus in the middle of the presentation. Humans are naturally wired to remember the beginning and the end better, so make sure that you don’t waste those moments.
For instance, start with a bold statement that promises something that comes back at the end of the presentation. I like to think of the beginning as the set-up and the end as the delivery. If you do it right, connecting those two moments will unlock the rest of the story, and your presentation will stick in people’s minds for a while.
6. Make it memorable
A little humor might help you tear down some walls and keep people engaged. Just be aware of your audience and what kind of humor is acceptable, and make sure that the joke is part of your story.
Your goal isn’t for people to leave the demo remembering a random joke you told — you want them to remember the joke because it connected so well with your story. If they remember that, the story will also stick better.
7. Save time for feedback
The duration of your demo will define how much you can cover. If you don’t plan time for discussion you’ll either leave the demo without the thing you were looking for, or you won’t even be able to demo everything because the discussion took over the demo.
As I mentioned above, a good rule of thumb is making sure whatever time you need to demo, that you have at least double that for discussion and questions. Bear in mind that the more time your demo takes, the more difficult it becomes for people to comment on it.
A good indicator that your demo is taking too long is the 20-minute mark, because after that the session will have to extend for more than an hour. After we’re done presenting, sometimes we feel that it’s “mission accomplished” and forget the whole reason we were presenting in the first place.
A few things that can help you guarantee a successful demo are:
Having a concrete objective: This will let your audience know exactly what you expect from them, which is key to getting the kind of feedback that you’re looking for.
Having an agenda: This not only gives yourself a guideline for the demo, but also helps establish the flow of communication. Your audience will know what the main beats of the demo are, as well as when they’re expected to contribute.
Having a note taker: After demoing and discussing for a while it’s easy to forget important things that were said in the beginning. To help with that, ask a colleague to take notes during the session. It’s important that you’re not the one taking notes. No matter how good you are at multitasking, you’re either participating in the conversation or you’re taking notes — doing both well is very hard.
Final recap: After getting all the feedback, a good way to conclude your demo is to briefly recap the discussion and go through the key areas that need action. You can even use the notes and share them afterwards to make sure there’s agreement on what needs to be done and to figure out when you should schedule follow-up sessions.
With that said, remember that you’re in charge of what happens next. Depending on the audience and the objective of the demo, not all feedback needs an answer, and it certainly doesn’t all need to be taken. Be clear about what you’re doing with that feedback, including rejecting/deferring action on it.
Beyond the demo
When you think about a demo, you probably imagine a meeting where a person presents something and everyone else is watching and judging. However, there are other ways to demo your work that can help you build a stronger design but also share context with your audience and get them onboard even before the demo happens. If you’re presenting remotely, you don’t even have to share your demo with everyone at the same time.
Quick screenshots, screen recordings, or animations: Perfect to showcase micro-interactions or short flows. You can share them over Slack and get feedback on something very specific without having to put an excessive amount of effort into it.
Asynchronous walkthrough: This is essentially a pre-recorded demo, when you need to share a concept, or a more complex flow that requires some explaining. It’s a bit more effort than the previous example, but it’s still a good way to share ideas with your team and potentially get some thoughts too. This is also good to use before a meeting to improve people’s context, if you’re planning to discuss the same exact thing in a meeting.
The length of the recording is important to keep in mind. The longer you make these walkthroughs, the less likely it is that people will actually watch and give you feedback on it.
If you can’t help but have something that is a bit extensive, try segmenting your demo into pieces that represent major steps in the user journey. You can have separate videos, or you can timestamp sections in one video and refer to that in the beginning or in a description. Doing this allows your audience to watch only the bits they’re interested in.
Prototype + task: Often we do this mostly for user testing, but this can also be a good way to get fresh eyes on something you’re working on. Just share your prototype with a colleague and give them a task to perform on it, then ask for their thoughts.
As I said in the very beginning, a demo is important at all stages of product design. Sharing progress and context with your team and stakeholders won’t just help them get context in advance, it will allow you to get them on board and potentially even share ownership, especially once you take their feedback into account as you evolve your designs.
With that said, don’t limit that feedback to the scope of a meeting. If your demo is a prototype I encourage you to share it afterwards, because it’s one thing to see you walk through the experience, but another thing to actually experience it. Using is believing, and if a picture is worth a thousand words, a prototype is probably worth a good number of meetings.
Practical tools & tips
Prototyping
Building a prototype is simpler than you can imagine, the complexity only depends on the type of interactions you’re building. You can even build one using Google Slides and hyperlinks.
Figma is probably the simplest way I have to build one, since that’s where I create designs in the first place, but if you want to mock up richer interactions I recommend using tools like Principle, Framer or even After Effects. Ultimately, if your team has the resources, a better option is to have a UX developer that can prototype in React.
Just bear in mind how people can also use this prototype in the future. Here are some tools I use, with some pros and cons for each:
Google Slides
Pros:
- Easy to share & digest — anyone with a link can access it and walk through it. You can even make use of the presenter notes to add extra context.
- Nobody needs special permissions or to learn a new tool.
- Anyone can leave comments.
- Demo ready.
Cons:
- You can’t really design on Google Slides, so it requires a bit of double work.
- It’s good for a walkthrough, but not for something people can actually experience on their own time as the real product.
- Iterating is a lot of work.
Figma
Pros:
- It’s more time efficient, since you’re prototyping in the same place you’re designing.
- It’s fairly easy to share and demo.
- Most people should be able to access it.
- You can provide an experience that feels similar to the real product.
- Anyone can comment in the prototype.
Cons:
- You can’t build rich interactions.
- Not everyone actually knows how to use it.
Pros:
- You can build rich interactions.
- Feels more like a real product.
- You can import designs from Figma.
- Allows recording.
- Easy to demo.
Cons:
- Not so easy to share.
- Doesn’t allow for commenting.
- Only works on Mac.
Adobe After Effects
Pros:
- You can mock up any kind of interaction, even the kinds that aren’t technically possible yet.
Cons:
- It’s not interactive.
- The learning curve is a bit steep.
- You can only share videos.
- Not super easy to include in a live demo.
- Doesn’t allow for commenting in the prototype.
- It’s expensive and not always available for UX teams.
React
Pros:
- It’s the one that is closest to the actual experience.
- Anyone can experience it as if it was the real product.
- It’s a bit more than a concept, because it’s not just a visual prototype, it actually works.
- Eases the transition from UX to Engineering
Pros:
- You need someone with the expertise in your team.
- Doesn’t allow for commenting in the prototype.
Recording
If you’re trying to make your recording time-efficient, I recommend doing some prep work, like writing a short script. You don’t need to read from it, but you can have it as a fallback option, in case you get stuck.
There are a couple of tool options for recording:
Google Meet/Zoom: Create a call on your own, start sharing your screen, and record that meeting. When you’re done you’ll have a video that includes your camera and your screen recording. This is especially useful because it doesn’t require any post-recording work.
Zoom’s picture-in-picture recording is a bit nicer than what you can achieve with Google Meet, because it doesn’t sacrifice much screen real estate in order to include the presenter’s video.
QuickTime: You can record a walkthrough first and then record your voice and camera separately, or the other way around. This helps to stick to a specific time limit, but it requires an extra step to stitch the two videos together, which is fairly simple to do with iMovie.
Other considerations
Be mindful of the video dimensions — understand that most people will watch this on a laptop, so try to optimize for that size. There’s no point in demoing on a 30-inch display if people won’t be able to read the text when that scales down to a laptop screen.
Be mindful of the video size — try to optimize it for online sharing.
Consider posting the video to Google Drive and set up a sharing link. It might take a few minutes to process before it’s ready, but after that it’s easier to share across the company. If this is an internal demo, you don’t need a high-res 4K video to get your point across, and the easier it is to share the better.
Thanks for reading! 💚
