As we are moving from pages to patterns when creating and documenting websites and other digital design systems, pattern libraries are becoming increasingly popular. Ethan Marcotte, who famously coined the term responsive web design, recently published a nice little piece about pattern libraries on his website, in which he writes:
This observation is as true as it is often neglected. If you ever have created or worked with style guides and pattern libraries, the following process might sound familiar: Quite a few elements of a design, like buttons or typographic elements are defined beforehand, without much or even no context at all. Other elements though are indeed created to solve very specific problems in very specific contexts. But as soon as they become part of a pattern library, all those patterns suddenly are treated as immutable rules, absolute truths carved in stone. Ultimately, they are used to solve totally different problems, problems for which they might not be the best solution because the context is different now.
For design patterns, context really is crucial. Context is crucial if you want to establish a visual hierarchy. Context is crucial, if you want to balance out the elements of your design system against each other. Context is crucial with regards to responsive design: What happens to a component at different screen sizes? Context is crucial in terms of progressive enhancement: What happens to a component if the network fails or an advanced feature is available on a specific device?
This is also why Ethan suggests that our pattern libraries could be more than just interface snippets and that we should instead “discuss and document patterns in the context of how and why they were made.” This includes that we should go further than just describing how something looks and how it can be implemented, but also “describe the compromises we make — the forces we resolve — when we design (and use) our patterns.” What a worthwhile goal.
While I pondered over how one could be more mindful of context when creating pattern libraries, I remembered John Maeda’s three C’s of design. They are:
Content: There needs to be a message or meaning. Everything needs a reason to exist, otherwise it shouldn’t.
Context: Content doesn’t live in a vacuum. A Chanel bag sitting on a shelf at Wal-Mart will only confuse.
Contrast: An element is made stronger when a counterelement is offered. Salt tastes saltier after one has had some sugar.
Those three core principles of design – content, context, and contrast – provide a foundation for practical and purposeful design solutions. And because patterns are not simply rules but “represent our shared understanding of design solutions”, why not take the idea of considering context even further and use those three C’s to better describe our patterns?
For a specific component, we could for example check how it is defined and shaped by the three C’s:
Content: Why does this component exist? How does possible content look like? Is the content allowed to change and, if yes, how? If the content changes, how does this affect the component?
Context: How does the component look in different contexts? Does it maybe change and adapt depending on where it is used (pages, header, footer, etc.)? Does it have improved accessibility features? Is it influenced by other components? Does the component depend on or react to certain device capabilities? Does it work offline or only under certain conditions?
Contrast: What makes the component distinct, what makes it stand out against other elements of the system? Are there interdependencies with other components that change the perception of the element so that the appearance needs to be adjusted to (still) achieve the desired outcome?
These are all just some first quick thoughts, but I really like the idea of thinking about patterns on this qualitative level. Also because the success of a pattern library – or a style guide – depends on two main characteristics: For one, it should be accurate, deliberate, and comprehensive enough to provide guidance and a solid framework to work with. At the same time, it needs to be flexible enough to allow for innovative, diverse applications and thus practical solutions to a multitude of problems – which also includes that it is allowed to grow and change over time.
Both accuracy and flexibility can only be achieved if we are able to judge if an element is the right solution to a specific problem, and for this, we need a clear understanding of its purpose and its qualities. If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment. And this will certainly make our pattern libraries better. Because a pattern never exists in isolation.
Header image shows Nakagin Capsule Tower, Tokyo, the world's first example of capsule architecture, photo by Dick Thomas Johnson licensed under CC BY 2.0, slightly edited and color corrected.