It happens to every design team at some point. Someone has the horrible realization that even though you’ve all been designing the same product for years, you’ve been doing it inconsistently. The apps, websites, and marketing pages are direct reflections not of a shared set of design styles and components but rather the individual taste of each designer who worked on them.

Look, there’s Jared’s signature love for big typography. And Karen’s affinity for pastels. And Jordan, for some reason, likes his interstitials to have buttons that say “close” rather than the X-shaped icon everyone else on the team uses.

“We need a design system,” everyone concludes, nodding emphatically.

And so, the team sets off on its quest. You research other style guides, do UI and UX audits of your products, and spend the next six months building out a beautiful, comprehensive design language. You launch it internally, to a grateful engineering and marketing team, and the blog post you wrote about it got a ton of attention. You did it!

But then…

It’s a week later. You’re sitting in a design critique and notice that Jared has nudged the header size up a few points in his mockup.

“That h1 looks bigger than it is in the style guide,” you volunteer.

“Yeah,” Jared says. “That type size isn’t working for me in this context. I need something bigger and bolder.”

Enter, the  

Every team that launches any sort of style guide runs into this problem, and it can be jarring how quickly it rears its head. At BuzzFeed, we ran into these kinds of discussions almost instantaneously after shipping Solid. And while no style guide can or should remain static and immovable, it’s important to give your team tools to have rational discussions about when to break away from the style guide, when to change it, and when to change their designs to better align with the guide.

One day, while talking to Allison, one of the BuzzFeed , about whether she should break the style guide or not, I accidentally came up with what I started calling The Style Guide Decision Tree — a series of questions to ask yourself in order to make the best decision possible for your product and its consistency. It wound up working well for us, and I’ve noticed it coming up a lot lately in conversations I’m having.

Without further ado, here it is:

Image: Cap Watkins

One important thing about the Decision Tree is that it really pushes designers to get creative with their use of your design system. It’s surprising what people can do when forced to adhere to constraints, and I personally believe even just the first two questions generated not only better design but very interesting applications of styles we already had available. I was constantly surprised by the ways people found to bend the guide without breaking it. And when we did break it, it was in thoughtful, purposeful ways.

Building a robust, useful style guide is the beginning of a long journey, not the end of one. Getting your teams to care for the overall system goes a long way toward making your design system more durable into the future.

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here