Minutes of the 01-11-05 meeting of the Rocky Mountain
Internet Users Group (RMIUG): "Designing Usability
into Products: the Engineering, Art, and Psychology of
Prototyping"

A PowerPoint presentation for this meeting is
available at
http://www.rmiug.org/html/meetings/2005/usability.pdf.

Josh Zapin represented the RMIUG executive committee
at the meeting. About 60 people attended. Jeremy
Kohler recorded the minutes and Josh moderated,
thanking the RMIUG sponsors for their support:

MicroStaff (http://www.microstaff.com) generously
provides food and beverages at the meetings. The
company provides Creative and Technical Talent for
Web, Interactive Media, Marketing Communications, and
Software Development projects.

ONEWARE (http://www.ONEWARE.com) is a Colorado-based
software company that provides semi custom web-based
applications, and sponsors the RMIUG meeting minutes.

NCAR provides free use of their wonderful facility.

Copy Diva (http://www.copydiva.com) provides the AV
equipment.

INTRODUCTION

SPEAKER

BILL PAWLAK is the President of Inovdesigns, a User
Interface (UI) Design and Analysis company focused on
making the world of technology easier for people to
use. Bill has over 10 years of multidisciplinary
experience designing, testing, and developing user
interfaces for software, web-based, and mobile
applications. He has applied his expertise to
everything from very large, complex systems such as
air traffic control to desktop software systems to
rich internet applications. Prior to founding
Inovdesigns, Bill led customer experience efforts with
Seurat for clients such as RE/MAX International,
Empire Blue Cross/Blue Shield, Microsoft, P&G, and
Agilent. Bill's educational background is in
Human-Computer Interaction and Industrial/Cognitive
Engineering.

----------------------------------------------------------------------------
MEETING MINUTES

ANNOUNCEMENTS

The Boulder Valley School District offers a suite of
beginner, intermediate, and advanced courses on HTML.
Prices range from $145 to $185 for several classes.
Contact Amy Hughes for information.

NCAR has an opening for an entry-level system
administrator. You can email webmaster@... for
job info, and find the posting at
http://www.fin.ucar.edu/hr/careers/uco_jobList_ext.cfm.

-----------------------------------------------------------------------------
INTRODUCTION
This meeting was a special collaboration between RMIUG
and the Rocky Mountain chapter of the Special Interest
Group in Computer-Human Interaction (SIGCHI). Visit
http://www.acm.org/sigchi for more information.

SIGCHI is for usability engineers, info architects,
and anyone interested in making products and services
easy to use. The international SIGCHI has a free,
moderated (spam-free) mailing list with thousands of
members, which can be a great information resource.
You can sign up at http://www.sigchi.org/listserv, and
find the local website at
http://www.markmeyer.net/RMChi. The contact address is
rm-chi@....

LAURIE LAMAR is chair of Rocky Mountain SIGCHI, and
surveyed the audience as a warm-up before Bill's
presentation:
Q: Where are you from? ~20 people from Boulder and
points north. ~17 people from Denver and points
south. 3 people from west of Denver.

Q: Primary job function?
* Coding, software engineering, systems arch: ~15
people
* UI design, interaction design, usability: ~20
people
* Project management: ~12 people
* All of the above? ~10 people

Q: Who has written/read a requirements doc? ~20 people

Q: Designed a user interface? ~22 people

Q: Attended a formal usability test? ~10 people

Q: Involved in a project that used a form of
prototyping? ~15 people

Q: What's the biggest barrier in your
organization/project to usable design?
* Perception that it's too expensive, takes too long
* Too hard to recruit test subjects
* Legacy products, inertia to change
* Usability efforts have no attachment to quantitative
ROI
* Design by executives
* Lack of knowledge
* Usability does not necessarily sell products

Q: How did you learn about UI design?
A: Read books and articles-about 15 people. Learned
from mentors-about 12 people. Attended
seminars/workshops-about 10 people. Got a degree-about
6 people. Just learned by doing--- about 5 people.

Q: If you're designing usability, the goal is to make
products that are used well, and maybe even fun for
the user. How would you define Formal Usability
Testing?

A: Watch someone working, surveys, focus groups,
gather metrics (how long does take to learn a task),
use an experienced QA person, make sure it happens
well before application launch so you actually have
time to change the interface, have people talk aloud
as they are using (ask them questions), an iterative
process (repeated during development phases).

When budgets and timelines get tight, Formal Usability
Testing often gets sidelined.

------------------------------------------------------------------------------
BILL PAWLAK
This PowerPoint presentation is available at:
http://www.rmiug.org/html/meetings/2005/usability.pdf

How do we design usability upstream, before we test
for it? The answer is prototyping.

PROTOTYPING

Barriers to prototyping: time, expense, inertia, can't
quantify the ROI (return on investment), products get
designed by business people who have no knowledge of
usability, and the fact is many top (successful)
products are poor in terms of usability.

People don't like to read requirements documents, yet
those requirements have to be translated into usable
designs. Often the developers do it, but the problem
is they focus mostly on technical issues, not
usability.

Usability testing tends to get cut due to budgets and
timelines.

But informal prototyping can actually save a lot of
time and money.

Prototyping is nothing new: it's commonly used in
building models, movie storyboards, outlines for
books, draft processes and procedures. Consumer
products are often prototyped.

We can gain similar benefits in software if we use
prototyping.

A prototype is designed for demo purposes and allows
testing of a design before the product is put into
production.

The type of prototype is defined by its level of
fidelity (detail), level of interaction
(functionality), and "Direction."

LEVELS OF FIDELITY

Low:
Just a drawing of the interface on paper, or sketches
on a whiteboard. It's easy and fast, but not good at
showing interactivity.

Medium:
An HTML version, for example, showing some
interaction. Things are clickable, things happen.

High:
Something that uses real data, generating results. You
can test how well it works with real stuff.

Simple products can get away with lower fidelity
prototypes, which is good because they are cheap. The
more complex mission-critical or life-critical systems
require more fidelity.

LEVELS OF EXECUTABILITY/INTERACTION

Guided:
It looks like a complete system, but if you try to use
it you can only go down only one possible path; the
system guides you to one endpoint.

Scripted:
You are told what to do as you go through the
functions in the prototype.

Functional:
It's all basically there, but not as robust as it
needs to be in a final product. For example, the final
product might require a fancy database, but the
prototype will use a simpler substitute.

"DIRECTION"

Horizontal:
Just top-level features, showing broad functionality.
But doesn't go into much detail or depth for any given
feature.

Vertical:
Models only one or a few features, but in much more
detail (like Guided Interaction).

Diagonal:
A mix the two: a lot of high-level stuff, plus you can
dive down into some details. It shows a subset of
important features. A diagonal prototype is designed
for later stages of prototyping.

Q: What happens when a business person sees your
prototype and doesn't really look at it and says yeah
that's great, just go do it?
A: One technique is to make it ugly, so it doesn't
look like it's just ready to go.

Q: The higher the fidelity of your prototype, the less
likely you'll get good feedback.
A: That's why it's good to start with lower-level
stuff.

WHEN DO WE PROTOTYPE?

You can squeeze it in just about anywhere in the
development process, using the appropriate level of
fidelity and keeping the whole team involved.

Very early in the process, a prototype can provide
proof of concept--is it a good idea? Later, you can
guide development with further prototyping, using it
to do any of the following:
Prove the concept, gather requirements, validate
specs, guide development, and solve design problems.

How does prototyping fit with "agile" development? You
can prototype in micro-level pieces (like agile), but
first providing an overall snapshot will most benefit
an agile environment, helping ensure all the little
groups have the same idea of what the goal is. It can
prevent problems where once you put all the pieces
together they are not consistent with each other in
terms of style, look and feel, etc.

Prototyping is especially important for accessible
products, marketed to people with disabilities.

Most prototypes are throwaways, but some are
evolutionary. Generally all prototypes get
trashed--they absolutely should NOT become production
systems.

BENEFITS OF PROTOTYPING

-Reduces communication issues. Better see how it's
supposed to be. Don't have to read through specs and
requirements to see what you mean when you say the
system has to do xyz.

-Saves money. Testing of a prototype can reveal
potential hazards that might be costly after product
is released (for example, avoiding lawsuits).

-Facilitates iterative, participatory design and
development.

-Facilitates requirements gathering and analysis.

-Translates technical specs and guides later
development

-Catches and fixes design issues earlier in process,
when they are cheaper to fix.

-Catches and fixes BUSINESS issues early on: customer
contingencies such as behavioral changes due to
external factors. For example, what happens when
customer interest in your beach resort rental system
soars on a particular holiday and you actually run out
of rentals? Sales reps can go through prototypes and
catch that kind of stuff.

-Can provide proof of concept to attract funding.

-Can demonstrate progress at an early stage, even
before you've flushed everything out.

-Provides a rich test bed for Usability testing.

PROTOTYPING RISKS

-People might try to use a high-fidelity prototype in
the real world before it's ready (like a prototype air
traffic control system).

-Low fidelity prototypes can be misleading and
disappoint people who don't understand prototyping.

-If you don't have a completion criterion, prototyping
can go on forever.

-Your prototype might become a production product.
Prototype code should never never NEVER become
production code. For example, say you build a
prototype to demonstrate functionality, and then you
take the code and try to build in cross-platform
compatibility--which was not a consideration for the
prototype: a prototype isn't meant for that.

Q: So how do you make sure clients don't try to use
your prototype?
A: Make sure to show them how it isn't a real system,
what doesn't work. Tell them what the code is NOT
optimized for, tell them what still has to change.
Having clients more involved with design and
development can help.

Important: if you're spending too much time building
production code into your prototype, then you're
missing the point of prototyping. It has to be easily
changeable, not laden with working code, and
inexpensive. There are some tools that can facilitate
making usable prototypes without having to write out
lots of code.

PROBLEMS WITH USABILITY TESTING

-Happens too late in process, things get
rubber-stamped.

-Often seen as an a la carte option that can be easily
cut.

INFORMAL EVALUATIONS FOR PROTOTYPES

These include Heuristic Evaluations, Walkthroughs, and
Inspections

Heuristics:
Some are derived from research studies. Create the
rules and go through the system and see where rules
get violated.

Walkthroughs:
Build out an abstracted idea of what the user is
trying to do, like use case scenarios. Evaluate steps
needed to accomplish goals: is there enough
information in the system to guide the user toward the
goal?

Cognitive Walkthroughs:
This is a tool for developing the interface, not
validating it. Phrase goals in non-obvious ways: not
"click the order button" but "buy a book". Best in
early stages of development.

Pluralistic Walkthroughs:
Conducted by a group of people, where the role of the
usability engineer is more facilitation than
evaluation. The team environment can be very
educational for many participants, helps you find
resolutions quickly.

Features and Functions Inspection:
Systematically go through the system. Evaluate each
feature for availability in the interface, number of
steps required in flow, data elements, and
applicability to completing a goal. Consider prior
knowledge in the user: how are people used to doing
stuff, like what keyboard shortcuts are typical for
doing similar things in other applications?

Standards Inspection:
Does your product match standards in the industry?
Where do people expect to find stuff (like the home
link on a website is usually in the upper left). You
can break a standard if the business/product needs to,
just know that you are breaking it and try to account
for that in other areas of the design.

Consistency Inspection:
Look for consistency within the product and across
multiple products that your company produces--good for
product branding, maintaining customer loyalty.

No Need for Formal Usability Testing?
Informal methods can miss the
emotions/frustrations/thoughts/memories/true prior
knowledge that can only be brought in by real users.

PROTOTYPING TIPS

Walk before you run: Start on paper, keep fidelity
low, small can help you. Go horizontal before
vertical.

Get Technical: Determine what you want in light of
what is possible to build. In order for the process to
be considered successful across all team members, you
need to understand the constraints of money,
technology, and your market.

Use Includes. Include statements can make prototyping
easier.

Get Thorough: Initial stages can be high level and
lack detail, but ultimately you need to get deep.

Not-ready-for-primetime prototypes: Don't make code
for production.
A rule of thumb: Design people shouldn't code products
and developers shouldn't design them.

Keep things grey: Don't put pretty things on your
prototype that might distract a reviewer's focus. Use
color selectively, only when you really want to
highlight something, or when color is part of the
function.

Be careful about using content that might be mistaken
for something real. Putting gibberish in text areas
can often help keep the user focused on functionality

Establish an end point for the prototype.

Eat your Own Dog Food: Be involved (everyone -
developers, clients, Project Managers) in the
prototyping process - review what's being designed.

PROTOTYPING FAILS WHEN:

-The project is too small.
-There is no finish line.
-The prototype is mistaken for the actual product.
-The prototype becomes the production-ready system.
-Customers/clients/users don't provide enough
feedback.

Q: Any advice for prototyping portals? Any good
tools/techniques?
A: A common challenge is coming to agreement on what a
portlet is. For portlets, you can have dueling
prototypes: potentially six versions of same portlet
and let users decide what works best for their needs.

--------------------------------------------------------------------------
RESOURCES
Inovdesigns http://www.inovdesigns.com

Usability Professionals' Association
http://www.upassoc.org/usability_resources

Boxes and Arrows peer-written journal
http://www.boxesandarrows.com

User Interface Engineering articles
http://www.uie.com/articles

UIWEB columns by Scott Berkun (formerly of Microsoft)
http://www.uiweb.com

IBM's Ease of Use resource site
http://www-306.ibm.com/ibm/easy



=====
JZ

Joshua D. Zapin

E: mail@...
W: http://www.jzapin.com
(303) 506-8262