Be Better: Design Systems

Ben’s email newsletter offers an in-depth look at how to make Design Systems better.

“If we want to be better at our jobs, we need to be better people.”

Over the last few years, many major brands have started to release microsites that explain the way they approach voice and tone, user experience, design, and code as they create products for the web and beyond. These design systems have changed the way we think about our work—shifting us toward a more systematic approach to web design. For companies like Sparkbox, this has impacted the kinds of products we deliver to our customers. Many of our projects now result in our team creating a living, breathing pattern library alongside our customer’s internal team. In this way, we can create something that encourages consistency, efficiency, and sustainability. We create a web that will last.

As we’ve tackled more projects that include design systems, we’ve learned a lot. We’ve created our own frameworks and have tried many of the tools available for creating them. We’ve used Brad Frost’s “Atomic Design” approach and we’ve used system categories that more closely mimic the internal language of a specific client. As usual, there are many ways to approach the construction of a design system, and the results are not always perfect. Kasey, who’s worked on one of the largest design system projects we’ve ever tackled, has written about some of the challenges we’ve seen in this work.

Despite the challenges, there is tremendous value in design system work. We’ve recently had the opportunity to work with Gap to create a cohesive design system for all of their brands. The project has been incredible. To work at this scale has been both exciting and eye-opening. As part of our participation in ConvergeSE, we co-presented about the work we’ve done on “Stitch,” the Gap design system. If you’d benefit from hearing what it’s like to embark on a project like this, spend some time watching this video where Drew (from Sparkbox) and Teresa (from Gap) share the project.

And whether or not to take this more systematic approach is not a binary decision—not every project needs the same type of design system. As Bryan points out, you need to do the work to understand the audience and the problems an internal team is trying to solve. We’ve come to appreciate the perspective that building a design system is building a product.
 
Organized Living is an organization that understood this. Last year, we had the opportunity to help redesign their web presence. Because of their product-centric view of a design system, we set out to deliver one from the beginning of the project. You can read about that experience and listen to an interview about the project with Ethan Marcotte, Karen McGrane, Ryan Cromwell, and Michael Hickerson.
 
This outcome of design system work—the ability to create something that can live beyond a release or two—is compelling. And I believe it’s freeing for an internal team, granting them the ability to rapidly develop new experiences by pulling together existing components. That speed, and the confidence that comes with well-tested modular design, means our teams can do more with less. And who doesn’t want that?

Do you want to learn more about how to sell a Design System to your team? I love to talk about this, drop me a line.