User interface (UI) prototyping is
an iterative analysis technique in which users are
actively involved in the mocking-up of the UI for a
system. UI prototypes have several purposes:
- As an analysis artifact that enables you to
explore the problem space with your stakeholders.
- As a requirements artifact to
initially envision the system.
- As a design artifact that enables you to explore
the solution space of your system.
- A vehicle for you to communicate the possible UI
design(s) of your system.
- A potential foundation from which to continue
developing the system (if you intend to throw the
prototype away and start over from scratch then you
don't need to invest the time writing quality code for
As you see in the activity diagram
depicted in Figure 1 there are four high-level steps in
the UI prototyping process. The first step is to
analyze the user interface needs of your users. User
interface modeling moves from requirements definition
into analysis at the point you decide to evolve all or
part of your
essential user interface prototype into a
traditional UI prototype. This implies you convert your
hand-drawings, flip-chart paper, and sticky notes into
something a little more substantial. You begin this
process by making platform decisions which in effect is
an architectural decision. For example, do you intend to
deploy your system so it runs in an Internet browser, as
an application with a windows-based graphical user
interface (GUI), as a cross-platform Java application,
or as a mainframe-based set of "green screens?"
Different platforms lead to different prototyping tools,
for a browser-based application, you need to use an
HTML-development tool, whereas a Java-based application
would require a Java development tool and a different
approach to the user interface design.
Figure 1. UI
While you're determining the needs of your
stakeholders you may decide to transform your essential
user interface prototypes, if you created them to begin
with, with sketches.
Figure 2 depicts an essential UI and
Figure 3 a sketch
of two potential screens or HTML pages based on that
prototype. Transform really isn't the right word here
seeing as I'm using a completely different modeling
technology now (a whiteboard instead of paper) so in
effect I'm replacing the essential UI prototype with the
Figure 2. Essential
I chose to split the prototype in
two for cohesion issues - I prefer screens that fulfill
a single purpose, in this case capturing basic student
information and enrolling a student in seminars
respectively. This is arguably a design issue (there's
a fine line between analysis and design which you'll
cross all the time). The sketches provide a final level
of detail than the paper prototypes do, it is much
easier to get a feel for how the screen will be
than it is from Figure 2, although the sketch isn't as
flexible because it's hard to shift widgets from one
part of the diagram to another whereas with the paper it
is very easy.
Figure 3. Screen
|As you iterate through UI
prototyping you will often discover information better
captured in other artifacts. That's okay, you can
follow the AM practice
Iterate to Another Artifact and capture that
information in the proper place. It also points to the
importance of the AM practice
Create Several Models in Parallel - you often
need to work on several things at once to get the job
done. Agile software development is an evolutionary
process, so this is normal.
Once you understand the UI needs of
your stakeholders the next step is to actually build a
prototype. Using a prototyping tool or high-level
language you develop the screens, pages, and reports
needed by your users. With the user interface platform
selected, you can begin converting individual aspects of
your essential UI prototype into your traditional UI
prototype. You may want to create sketches such as you
see in Figure 3 or
go straight to a concrete implementation, such as the
HTML page depicted in Figure
4. The sketches are more inclusive,
your stakeholders can be actively involved in creating
them, although the actual HTML page is much closer to
working code (your primary goal).
Figure 4. Concrete UI
prototype (HTML page).
It is critical to understand that
you don't need to create a prototype for the entire
system. It is very common to prototype a small portion
of the user interface, perhaps a single screen or HTML
page, before moving on to implementing it. Remember,
agile developers work in an evolutionary manner - the
don't need to define everything up front before moving
on. Sometimes you will need to prototype a large
portion of your system, perhaps as part of an
envisioning exercise or perhaps even to help define the
system scope so that you can obtain project funding.
After a version of the UI prototype
is built, it needs to be evaluated by your stakeholder's
to verify that it meets their needs. Sometimes this is
as easy as asking someone to spend a few minutes to look
at what you've built and other times it's as complicated
as scheduling a meeting so that you can demonstrate the
software to a group of people. I prefer the first
approach. When evaluating a UI prototype I've always
found that the following questions provide me with
- What is good about the UI prototype?
- What is bad about the UI prototype?
- What is missing from the UI prototype?
After evaluating the prototype, you
may find you need to scrap parts of it, modify parts,
and even add brand-new parts. You want to stop the UI
prototyping process when you find the evaluation process
is no longer generating any new ideas or it is
generating a small number of not-so-important ideas.
Otherwise, back to exploring your stakeholder's UI
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.