This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Some time ago, I worked with a large client, helping them to catalog their existing design patterns, and to understand how they could establish a broader design system. They had multiple design teams, each overseeing a different product, and each keenly aware they needed something to help them create more consistent interfaces.
But perhaps even more than that, they knew they needed to talk about their design patterns more consistently. As they started creating an inventory of all their existing patterns, they found one team used “atoms” to refer to each of its components, whereas another team used “atoms” and “organisms” interchangeably, regardless of how complex a given pattern might be; one team might refer to a specific kind of design pattern as a banner, while another might call a near-identical pattern featured hero; and so on.
So for a few workshop sessions, we took a page from Charlotte Jackson’s playbook. We broke up into smaller groups, took scissors to printouts of some representative pages, cut them up into patterns, and named each pattern in turn. After working through all the patterns, each team then presented its findings to the larger room. Invariably, that leads to solid debates around differing results, the approach each group took, and the language they settled on.
I should note I’ve run this exercise with a few clients, and with conference attendees. Each time I’ve found the discussions to be consistently thoughtful. (Also: snipping up a bunch of webpages is weirdly cathartic.) It gets groups talking about why a specific pattern should be called teaser and not blurb, whether or not four different treatments for a media player are needed, or why there absolutely should be different treatments for short product preview and full product preview. If you’re lucky, a common, shared language may start to emerge from this exercise.
But in addition to that, these workshop teams gradually realize the primary benefit to creating a pattern library isn’t the patterns themselves. Don’t get me wrong: identifying strong, sustainable patterns is, y’know, why we do this work. But rather, they understand the language used to name, organize, and find their patterns is what allows them to use those patterns effectively—and that is what creates more consistent designs.
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.) But from where I sit, it’s really exciting to see clients and conference attendees independently arrive at the same conclusion: that the words we use to talk about our design are, well, valuable design tools themselves.
Note: My thanks to Scott Jehl, who provided some really wonderful feedback on earlier drafts of this entry.
This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Ethan Marcotte | Sciencx (2018-05-04T04:00:00+00:00) What’s in a pattern name?. Retrieved from https://www.scien.cx/2018/05/04/whats-in-a-pattern-name/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.