CNBC design system
It’s a central hub for all our design principles, components, and guidelines, helping our designers and developers create cohesive and high-quality user interfaces more efficiently.
Overview:
I led the construction of the Design System for CNBC.com. This work consists of a Figma based Pattern Library with Storybook integration that functioned as our style guide. Our Pattern Library is intended to be a centralized place where designers shape and evolve our design language over time. This designer focused document integrates with Storybook, our UI component explorer that brings our patterns to life. Storybook also houses foundational principles and overarching rulesets through a simple platform, accessible for all internal teams.
The Problem:
- Design Debt: From a lack of foundations, CNBC.com was redesigned and had a series of dependencies from an older platform. This mix of new & old resulted in an almost never-ending accruement of design debt because the design language wasn’t built off of it’s own solid foundation.
- Unscalable Design Patterns: Many existing components did not scale well for old and new use cases. This led to a lot of single use patterns being implemented, resulting in a poor, inconsistent user experience and difficulty in managing the various styles.
- No Centralized Location: There was no single source of truth to access (shared library) styles for our product. Designs were dispersed throughout many different files and tools (i.e Sketch/Illustrator and more recently Figma) and locations, with little attempts at versioning. This made it cumbersome to navigate to designs, and led to a more inconsistent visual language. Additionally, there was also no clear source of documentation for guidelines on how to use certain styles for designers and engineers.
The Solution:
- Pattern Library: The goals of our Pattern Library is to provide a centralized location to access the most-up-to-date designs used for our product. This would include all the core foundations such as typography, color, layout as well as the patterns for components and modules.
- Engineers can use the Pattern Library to cross check specifications, such as different attributes (layout, size, color, etc) for elements, components and modules. QE could access the Pattern Library to cross-check and reference UI for the website, comparing how things are against how they should be for accuracy.
- Style Guide: The goals of our Style Guide are to provide principles, guidelines and documentation from a few different perspectives. Engineers will use the space to house and test these new components. QA can reference, reviewing Figma designs embedded next to Storybook developed component. Product teams can reference existing patterns when considering future product directions or enhancements.
Asset Discovery:
We first needed to assess the design debt on CNBC.COM. I led the UI audit, collaborating with members from the agile team, QA, product, and engineering departments.
- Audit and discuss UI patterns and interactions.
- Flag the UI inconsistencies by running component cutout sessions of all known pieces of the site and making a running inventory of what is needed
- Find opportunities for short & long-term improvements
- Lay the ground-work for the Style Guide
Google sheets showing taxonomy inventory
Structured a cutout process to categorize all components.
atomic structure:
The next step in the process was to decide on a framework for our pattern library and start thinking about sharing and governing documents.
Pattern Library Organization: To promote consistency across the system, I needed to define rules for combining and encapsulating our patterns. I reviewed several different design systems (pattern libraries and style guides) and found that their frameworks were largely similar. A guiding principle of our competitive analysis was scalability and reusability.
We settled on a hierarchical approach to classifying our functional patterns based on their complexity, deciding to adopt Atomic Design, pioneered by Brad Frost. The concept of atoms, molecules, organisms, templates, and pages would work well for categorization. However, we modified the methodology to suit our needs, ultimately deciding that we would not require “pages” or “templates”. We also adjusted the naming conventions to what our team felt worked best for CNBC:
Atoms = Elements
Molecules = Components
Organisms = Modules
Pattern Documentation & Taxonomy: After choosing our methodology, we needed to apply our taxonomy to the newly refined pattern library. Working with the mobile apps product designer, we established our structured approach in Figma. This allowed us to effectively document and organize our patterns, ensuring clarity and ease of use for the entire team.
Using a detailed component naming structure in Figma, including component name, type, variation, and screen type, makes for an organized and efficient pattern library. It enhances clarity and consistency, making it easier for designers and developers to locate and understand components quickly, facilitating smooth collaboration and reducing duplication.
This structure simplifies maintenance and scalability, aids in efficient prototyping and handoff, and ensures design consistency across devices, resulting in a cohesive user experience.
As the design system evolves, new components and variations will be added. A robust naming structure makes it easier to integrate these new elements without disrupting the existing organization. It also simplifies the process of updating or modifying components, as the naming conventions provide clear guidance on where each component fits within the system.
Typography:
A shared use of typography required clear guidelines and patterns that everyone could understand. CNBC has a variety of page types across its sections, including headline-driven landing pages, in-depth articles, and data-heavy quote pages. We needed a dynamic typography scale system that could balance these options and provide a compelling vertical rhythm in the designs.
I decided on a modular scale of Major Second (1.125), rounded to the nearest whole number. This scale could be used consistently across our four breakpoints. Additionally, a line-height system was incorporated using 1.125 times the font size. While this line-height was intended to serve as a baseline, designers could adjust it as needed for specific applications. This approach ensured flexibility while maintaining visual harmony and consistency throughout the site.
color:
My initial step is to make the use of color more consistent throughout the design system by considering how color functions within our pattern library. Our font colors are generated from the "system" palette of colors. It is preferred that the color is on the dark end of the spectrum (+40 or higher) to ensure readability. Font foreground colors should provide enough contrast to be accessible for the visually impaired and meet the minimum WCAG AA Standard. We strive to follow this contrast rule for all components that overlay, not just typography. Our touchpoints for color include:
- Different types and hierarchy of text (body, headings, blockquotes)
- Separators and decorations
- Links and Call to Actions
- Confirmation and Error States
- Chart Data (Positive, Negative, Market Open, and After Hours)
- We use a tonal range number system for balanced progression, starting with 0 as the lightest and working in increments of 5 or 10 as needed for the color application, with 100 being the darkest color within the range. For example, "System 10" is easier for the team to remember compared to an arbitrary name such as "light concrete." This predictable number system can scale accordingly.
- Value: Specify the hex value associated with each type and range number to ensure clarity and consistency across the design system.
Spatial & Grids:
Space within our product helps us organize content and create a clear visual hierarchy. Developing a ruleset was crucial for constructing our patterns. For spacing, we used a 4pt grid system with increments of 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, and 48. Why do we use a 4pt grid? The variety of screen sizes and pixel densities has increased significantly.
Utilizing an even number like 4 to space and size elements allows for easy and consistent scaling. Most popular screen sizes are divisible by 4, which works well. A smaller number than 4 would increase the number of options, adding complexity, while a larger number would reduce flexibility too much. We initially tried an 8pt grid but found it too rigid for elements that were close in proximity, leading us to break the rules frequently. The 4pt grid strikes the right balance for our needs.
Storybook Integration:
Early in the development of the Pattern Library, I explored using Zeroheight and even Figma to house our style guide, aiming for a consumable format for other teams. However, it became clear that input from these teams was essential to guide its growth and usage.The decision to use Storybook emerged as a more suitable direction for the larger team.
Storybook is an open-source tool for developing UI components in isolation, compatible with React and other frameworks. Adopting Storybook served two key purposes: first, providing engineers with a centralized space for building components; and second, enabling the design team to embed specific style guide information in Storybook notes. The integration of the Figma node view plug-in into Storybook further enhanced the process, allowing engineers to view real-time designs and reference specs as components were being constructed.
growth & workflow:
Analytics, awareness and governanceWe started leveraging Figma’s internal Design System Analytics to shape the usage of our system. By closely monitoring the use of libraries, components, and internal styles, we can identify areas that need further refinement and determine which parts of the design system are unnecessary. This approach helps us reduce maintenance efforts and focus on areas that will provide the most value to our internal team.
Analyzing usage is also instrumental in demonstrating the effectiveness of an analytics-driven design system to stakeholders, minimizing assumptions about its potential applications and highlighting its practical benefits in real-world scenarios.
Lessons Learned :
I've mapped out hypothetical use cases for planning and utilizing the design system pattern library across designers, engineers, and product users. This approach will ensure consistent and efficient design implementation, streamline collaboration among team members, and enhance the overall user experience.
- To enhance collaboration, I initially concentrated on close cross-team members but should have involved a broader range of colleagues, including QE, Infrastructure, and SoftOps. Their insights, such as specifications for Storybook implementations, were initially overlooked but proved crucial.
- Demonstrating value to leadership earlier in the process could have accelerated resource allocation and implementation. Leadership has shown genuine interest, so showcasing early successes and potential benefits could have facilitated quicker support and allocation of resources for our initiatives.
I estimated a 40% faster start-up time for screen designs by comparing the effort required to complete "in-progress" design stories using existing components versus creating new ones.
This efficiency gain was significant across all Agile teams within the company that adopted our system. Since its adoption, the design system has experienced rapid growth, with over 1,000 unique elements, components, and modules added. This growth is a testament to the system's success and ongoing impact across the organization.
