Why your design system should include content | Clearleft

Patterns in language and language in patterns. – Ellen de Vries – Medium

A transcript of the superb talk that Ellen delivered at Patterns Day. So good!

Patterns Beyond Context · Matthias Ott – User Experience Designer

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.

Take a closer look at the patterns in our language. | Clearleft

Ellen goes through the principles behind the tone of voice on the new Clearleft site:

1. Our clients are the heroes and heroines, we facilitate their journey.
2. Speak as an individual doing whatever it is you love. Expose lovable details.
3. Use the imperative, kill the “-ing”.
4. Be evocative and paint the picture. Show don’t tell.
5. Be a practical friend.
6. Be inquisitive. Ask smart questions that need solving.

“Content & Display Patterns,” an article by Dan Mall

A really terrific article from Dan on building pattern libraries. In summary:

1. Naming things is hard,
2. Separation of content and presentation is A Good Thing.

There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:

When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.

(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)

What would HTML do? - The Cascade

Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”

HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.

Design systems should hope for the same.