| In this section:
|
Building a
prototype is a cheap and easy way to confirm what you think you know about the potential
users, their equipment and what the product should do. Users are much more able to
articulate what they actually want when faced with a software prototype.
You need to answer some or all of the following questions:
These questions are important because without answers you run the risk of designing an interface that does not suit the target market. The secret of a good screen design is the consistent application of design rules that conform to the answer the three questions above. |
Prototyping
is quick and cheap |
|
A paper
document that describes the new or enhanced product is nowhere near as good. Large
technical documents like Requirements specs or Functional specs are rarely comprehended
properly by users, with the result that what gets built is not what they actually require.
There are
different types of prototypes:
They are not incompatible with one another, but they have different purposes. |
Types of prototype | ||
A user
interface prototype is built to:
It does not generally include a mock-up of a complete business process. Nor does it test that the database can support a specific level of transactions pre minute, or that secure messaging will actually work over the wide area network etc. |
User Interface prototype | ||
| A user interface prototype can generally be built in a matter of 2 to 4 weeks and might simulate 8 or 10 screens. It can be built with a programming tool like VB or Delphi, or you could use a multimedia tool like Director. | Build in 2 to 4 weeks | ||
| A more complex prototype that also demonstrates the feasibility of some technical design issues or includes a full business process might take 6 weeks to build. | |||
| It should be put together using the actual programming tools you intend to use for the real product. | |||