An Event Apart: Patterns, Components, and Code

by July 28, 2010

In her Patterns, Components, and Code, Oh My! presentation at An Event Apart in Minneapolis MN, Erin Malone provided an overview of design patterns, their origins, and how Web teams can use them successfully in their product design and development processes. Here's my notes from her presentation:

  • Christopher Alexander identified patterns in architecture and put them together in the context of how people use physical spaces to interact. He created a design vocabulary or “pattern language” for creating structures for people to use.
  • The “gang of four” Design Patterns book applied this thinking to software development for object-oriented programming.
  • Building on this work, Jenifer Tidwell, Martin Van Welie, Yahoo!, and other designers have published pattern libraries for designers.
  • Pace layers: different parts of architecture change at different rates. The structure will change at a faster rate than the geology but much slower than the services, space, and stuff layers of a building. Software design fits into a similar model. Slower changing parts are infrastructure/platforms, content, front-end code. Faster changing parts are interaction specs, patterns, and visual design. If you put your services in your structure you may need to tear your building down to change how it can work.
  • Patterns are optimal solutions to a problem in context. They are not for edge cases. The context is important as it determines if a pattern fits your specific needs.
  • Patterns consist of what (what does the user want to do?), examples (archetypical examples of the solution in action), use when (when to use it), how (to meet the user’s needs), rationale (why is this a good solution). The how needs to be well documented. What are the issues, opportunities, and considerations? This is where the bulk of the discussion about a pattern resides. It helps designers understand how to effectively implement a design pattern.
  • Sources of data for patterns include research data, product specifications, and audits of existing solutions in the wild. If you see common approaches to solving similar problems –there’s likely a design pattern there.
  • Make sure you capture a screen shot to document your pattern– a picture is worth a thousand words.
  • Determine where a solution is appropriate. How is it different or similar to other patterns? Document open questions and special cases. Provide links to supporting research.
  • Patterns are not the last word on design solutions but they help provide baseline information to allow you to focus on the unique aspects of your applications.
  • Patterns are not specs. Specs are the ONE way to implement something. Patterns are ways you CAN solve problems. Specs often include brand guidelines or technology requirements. Interaction patterns do not dictate look, placement, or layout. Specs are rule-based while patterns require you to think.
  • Patterns provide you with design rationale that helps build consensus across multiple stakeholders. Developers, new team members, etc. can use well-documented patterns without a lot of direct interaction with designers.
  • The pattern is the core. Research backs it up. But you need stencils or components that serve as an instance of a design pattern. Stencils provide a visualization of the pattern in an instance: a component. They can specific to a tool (Axure, InDesign, Visio) or a library (Y! Pattern library), or a company.
  • Components are reusable, specific elements of a design system. You can put them together like building blocks to create application designs. Components work best when there are code libraries to back them up.
  • There are a lot of pattern solutions out there –see how you can map what already exists to what you want to do. If you can map a code snippet to a component, it makes development quick and easy.
  • The complete pattern toolkit: patterns, research, stencils/components, code, specs/visualizations. This allows you to build prototypes, quick development.