Effective software design isn’t just about designing a thing and then turning that design loose unto the world; it’s also about communicating that design to the people that matter and ensuring that they understand what your design is about, why it is the right approach and what problems it avoids or solves.
When we create a software prototype, we have to make many design decisions of varying importance. The prototype itself might be demonstrated to various audiences and so a little guidance is worthwhile.
One tactic which is worth covering is to understand your audience and how they will perceive your prototype. A technical audience will doubtless look at your prototype in an entirely different way to a business audience, which in turn will probably look for different things than would an audience of end-users. The key is to tailor your approach to demonstrating your prototype so that:
1) It uses language and terminology that the audience understands;
2) It respects the motivation of that audience – in other words, what they want to get out of the demonstration, and
3) It prompts for any specific feedback that you, as the prototype designer, wish to solicit from that audience so as to feed back into the design.
The very best approach is a personal demonstration, particularly a one-to-one hands-on tour. Letting a user have a play with a rich prototype is an incredibly engaging and fruitful technique, which also gives you the opportunity to watch how that user explores the design. You might be very surprised by the varying way that different users interact with your design. If you spot any confusion or hesitation in their use of your design, it could be a strong indicator of a problem which you can then fix.
However, it’s not always possible or even desirable to do a personal demonstration. Sometimes it’s not even feasible to let users actually use your prototype at all – either for technical or business sensitivity reasons.
In these cases, one powerful method that has emerged in recent years is the use of screen-casting technology, so that a prototype can be demonstrated and a recording of the screen made (along with an audio voice track). These can then be replayed by any interested party.
The most important thing after all this is said and done is to ensure that you are in regular contact with your end users, stakeholders and anyone who needs to be involved. Prototyping is all about getting feedback and refining designs based on that feedback, so however you want to do it, getting your audience looking at your designs is one of the cornerstones of effective requirements prototyping.
(I’d like to recommend a very useful tool called iShowU HD Pro, which is a very low cost solution for screen-casting. I’ll review this at the end of March, but would strongly recommend anyone who would like to try screen-casting to give it a try.)