Given that the purpose of software demonstrations is to (1) build a vision of a solution or (2) show proof, everything we do in a demo needs to support these objectives. In demos we are working to “suspend disbelief” in our customer audience – in other words, we need to make the demo appear to be as close as possible to real life. Anything we do or show that is obviously fake hurts our cause.
Two examples of making a demo obviously appear to be fake are:
- The use of silly or obviously fictional names (e.g., “Mary Manager”, “Dave Departmenthead”, “Sarah Superuser”).
- Naming files or processes “demo” or “test”.
To these I add a third, slightly less obvious item:
- Dates and date ranges.
I was watching a demo recently and noted that all of the reports that were run and presented showed data from 1998 and 1999. This automatically makes one wonder about the software: Has it been updated since then? Are their QA test suites that old? Have they tried the system with current data?
The old data also impacted my attention. Instead of listening and watching the next steps in the demo, I found myself wondering and thinking about data from 1998…
The morals are clear: Use real-life names (people, files and processes) and use dates that are contextually relevant for the customer’s situation.
2 comments:
Agree with you on dates, but recognize at the same time that it's impossible to keep samples updated on a quarterly basis, and for small teams even annually is probably not feasible. Every decade should be workable :)
I'm going to disagree on the naming rule, but very interested to hear your thoughts. We've been debating that internally, and my position is that last names provide no value in a demo or sample data. Nobody says "give that to Mary Birk," they say "give that to Mary." Using roles in the last name provides a context to who the person is and immediately defines in the viewers mind what they should expect of that person. What features might they be interested in, what data/reports are are they using, how do they relate to the current story being told, etc...
Hi Matt,
Excellent comments. There appear to be two separate issues here, perhaps:
1. What is seen on the screen.
2. What is delivered verbally.
What is seen on the screen (what your software is showing) should look as realistic as possible.
What you articulate verbally, however, can/should be a modified version to match the audience's roles and job titles.
Additionally, the more you stay in "you" mode, the better the reception by the specific audience members. For example, "So, the fast route for you to complete this is to simply click on your record..."
Post a Comment