Why design demos are so good?
Design demos are often a magical place to be. Hands-on participation of c-level, eng, and biz people, and every opinion matters. What is there to learn and how can we ensure our presentations with stakeholders have the same effectiveness?
It is always striking for me how many people are active in UI/UX meetings in comparison to engineering or business ones, and it has been like this for any company I worked for. I mean not only UI/UX team but external people like business/product people and developers fully participating. Let's do a quick look at why it is like that and what we all can learn from it.
🪄 We all love visual
Having visual aid to what you are saying is great, and what is a better place for this than a UI meeting? This one is self-explanatory, and you probably won't beat the design team in this field, but we all can do probably better and takes some lessons from them.
If you are engineering doing a sprint demo - consider creating short clips (GIFs) and putting them on a presentation slide with a short text explanation, instead of doing one long live demo or playing a 10-minute recording from an app or website. Bit-size chunks of visual aid are best.
🙋 Participants who actively care
If we don't understand "what is here for me" we are doomed to fail to achieve anything at the meeting. There is nothing that comes close to the design team demo, as it directly affects the product and thus business.
Consider doing more hands-only active workshops with only selected participants that care about this particular topic. If somebody is by design only a listener and you don't actively care about their input... well, consider providing the same information but as a written text, maybe email or page in Confluence or another tool.
🗺 Know where we are
On many technical demos we tend to jump from high-level to low-level implementation details a few times during one demo. It is important to avoid those as it is very easy to lose part of your audience each time you do this. From my observation design teams do it much better and 98% of the time they stay on screen-level which is easy to understand for all participants, and there are many visual clues about which product/process we are discussing at any moment.
Finding the right balance between general information and details is very hard to get right. If you need to jump into low-level details - can consider adding "breadcrumbs" where you are ex. "App/Account List/Account Details/Account Limits" on side of your screen or presentation slide.
📺 For remote meetings - it is very easy to focus on one person's questions and ignore the rest of your audience, try to avoid this and if somebody has more questions, consider asking them to stay after the call. This is a much harder problem during remote meetings as it is too easy to forget about silent ones.
💡On a feedback loop
Make sure that if someone asks or comments on your work - their input is taken into account. You don't always have to accept it but make sure it is addressed and the person is heard. If not people will stop being active in your meetings as their opinion won't matter, and if this is good for you... well, why do you do a call instead of a written announcement?
A good practice used by many designers is directly asking participants to put comments on ex. Figma file. Consider doing the same - if you have someplace (ex. Confluence) where you put demo materials after the call (or even better before it) maybe use this place to do a Q&A section where you can make sure people's input is taken into account.
🧩 Start with what is already familiar
The best is when you have some output to present in the same area that is already familiar to participants. Consider what you can build your story around and stick with it for a few demos, if you can spin demos around your company strategy and create coherent narration - even better! Quarterly goals might be a good consideration to start with. Jumping between remote topics from demo to demo or on the same one, can be as bad as jumping too often from high to low level.
On many design demos we often started with some familiar page (ex. home screen) or general design system updates, and then move to more specific topics.
- Use visual aid.
- Less but more engaged participants.
Check if maybe part of your demo shouldn't be a written announcement and another a workshop with a smaller audience.
- Stay on the same detail level, and if you jump into details - do it carefully.
- Feedback loop. Write down comments and make sure participants have their opinions and questions addressed.
If you noticed other tips & tricks from design meetings, or maybe you don't agree with something of the above - please leave a comment!