Java Reference
In-Depth Information
11.7.3
Prototyping can be an effective way to carry on the discussion of both require-
ments and user interface design. Given only a hypothetical or abstract descrip-
tion of some software, it can be very difficult for people to imagine what the
implications of its use will be. A simple prototype can immediately bring the
discussion down to the concrete; people can point at things and say “I like this”
and “I don't like that” and “How would I do so-and-so” and then see whether
or not it would work. Sometimes, ideas that sound great on paper turn out to
be pretty poor ideas when realized. Prototypes can help you discover that
quickly and easily.
One very useful but inexpensive prototyping mechanism can be
HTML—that is, creating Web pages. Simple static HTML can be fast and
cheap to build, but can begin to approximate what the user interaction will
look like—especially for, but not only for, Web-based solutions. It may not be
an exact replica of the final product, but for a first step it can really get the
discussion moving.
If the UI is too complex for a Web page mock-up, you can still use HTML
for prototyping by getting images (screenshots) of what you want your final
solution to look like and then making these images clickable on Web pages, to
simulate some simple user interaction with hyperlinked image sequences.
The idea is to get something “tangible” in front of people as soon as possi-
ble, to further the discussion in a way that written descriptions never can.
(“A picture is worth a thousand words.”)
Once you've built a prototype, shop it around. Hold informal meetings
where you demonstrate the basic functions to stakeholders. We recommend,
as much as possible, meeting with one group of stakeholders at a time. That
way you can keep your conversations focused. If you have two different stake-
holder groups represented and their expertise and interests are wildly different,
you'll be boring ½ the participants all the time. Even if their expertise is similar,
you may have groups with competing or conflicting requirements. While you
need to understand such conflicting requirements and eventually come to some
detente, this meeting is not the best venue for settling those issues; it would
more likely simply scuttle your meeting and void any value from it.
Prototyping
that Dale Carnegie is as important to the software designer as Yourden or Booch. Your users
need to be your friends if you want to succeed.
