Dashboard Design System

BACKGROUND

Dashboards were inconsistent across the product, each custom designed to a client's needs

Forma.ai dashboards are primarily used by sales reps and sales manager to review their performance. It helps them make informed choices by displaying metrics such as how much attainment they need to reach their quota, how they are performing over the past year, or which product quotas are doing well.

At the time, each dashboard was custom designed to adhere to each client’s custom needs. The experience was inconsistent across the dashboards. Customer teams had troubles with understanding what goes into a dashboard as well as which types of charts and widgets to use. As we continued to scale, it was becoming increasingly important to reach a cohesive product experience.

SOLUTION

Introducing a dashboard design system

To address this, I brought up the idea of introducing a dedicated design system for dashboards. The core design system included guidelines and principles for foundational components which fed into the new dashboard design system. With every new client onboarded, the design system would evolve with each problem and use case discovered.

TARGET AUDIENCE

Creating alignment across teams

The dashboard design system in the initial stages found it's home in Figma, providing easy access for designers, engineers and customer operation teams. As the design team thought of future iterations to our design systems, we considered the potential benefits of integrating the design system with Storybook, contemplating how this combination could further enhance our development workflow and overall user experience.

IDEATION

Creating the building blocks

The components created were based off of the atomic design principles, as the core design system was too. The dashboard design system was mostly composed of larger blocks – molecules, organisms, templates and pages related to dashboards. Atoms such as typography were used from the core library. Additional colour palettes were also built to better suit data visualizations for accessibility.

GUIDELINES

Dashboards

With an established first version of the library, each new client dashboard created utilized components and patterns from the system. These are some of the documentation surrounding dashboard layouts and cards.

COMPONENTS

Charts

Charts are broken up into distinct types, focusing on part-to-whole representations, trends and comparisons. Conducting research on existing chart design systems and an audit of all our chart cases provided insights to identify the best categorization method.

COMPONENTS

Go Gets and Tables

Go Gets are fundamental widgets in displaying attainment and target metrics, typically displayed on the performance page. Tables house transaction level detail information and are the most commonly used component. Having detailed documentation and examples of these widgets used allowed our team to implement quickly with more consistency.

MAINTENANCE

Monthly design system meetings, #design-systems-feedback

The design team established a cadence of monthly design meetings, open to all teams, which allowed for the validation of new or changed components and provided a forum for questions and feedback. In these monthly meetings, we discussed both the core and dashboard systems, in which I was in charge of managing updates, conversations and feedback relating to any component of the dashboard systems. These forums and discussions were expanded upon in our created Slack Channels in order to facilitate further discussions and feedback. This showed the open and fluid teamwork between the product and engineering team.

CHALLENGES

Flexibility <-> Customization

Finding the right balance between providing flexibility in components while ensuring customization options.

Categorizing and naming components

Establishing a coherent naming taxonomy and information architecture for diverse widget types.

Adoption of the system

Achieving widespread adoption of the design system across clients and aligning existing components.