The user interface (UI) is the portion of software with which a user directly interacts. An essential user
interface prototype (Constantine and
Lockwood 1999), also known as an
abstract prototype or paper prototype, is a low-fidelity model, or prototype, of the UI for your system. It
represents the general ideas behind the UI, but not the exact details. Essential UI prototypes represent user
interface requirements in a technology independent manner, just as essential use case models do for behavioral
requirements. An essential user interface prototype is effectively the initial state-the beginning point-of the
user interface prototype for your system. It models user interface requirements, requirements that are evolved
through analysis and design to result in the final user interface for your system, enabling you to explore
usability aspects of your system.
Two basic differences exist between essential user interface prototyping and
traditional UI prototyping. First, with essential UI modeling the goal is to focus on your users and their
usage of the system, not system features. This is one of the reasons you want to perform essential use case
modeling and essential user interface prototyping in tandem: they each focus on usage. Second, your prototyping
tools are simple, including whiteboards, flip-chart paper, and sticky notes. The minute you introduce electronic
technology to your prototyping efforts you have most likely made a design decision about the implementation
technology. If you use an HTML development tool to build a user interface prototype, then you may immediately
narrow your design space to the functionality supported within browsers. If you choose a Java development
environment, then you may narrow your design space to Java, and if you choose a Windows-based prototyping tool,
you may narrow your design space to whatever is supported on the Windows platform. Right now, you should be
focused on requirements, not design; therefore, you don't currently want to use technology-based prototyping
tools. Understand the problem first, and then solve it.
So how do you use sticky notes and flip-chart paper to create an essential user interface prototype? Let's
start by defining several terms. A major user interface element represents a large-grained item, potentially a
screen, HTML page, or report. A minor user interface element represents a small-grained item, widgets such as
user input fields, menu items, lists, or static text fields such as labels. When a team is creating an essential
user interface prototype, it iterates between the following tasks:
- Explore system usage. Your team will explore system usage via several means. First, you will
likely work together on a
whiteboard to discuss ideas, work
on initial drawing together, and generally take advantage of the dynamic nature of whiteboards to come
to an understanding quickly of the portion of the system you are discussing. For example, with the
university system, you may gather around a whiteboard to make an initial drawing of what a university
transcript would contain or what a seminar enrollment submission would contain. Second, as you have
seen,
essential use case modeling is an
effective technique for understanding the behavioral requirements for your system.
- Model major user interface elements. Major user interface elements, such as potential screens and
reports, can be modeled using flip-chart paper. I say potential because whether something is a screen or
printed report is a design decision-a university transcript could be implemented as an HTML page your
users view in a browser, as a paper report that is printed and mailed to students, or as an application
screen. Each piece of flip-chart paper is given a name, such as Student Transcript or Seminar
Enrollment Request, and has the appropriate minor user interface elements added to it as needed.
Pieces of flip-chart paper have several advantages: they can be taped to a wall; they are good for
working in groups because they make it easier for everyone to see and interact; they are large enough so
you can put many smaller items such as sticky notes on them; you can draw on them; and they can be
stored away between modeling sessions.
- Model minor user interface elements. Minor UI elements, such as input fields, lists, and
containers (minor UI elements that aggregate other minor UI elements) are modeled using sticky notes.
Constantine and Lockwood (1999) suggest using different color notes for different types of components,
for example, bright colors (yellow or red) for active user interface elements such as input fields
versus subdued colors (white or tan) for passive interface elements such as containers. Figure 1
depicts an essential UI prototype to enroll students in seminars. The Student name sticky note is
a container that includes four active elements: First name, Surname, Middle, and
Title. The other sticky note represents a list of the seminars a student has taken or is
currently enrolled in. Notice how each sticky note has a name that describes its purpose, but not how it
is implemented. You can look at the sticky note and immediately know how it is used. Different sizes of
sticky notes are used, indicating the relative size of each UI element. Also notice how the relative
order of the UI elements are indicated by the order of the sticky notes: a student's title comes before
his first name, then come his initials and his surname. This ordering may change during design but for
now it is close enough. Whenever you realize you may need a minor user interface element, you simply
take a sticky note, label it appropriately, and place it in the general area on a major user interface
element where your stakeholder believe it belongs. Sometimes you identify a minor UI element that may
not have a major UI element on which to place it. Don't worry. This is an iterative process, so attempt
to identify an appropriate major UI element and continue. The very fact that sticky notes do not look
like a real GUI widget is a constant visual reminder to your team that you are building an abstract
model of the user interface and not the real thing. Each sticky note is, effectively, a placeholder that
says you need something there, but you don't yet know yet the best way to implement it, so for now, you
want to leave it open.
- Explore the usability of your user interface.
Highly usable systems are learnable, they enable user productivity, their use is easy to remember, and
they are supportable.
Figure 1. Essential UI prototype for enrolling in seminars.

Let's examine
Figure 1 in greater detail. This prototype was created using a standard piece of flip-chart paper; you
should use one piece of flip-chart paper per major user interface element. The name, in this case Enroll in
Seminar, is typically written across the top. Notice how there is two containers, which I drew on the paper
to help bound different sections of the UI. The pink sticky notes, such as Student Number and
Student Name, represent input fields, whereas the yellow ones are display only. Student Name is
interesting because it is a bit of a cheat, listing four separate data elements on the one sticky note. I will
often do this when I know some thing always come in a group and when I think I will need the room, which, as you
can see I do. The blue sticky notes, such as
Search and Help, represent actions items. Action items are often implemented as push buttons,
function keys, or "hot key"¯ combinations, such as CTRL-SHIFT-S. All of the lists support selection of the
information within them, for lists that don't support selection, you should indicate this information.
I like to ask questions about how your essential user interface prototypes would be used. For example,
what should happen if a student really wants to enroll in a seminar that is currently full? Should she be
given the opportunity to add herself to a waiting list? If so, how does that affect the user interface? You
likely need to support the capability to indicate a waiting list of X number of people already
exists, as well as a way to request being added to, or removed from, the waiting list. Should obtaining
detailed information about the professor teaching a seminar be possibleShould obtaining detailed information
about the seminars in the prerequisite list be possible? In Figure 1 you see it is
possible to search for a seminar by inputting its number or name. Should searching by the department that
offers the seminar be possible? Or, by day of the week on which it is offered (when I was a student I had a
1.5 hour commute, so I tried to enroll in seminars that all were held on the same days)? Or, by the name of
the instructor teaching it? These are all interesting questions, the answers for which could potentially
result in new requirements. However, always remember that your stakeholders are the official source of
requirements, not developers. If you identify some new functionality that you think is required you need to
convince your stakeholder that it's a good idea, have them prioritize it, and add the new requirement to the
stack. When you're following Agile Modeling's practice of
Active Stakeholder Participation this is very easy to accomplish because your stakeholder(s) would have
been part of the modeling exercise to begin with. |
 |
We have been jumping through hoops not indicating implementation decisions for the major user interface
elements. The reality is that you know that the seminar enrollment prototype is going to be implemented as
either a screen or an HTML page, so why not admit it? When a major user interface element contains one or more
minor user interface elements that permit editing, then you know it's going to be a screen or a page. When it
contains no editable elements, then it will be a report. If you are going to a lot of "unnatural"¯ effort to make
your major user interface elements independent of implementation technology, then you may want to loosen up a
bit and distinguish between reports and screens/pages. In fact, once the architectural decision of how we're
going to deploy the system has been made, I have a tendency to draw screen sketches on a white board which
enables me to get a more accurate rendering of what the screen/report may look like. However, as always my
advice is always to choose the most appropriate tools and techniques for your situation.
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
Translations