Last fall, our dev team wanted to get started with style guides. We had added a new member to the team, and as he was getting up to speed, we realized how lacking our project documentation was. If you've ever been a new developer on a team with weak documentation, you know how confusing it can be to try to familiarize yourself with a dozen projects without documentation.
The following is a guest post by Nick Berens, a senior front-end developer at wisnet.com. Nick and his team have been building websites through custom style guides for years. Over those years, Nick has been building and evolving a tool to help with this process. I'll let Nick explain both the philosophy and the tool.
I really like this post by Nathan Curtis where he discusses how buttons can be applied to a design system:
I love buttons. I can do things with buttons. Take a next step. Make a commitment. Get things done. With buttons, interaction springs to life.
That’s why Buttons are arguably a design system’s most important component. Devilishly simple, they offer a simple label in a defined region I can press. As such, buttons are where you apply a design language’s base attributes in ways that’ll ripple throughout more complex component later.
Borders, colors, text styles, icons; there’s so much to consider! But what I really wanted to make a quick note of here is the idea of resilience in a design, particularly where Nathan talks about adding components inside a button, like an icon:
When you add an element, even a simple icon, a button layout shouldn’t break down. Coping with less predictable elements reveals pesky issues of spacing and alignment inside.
So whenever you remove a component from inside a button then the button itself should still work. But this isn’t just important for buttons really, it’s important for any component that we’re building. In short: asking questions about how a certain element might break visually, or in terms of interaction, is vital to the process of building an effective design system.