Thinking in Design Systems
Solid user experiences are core to the product strategy of most customer/consumer facing digital companies, but asking design teams to be solely responsible for executing these experiences can create a potential bottleneck for innovation—especially if these teams are under-resourced.
Design systems help alleviate these bottlenecks by codifying the intersection between technology and design to serve as the manual for infusing a customer-centric, design-driven culture into the product development process.
The Evolution of Design Systems
For years, UX teams have endeavored to build and maintain custom styleguides for their products. What began as Photoshop files and large hex value tables has evolved into Sketch files that move between tools like InVision and Zeplin. But the newest challenge in building and maintaining these systems surrounds maintaining visual and technical consistency of these elements when multiple teams are working on multiple front-ends simultaneously.
The task of scaling front-ends to be both easy to build and highly performant is a fairly nascent field in software engineering. Front-ends are consistently being asked to do more—they are asked to apply business logic, to manage state and to animate seamlessly as the user interacts with them. Companies requiring a multitude of front-ends need to invest in scalable tools that modularize reusable design and business logic to make building them easier.
Twitter noticed this when the number of tools they were building were multiplying rapidly, with development resources failing to keep up. Designers were frustrated by the lack of cohesion between their interfaces. And from that chaos (and a well-timed “hackweek”) emerged Bootstrap. Mark Thornton, Jacob Otto, and their team of designers and developers stumbled upon a model that would define the next phase of modern web application design. Facebook, Salesforce, and Airbnb have invested in similar approaches, either centralizing their design system to a single team or investing into building reusable UI components across the organization.
Scaling Design
These approaches unblock product teams by reducing their reliance on dedicated product designers. Instead of architecting one-off solutions, why not build a service that lets you reuse modular microservices for a number of apps?
Design systems generate scalability by democratizing front-end development, and to some degree, design itself. Full-stack engineers no longer need to understand the intricacies of DOMs (let alone virtual DOMs) to be efficient front-end developers. It frees them from cumbersome red lines littered across design mockups, leaving more time to focus on fetching data quickly and accurately.
For our designers, it gives them the ability to quickly migrate from wire-framing to high-fidelity, clickable prototypes—they spend less time crafting the perfect border radius, and more time building holistic experiences that differentiate our products. A common UI library allows our team of four designers to efficiently service nearly a dozen engineering teams.
Challenges of Working with Design Systems
It’s natural for designers to shudder at the idea of sacrificing their creative freedom in favor of a “one-size-fits-all” style guide. Designers love re-inventing the wheel: it’s in our DNA. And when it comes to products, visual design is always ripe for critique and evolution.
Design systems make that sort of “pie-in-the-sky” exploratory visual design difficult to execute (but certainly not impossible). Instead, we work hard to find ways to infuse creativity into our design process by taking a more structured approach to ideation.
When we’re designing a new product, we always stress-test the existing components we’re planning to use. We’ll ask ourselves, “If we had no component library in place, how would we want this thing to look?” In doing so, we’re able to challenge existing principles and debate previously established guidelines for stylistic elements like drop shadows, borders, fills, and so on. That constant, component-centered exploration allows us to evolve our system incrementally.
Quantcast’s Design System
Historically, Quantcast’s front-end capabilities have, ironically, been mired by our deeply-rooted backend proficiency. Superior modeling and data-processing capabilities serve as a key differentiator in our market. But in order to expose those superpowers, we need UIs that highlight the power and accuracy of our modeling. And we need to design and build those UIs with limited bandwidth on our teams.
It burns a designer’s soul to see the same button implemented into two different places with two different classes. The design team at Quantcast had enough soul-burning. We endeavored to build a CSS styleguide that would hammer out CSS bloat once and for all. We started with a simple stylesheet that let developers apply classes to their markup to create visually consistent buttons, flexible grid structures, and other common components.
This helped maintain consistency, but the approach fell apart when our CSS structure was too closely tied to its implementations in various products. Deeply nested selectors can do this to you. You’re forced to stick to a precise class hierarchy to get the styles you want, necessitating strict markup guidelines. And humans (read: engineers) have trouble following strict guidelines. We had simple hyphen-case versus camel-case miscues ruining entire design layouts.
We knew we had to revise our approach. We could have fixed this problem by simply migrating to a more scalable CSS organizational scheme, like BEM, but we decided to take it a step further: let’s just abstract our styleguide into reusable Javascript components built on top of the world’s most popular front-end frameworks.
We began this process by building a bunch of Angular directives, which our engineering teams preferred. We soon realized that literally every new front-end engineer we hired preferred React, and so we began to build a React component library in parallel.
Today, we have three repos maintained by a front-end team that sits within product design: first, a styles codebase that houses all the CSS for our components, written according to BEM specifications. Second, a library of Angular components that can take in data and spit out fully functional, interactive UI elements. And third, a library of React components which, much like their Angular counterparts, can take in props that translate into UI elements. Our React codebase is still very much in its infancy, but the lessons learned from developing our Angular components, and feedback from engineering teams using those components, has made our fledgling React library the most useful yet.
Feedback and Response
The response was tremendous—it had a huge impact on the velocity of teams that were having trouble knowing where to begin when it came to building their front-ends. In response, we decided to productize these frameworks and establish a group of engineers within the Product Design team dedicated solely to building and evolving our CSS and Javascript frameworks. In addition, they help engineering teams without front-end resources get started on their apps by bootstrapping them with our tools, setting up their directories and build tools, and creating a front-end deployment process that meets their needs while being closely aligned to the rest of the applications at the company.
The Future of Our Design System
Design systems—and, more broadly, design languages—have existed since the dawn of user interfaces. What sets our initiatives apart is the way we’re trying to marry design and development to produce a framework that is not only fully functional, but also allows our engineering teams to learn front-end development as they build our products. We want this framework to serve as a growth tool for our engineers to learn front-end development, and add that to their already impressive repertoire of back-end capabilities. That’s why we’re encouraging the use of TypeScript, so that Java veterans can more easily understand the nuances of a dynamically typed language like Javascript. And why we leverage our front-end team as consultants for the company at large. These initiatives remind engineering teams that they shouldn’t feel isolated when it comes to front-end development—there are resources available at the company to help.
Building a passion for beautiful and performant front-ends is undeniably a challenge for any company. Investing in the right infrastructure is key to communicating to the company at large that we care about crafting a superior user experience, grounded in solid front-ends and well-tested design principles.
If you’d like to learn more, or join us on our mission to reinvent front-end engineering at Quantcast, check out our job board.
