Adding design process attributes to patterns

(this is a follow-up to my previous post called Processes + Patterns = ?)

update (September 28, 2006): I made some small changes after I re-read this post today. I hope they help increase the legibility.

Let's see what happens if we add processes to patterns.

• Patterns are tradionally centered around context of use: When is it a good idea to apply this pattern, and when not?
• Processes are all about context of design: in what situations should we include what types of designers in the team, delivering what and how?

The idea of adding design process attributes to patterns expands the focus of patterns to include the context of design.

This could allow us for example to determine that certain aspects of Agile processes work better for informational sites than for e-commerce sites. Or that a community website on average takes three times as many usability evaluations to complete successfully. Or that a site's usability with breadcrumb navigation is rated higher if a card sort excercise was used in the design process.

Attributes that could be captured with the patterns (and evaluated by users) are:

• Design Roles
• Design Methods
• Design Deliverables

Here are some examples of each, using some of the titles from Martijn's patterns (with Initial Capitals) for reference:

Design Roles

• Some of the more commercially oriented site types really need a marketing or branding expert.
• Search-heavy sites need an indexer or search expert.
• A Web-Based Application like a Product Configurator should not be designed without an interaction designer, just like a site using Faceted Navigation needs an information architect.
• The designer of a Printer-Friendly Page could use the help of someone fluent in CSS.
• The Artist site needs to reflect the artist's personality so either the artist him/herself or a good personal ethnographer should be involved in the process. (Check out the work Stamen did for Vito Acconci).
• A designer who considers using the Premium Content Lock pattern may need the help of a business analyst and a marketing intelligence expert to calculate the ROI.

Design Methods

• Performing a card sort excercise seems like a good idea for Corporate Sites, Portals, and Information Seeking experiences, as well as for several types of navigation and menus.
• Web-based Applications, Community websites and Blogs probably benefit most from iterative approaches by including feedback from participants in usability tests or real-world web traffic analyses.
• A one-off Branded Promo site, Campaign, or Fun site may not have to be usable as long has it has an impact, so you want to measure emotional responses.
• Design proposals for Campaign pages and Banners could be evaluated using A/B- or multivariate-testing.

Design Deliverables

• For larger Web-based Applications and most Wizards, you cannot live without a set of documented screenflows, showing happy paths and alternatives a user can take through the application when completing a task. (Informational Corporate Sites and smaller Campaign sites can usually do without.)
• E-commerce sites in general are bound to improve if the maintainers take a look at the web analytics reports.
• Moodboards are usually the start of any Branded Promo site and Campaign site, whereas most Forms, Guest Books and Search Results don't require one.

As shown above, this idea is more applicable to higher level patterns (Martijn's Site Types, Experiences, and larger functional elements like shopping carts) and less suitable to lower level patterns (like list management or the action button).

Collecting evidence
How would adding design process knowledge to pattern collections work in practice? As with patterns, it would require volunteers to suggest proven processes for inclusion with the patterns.
A selection of agreed-upon names for the attributes of processes (roles, methods and deliverables) might be a good start, to allow for suggestions to be made by simply selecting them from a dropdown list.
Of course such a collection of links between patterns and process attributes by itself is not knowledge; it's how the roles, methods and deliverables were applied in the design that is interesting.

In time, as with patterns, this knowledge will emerge slowly from a collection of contributed stories. Maybe collections like AIGA's design archive or CHI's Design Expo can serve as a starting point. Or could the Design Management Institute be good a source?

To be continued...
I'll let you know what I find when I dig into this idea deeper. In the meantime, suggestions for approaches, sources, ectetera, are more than welcome!