Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This page will be created by the OSDPL Working Group, and will give advice on creating and editing a design pattern in the Open Source Design Pattern Library. When finished, it will be migrated to the OSDPL at http://osdpl.fluidproject.org.

Draft Status

This page is an early draft, subject to extensive revision.

How to Create a Good Design Pattern

A design pattern is a solution to a design problem within a context. While patterns can be used for designs in many domains - from building architecture to object-oriented programming - the OSDPL will initially focus on user experience patterns: "... structural and behavioral features that improve the "habitability" of ... a user interface" (Tidwell, 2006).

Guidelines

Here are some guidelines for pattern authors and editors:

  1. All design decisions implicit and explicit in the pattern should be based on principles derived from an understanding of best practices. The pattern author should quote the underlying principle where it is important for the reader to understand why a particular decision was made.
  2. The concept of design patterns comes from building architecture. Architects are taught that their creations should exhibit commodity, firmness, and delight. The user experience designer focuses mainly on delight: those aspects of the design that inspire a sense of control, correctness, understanding, effectiveness and efficiency in the user's perception of an interaction.
  3. A design pattern should be user centric in its description. Everything in the pattern should be about what the user knows, perceives (sees, hears), understands, and may intend; as well as the actions the user takes in response to system behaviour.
  4. It is important to distinguish between a design pattern and a design. Patterns should be general templates, which are agnostic about the user's intentions. Designs are situational derivations of patterns, where the intent of the user can be specified in the scope description.
  5. The pattern author should make clear which audiences are being addressed. The basic outline of the pattern should be for all readers. Examples and illustrations can be constructed to service particular areas of expertise.
  6. The primary objects in the library are design patterns. They are templates from which actual designs (and implementations) can be derived. The author makes certain design choices, based on design principles, and leaves others to the designer and the implementer.
  7. The pattern author should make minimal assumptions about the user's intentions. The specific requirements and intensions of the user are more the domain of the designer, who is likely to be working with a more finely specified problem and restricted scope.
  8. Patterns should be useful to a variety of audiences. All the viewers of a design pattern should be able to appreciate its cohesiveness and form, and how it employs good design principles. Examples and supplementary material may be directed at specific audiences. For example, images or audio clips drawn from actual designs can be used as illustrations of good practice for designers. Code and markup fragments from existing exemplary implementations may be included for developers. How a pattern manages user workflow, user choices, and user understanding will be of interest to a business analyst.
  9. A pattern can be augmented with material addressing a variety of disciplines. The original author may only write for a subset of the potential audiences. Another author may add supplementary material addressing the professional needs of others. Each author and editor must be clear about the audiences they are writing for.
  10. A pattern description must always be written with attention to consistent and unambiguous terminology. In the OSDPL, a term used in one pattern should have the same meaning when it is used in others. Authors should draw upon and contribute to the OSDPL glossary to help maintain consistency.
  11. A well designed pattern describes a piece of functionality that can be referred to by name without explanation. This provides a chunking of concepts that enriches vocabulary and eases discussions between developers and designers. E.g. "At this point a progress indicator will appear." A pattern should aspire to become a meme.
  12. A pattern may reflect the state of current technology. For example a pattern may need to incorporate the notion of the user waiting for a response. If system response time becomes negligible due to technological advances, the pattern must be adapted to the altered dynamics of the use context.

An Example

Example: A pattern for a progress indicator

We're not going to actually write a pattern for a progress indicator, we're just going to describe some of the things that need to be considered in creating a good one.

Problem: Indicate progress of some process that takes time.

Context: A process has begun. It will take sufficient time that the user would like to know that progress is being made, at what rate, and when it will complete.

Relevant factors:

  1. What are the appropriate metaphors for progress: something moving, counting, going through a sequence (alphabetic or numeric), filling up, emptying out, growing or contracting, rising in intensity or volume, climbing the scale, etc?
  2. How does each metaphor signal the user of progress being made?
  3. What is the appropriate granularity (polling rate, change rate, refresh rate etc)?
  4. Should the refresh rate change through time?
  5. Can/should we indicate increasing precision as the process progresses?
  6. Should there be indication of work accomplished and work remaining?
  7. Should multiple metaphors be employed for one process? What metaphors work well together?
  8. Is it valuable to use depictions of the objects being acted upon by the process (e.g. files uploaded, files scanned, pages printed, spam delivered)?
  9. How can the designer create an association in the user's mind between the appearance of the indicator to the actual process?
  10. How can the indicator inspire confidence that the process is in fact progressing and will terminate? This is especially important if accurate estimates cannot be made.
  11. How can the indicator inspire confidence that the estimate of remaining time is accurate?
  12. How much information is needed? Is a simple accurate prediction of completion time sufficient?

A good design pattern will explain how each of these factors should be addressed, given the actual design objectives the designer is trying to fulfill. It may include:

  • Examples of design solutions based on the pattern. E.g. a well-constructed progress bar - of interest to the designer.
  • Code fragments or markup examples showing how parts of the design solutions can be implemented - of interest to the implementer.
  • No labels