(See my earlier posts for introduction to the series.)
A demo or a simulation is the best tool for telling about the ongoing designs for people outside the project. You can try to explain the design intent and use cases with bullet points on paper, but when people see and feel the designs, they will finally understand. In my work when presenting designs, I usually have simply skipped all slideware and presented the design only through an interactive demo. While using the demo it is quite easy to verbally point out different elements in the design, and at the same time tell the background story; the design rationale. It’s also a good test if you really know your story.
You can’t get a feeling of an interactive UI on paper. The first audience for a demo is the designer herself, or you as a design lead. By trying the designs out you can be confident that they really do work (for the user). With experience you can predict quite accurately if a design will perform well in user testing. Naturally, surprises still do happen.
One important aspect of building demos is process related. Without a demo, you perhaps can keep on working with different parts of the designs separately. Designing like that for long you run a risk that at the end, the bits and pieces will not fit together. Here where building demos help. The prototype engineer (or whoever does this for you) needs to get all the designs, well documented, with all the graphic files, and then make them all work together in the demo. Usually you will find that there are quite a few gaps, missing designs etc. A demo will force you to put together a complete system, not just parts of it.
A demo is a shared effort of the whole design team. Everyone’s contribution is needed. Demos help you feel that you are building one system together. If you can include good looking, although not necessarily final, graphics into the demos, you can also give the team a good morale boost. They start to see their efforts materialize and set further expectations for the final delivery.
PS. Fascinating discussion initiated by Jon Kolko here. I wonder if I should change the name of the series to “Interaction design leadership”…
…How abut just “Strategic Design Leadership”? :)