Design Systems

The purpose of the product shapes the design patterns it adopts.
A design system can be considered effective when it combines cost-effectiveness in the design process, and efficiency and satisfaction of the user experience in relation to the product’s purpose.
No matter how much we guard the brand, these things will happen – new requirements demand custom patterns and one-off tweaks. If we’re not conscious of them, such exceptions can dilute or weaken the brand.
Having looked how the team used the modules, we noticed that the most effective names in our system had one or more of these qualities: they were metaphorical, they had a personality, and they communicated the purpose of the pattern.
James Britton, an influential British educator, explains in Language and Learning that by conferring names on objects, we start “bringing them into existence,” just like children use language “to draw out of nothingness” the world around them.
...until you start calling a pattern by its actual name, it doesn’t exist in your system as a solid actionable block to work with. And every time you do use the name, you strengthen the element you call on, and evolve your design language.
Even a loosely set up system needs a solid foundation.
One of the simplest and most effective distinctions I’ve come across was suggested by Heydon Pickering in Inclusive Design Patterns. 10 The idea is to differentiate between links and calls to action (CTAs), rather than buttons and links. An important standalone action can be presented as a button, but be marked up either as a link or a button, depending on the interaction. The question of whether it’s a link or button is a matter of variants — first and foremost it’s a CTA.
What’s important is, of course, not the styles themselves but the effect they have. A functional tool should be useful and usable, but it should also feel simple, safe and robust.