Demo Prep: A Pattern Language for the Preparation of Software Demonstrations

By: T. Coram
Published in: PLoPD2
Pages: 407-416
Category: Customer Interaction

Summary: Preparation for customer demonstrations.


Pattern: Element Identification

Pages: 408-409

You're preparing a customer demonstration. Identifying exactly what should be demonstrated is a critical part of instilling customer confidence. Identify the key areas that concern the customer. Present demonstrations to alleviate the customer's concern that what is being developed is correct and will work the way the customer expects.

Pattern: Catalytic Scenarios

Pages: 409-410

You're ready to start a project. Requirements have been agreed upon. The customer has specified what he thinks he wants, but use demonstrable scenarios to be sure you and the customer agree on what is being built. Keep the demonstration uncomplicated and succinct.

Pattern: Mutable Code

Pages: 411

You've used Catalytic Scenarios and evaluating the effort to develop them. The level of coding for developing a demonstration is unclear, especially if the code will be usable in the development effort. GUI builders and scripting languages will help with the demonstration. Write only the code necessary for a successful demonstration.

Pattern: Prototyping Languages

Pages: 411-412

You're using Catalytic Scenarios. If you can't implement the end product in a language that supports rapid prototyping, then consider using a prototyping/scripting language (e.g., Tcl, Perl, XLisp) that works with your implementation language. Often such prototyping languages can be embedded in the implementation language and even become an extension language for the product.

Pattern: Lightweight User Interfaces

Pages: 412-413

Your customer demonstration must show some level of interactivity. Spend minimal effort on the user interface. If possible, use tools to facilitate easy modification of the interface without writing a lot of code. The customer should realize that the prototype interface is part of a demonstration, not part of the end product. Intentionally leave parts of the display incomplete; don't spend time making it just right.

Pattern: Judicious Fireworks

Pages: 413-414

You want the customer demonstration to excite the customer but not give unrealistic expectations. Dazzle the customer with just enough spectacular functionality to leave them wanting more. Use Lightweight User Interfaces. Pick a part of the interface to put on the best show and concentrate on it. Don't demonstrate extras that will not appear in the end product.

Pattern: Archive Scenarios

Pages: 415

You've prepared a successful customer demonstration and are returning to product development. Never believe that you've given all the demonstrations. Archive the demonstration. Code, scripts, results, and bugs should be saved. New scenarios will be developed or enhanced, but old demonstrations should be easy to repeat.