Select Page

I recently gave my first demo of an application a few months ago. The application consisted of a form that would store information in a database, then another application would access that data and give users the opportunity to work with it. Before going live our team wanted to show how the form would work.

Before the meeting I spent time making sure I would cover every feature. I approached the demo as I would a set of test cases. Showing how the form would handle all possible scenarios would be sufficient, I thought.

I began the demo by showing what would happen if I submitted an empty form. All of the validation errors appeared. Then I walked through the majority of the fields (not all, as there were plenty) to show what input was acceptable. During the demo I made sure to give equal amounts of time to each type of feature (e.g. ADA compliance, invalid input, use of cookies, etc). I finished by submitting a pre-filled form, showing the results of a “happy path.”

The UX designer of our team was there, and was kind enough to give me honest advice after the demo. From the demo itself and the conversation I had afterwards I gleaned the following:

  1. Take a function-first approach instead of a feature-first approach: I prepared my demo with the goal of demonstrating every feature relevant to the user. This resulted in an unnatural flow. I ended up jumping to different parts of the form because I was following my list. A function-first approach would have asked, “How will the user use this?” and demo with that mindset. In my case, I should have started the demo by filling out the form, and showing validation along the way, instead of demoing different types of validation. A function-first approach is less confusing and easier to follow.
  2. Not every feature requires the same level of attention: Our application needed to be ADA compliant. Even though we fulfilled this requirement, it was not necessary to demo because we knew the people who would be at the meeting would not use this feature. This did not make the ADA compliance less important, just less relevant to the demo. I briefly stated that our application was ADA compliant, then moved on. Extensive testing ensured that this functionality worked, but it had little place in my demo.
  3. Be excited: Nothing kills the mood in a room faster than a lack of enthusiasm. You helped build an application and you know how much effort it took to reach the finish line. Show your excitement! You helped develop something cool while making users’ lives easier. It is a win-win situation, so demo like a winner.
  4. Have a Plan B: Nothing goes wrong until it is time to demo, right? Make sure you have a backup plan. In this case, we deployed the application to a test server, but I also had the application running locally in case the test server failed. If Plan B fails, then reschedule the demo (or create a video using a screen recorder beforehand).

Since this first demo I have noticed the difference in taking a function-first over a feature-first approach. Demos are easier to plan, I receive far fewer questions, and the demo is shorter. If users want to see something that I did not initially demo I will show them on an on-demand basis.

How was your first demo experience? What have you learned since that time?