In my years as a professional trainer and ScrumMaster I’ve seen and done hundreds of demos. A lot of time demos are done to show off a product or train some users, here are some of my thoughts on how to create demos that users love.
Have a dry run
Seriously, the number 1 thing you should do when doing any speaking in front of people is a dry run. I always feel I’m at my best the third time I deliver something. The first time I’m still gauging content, the second time I’m noticeably more confident and have eliminated the irrelevant stuff. By the third time it’s slick and I know exactly where I’m going with things. My suggestion is to have a dry run to yourself, then have a practice in a safe-to-fail environment (maybe with a colleague) to obtain some feedback. Then by the time you demo, you stand a chance of really wowing your users.
Keep it focussed
A demo needs to a focussed objective. What are you trying to achieve? Who’s the demo for? Creating the right content for your users can be tricky but is essential for a successful demo. If your user has never programmed a line of code in their life, they’re not going to care about (or understand) how clean your code is.
Circulating scenarios in advance can help set users’ expectations of what will be covered. When doing the demo, try not to deviate from the agreed scenarios too much. Users will ask questions but if they’re not directly related to the scenario, park the question for later. If you deviate too much, you run a risk of overloading the user with too much information.
Use Real(ish) Data
No-one likes demos with ‘Lorum Ipsum’ text and names such as ‘Mr Test Test’. Try to use example data which bears some resemblance to real data. If you are entering data into an address field, fill an address in properly, don’t put a dot in the field and expect users to just accept it.
Involve the users
What better way is there of showing someone how easy and amazing something is than letting them do it for themselves?
Some of the most effective demos I’ve done involve providing a narrative and asking a stakeholder to drive the keyboard and mouse. So at your next sprint review, try to guide your Product Owner (or other stakeholders) through the process. Try to let them figure as much out as possible themselves, if they struggle to figure out, it may highlight UX issues that you may not of expected. For remote demos, this is easily done using screen share software such as join.me or WebEx.
Confirmation of Understanding
In order for communication to happen, both sides need to develop a shared understanding of the message. As a trainer, we need to look for understanding from the users to confirm that our message has been received. Ideally, this should be a play back of the message we are trying to convey. If you are training users on a piece of software, they will need to try it themselves and ask questions before they understand what you’re trying to show them. My favourite way of doing this is to ask users to pair up after the demo, run through an exercise while explaining to each other what they’re doing and why. Don’t underestimate the value of this item, if your users don’t understand what they’re doing, you have not delivered any value to the business.
Ask for Feedback
After any meeting or demo, I like to spend a couple of minutes obtaining feedback. This allows users to feel they have an input into the way I work and I learn something from the user’s perspective. I use a grid as shown here. The left column is stuff that the users liked, the right column is stuff they would change if I did another one. It’s much more effective than feedback forms or just asking for feedback. It takes a brave person to ask for feedback and I believe the users respect that.