Minutes of the 1-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 semicustom web-based applications, and is the sponsor of 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@ucar.edu 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@indra.com.

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

=======================

RMIUG (http://www.rmiug.org/) appreciates the sponsorship of
MicroStaff (www.microstaff.com), ONEWARE (http://www.ONEWARE.com), and Copy Diva (http://www.copydiva.com).