Ariaware Usability Design Pattern Catalog for RIAs

Based on our extensive experience in developing usable Rich Internet Applications (RIAs) -- as well as standard desktop and mobile applications -- we have begun to formulate a list of Design Patterns for Usability Design. Design Patterns, first introduced in the field of architecture, outline common solutions to common problems. These Usability Design Patterns should be taken as a useful starting point. They are not a replacement for Usability Testing.

Some of the patterns give examples of usage that relate to our work on the Telrock Messaging RIA. This is an RIA that allows users to send and read SMS messages.

Talk One Language

There should only ever be a single term or phrase used to refer to any given item in the application. An item here may refer to a concept, a business function or task or even a widget or individual interface element. You will find that the use of a metaphor for the project, as advocated by eXtreme Programming (XP), will ease this task tremendously.

Respect User Effort

Try to limit the user's physical toil while using the application. Example: For an SMS Messaging RIA, scrolling while viewing messages must be kept to a minimum or obliterated altogether.

Let The User Work

Users must be able to perform their most frequent, most important tasks without any resistance. Example: For an SMS Messaging RIA, this would include reading, replying to and forwarding messages and quickly checking the various mailboxes.

Prevent, Don't Scold

Whenever possible the UI should prevent the user from making a mistake instead of alerting the user to the mistake after the fact. This must be achieved without the UI getting in the way of the user.

Give Sufficient Feedback

The UI should give the user sufficient feedback for users actions. (This ties in nicely with Steve Krugs "Don't Make Me Think" philosophy: The user should never have to think "did that work?") Related to Don't Lose The User, see below.

Show, Don't Tell

Although this may seem to contradict with the Give Sufficient Feedback pattern, it is rather meant to compliment it. Whenever possible, meaningful visual cues (when appropriate to the audience) should be chosen instead of lengthy textual descriptions. This can also pertain to actually teaching a user to do something in an application by showing them.

Don't Lose The User

The UI should protect the user's sense of spatial positioning. The user should never feel "lost" within the application.

Don't Sell What You Can't Deliver

Users must not be given Graphical User Interface (GUI) expectations that cannot be met (or can only be partially met) within a Web User Interface (WUI). Whenever OS or GUI expectations are set, they must be fully met. That said, the application must try and meet OS expectations as much as possible, especially for ergonomic features such as keyboard shortcuts and navigation but also for expected auxiliary helpers such as tooltips.

Don't Keep Them Waiting

The application must perform fast enough to be considered usable within the given engineering limits for the application.

A Practical Application

You can see how we applied these Design Patterns to the Telrock Messenger project to reach high-level design decisions in our Telrock Messenger Case Study.