 |
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
your prototype).
|
|
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
prototyping process.
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
sketches.
Figure 2. Essential
user interface.
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
implemented from
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
sketches.
| 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
significant feedback:
- 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
needs.
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
|
|
|
Maturing Usability: Quality in Software, Interaction,
and Value contains a collection of
writings from various experts in the field of usability
and user interface development. It provides an
understanding of how current research and practice has
contributed towards improving quality issues in
software, interaction and value. I wrote chapter 4 which
describes how usability fits into the Agile SDLC.
Other chapters look at how using development tools can
enhance the usability of a system, and how methods and
models can be integrated into the process to help
develop effective user interfaces; theoretical
frameworks on the nature of interactions; techniques and
metrics for evaluation interaction quality; the transfer
of concepts and methods from research to practice;
assessments of the impact that a system has in the real
world; and how to focus on increasing the value of
usability practice for software development and on
increasing value for users. A balance between
theoretical and empirical approaches is maintained
throughout, and all those interested in exploring
usability issues in human-computer interaction will find
this a very useful book. |
Translations
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
