Introducing the Idea

I introduced the idea of building a design system at Genius Sports Services annual away days in Vilnius, Lithuania. I presented a brief overview of my plans to launch the design system project. This presentation was the first step in getting buy in from all team leads that would benefit and contribute to the design system product. A design system is a living product with a roadmap & backlog. It’s an iterative process that combines UX, visual design, development, management and consensus around source of truth. Buy-in was absolutely crucial.

Goals and Success Measurement

Along with some stakeholder input and some research into other mature design systems, I put together a set of goals that the design system should meet:

Create a shared design language
The design system should facilitate and create a shared understanding between product owners, designers, developers and stake holders.

Be reusable
The design system should be built in a way that it facilitates reusability through design. Patterns should be well defined and agnostic, yet adhere to most common and understood best UX practices to be applied where needed as needed.

Communicate design decisions
The design system should clearly explain design decisions and defend them through extensive research, user understanding, best practices and product knowledge.

Shape expectations
The design system needs to be able to lead product expectations before the move into development. Product owners should be able to plan around and expect certain levels of inclusion of the design system.

Empower product owners
Product owners should feel that they can easily, and quickly build out products that meet the needs of the business or client.

Be sustainable
The design system should be built in a way that makes it a living product that evolves over time and meets the needs of products, as well as define direction of new products through discovery.

Be clearly defined
The design system should be presented with purpose and its mission clearly defined and communicated.

Be flexible
The design system will grow with the needs of the business. The design system should be able to integrate into any development process. The system should adhere to a “graceful degradation” policy by which the system can be used in part, or whole without failing or becoming unusable.

Demonstrate our design principles
The design system must demonstrate our design principles, and elaborate on their purpose by example.

Easily accessible
The design system should be easily accessed by the entire organization.

Easy to update (keep updated)
The design system should be updated on a regular basis. It would be nice if it could be updated via some automated workflow.

Make feedback easy
The design system team should be able to receive feedback and respond in a timely manner.

Include a version history or change log
The design system changes should be available and transparent.

Design System KPI’s

It’s important that a team and a product can measure its success and have the ability to improve with time and feedback.

UX Scorecard

Improve Score by %

We should be looking at ways of improving overall scores for our products.

Adoption by Team

% of Adoption by Product Line

We should strive for adoption over time, providing a valuable and reusable resource for all products, existing and new.

Coverage of Product

% of Products Supported

How much of the product eco-system do we cover? Has out design system taken into consideration different device and use cases?

Overall Satisfaction

% of Satisfaction

Easily met with a survey sent out periodically to development leads and product owners.

Building the Team

Putting together the right team was important to the success of the design system. I enlisted several members from key areas of the business who would contribute, plan and organize activities, write documentation and set technical and design precedent. These are the keepers of design truth.

Jason Luna

Design System Product Owner

Alius Kveinys

Lead Designer

Daniela Angarita

Lead Front-End Tooling

Tommy Barth

Lead Front-End Delivery (React)

Lissa Aguilar

UX Strategist

Brandon Smith

UX Strategist

Dan Mizuba

QA Manager

Rashmi Lopez

Senior UI Designer

Stephen Gardner

Executive Adviser

Contribution

After the team was formed, it was important that we understand how this team would interact with the rest with our product teams to contribute to the design system.

Ideally, when the GSDS reaches a point of inclusion in the development process, and the core design team (above) has established rules of engagement – we would open the design system to a small group of people who will be selected for a period of time to collaborate on the design system. The Design System Small Group will meet once a month to discuss in detail the direction and set up a series of goals. This could turn into a story writing session that actively writes tickets into the GSDS backlog. The small group should contain product owners and development leads that are actively contributing to a product we’re focusing on.

A federated team will:

  • broaden legitimate relevance to many platforms and lines of business (e.g. Betgenius console, vs. livestats products)
  • limit perceptions of bias by representing many perspectives
  • ease spreading the system across teams by equipping more evangelists

Technical Overview

I created a simple diagram to illustrate the technical and delivery architecture of the design system. This would ultimately lead to the building of proprietary tools that would create automated and semi-automated solutions to ensure that the design system was deeply integrated and well documented into our product development pipelines. We also used many third-party tools and software solutions on top of our custom built tools.

Toolkit

Visual Design Tools

Sketch

Sketch is our go to design tool of choice. We design all wireframes and hi-res UI within Sketch.

Framer

We use Framer to build out animated and interactive prototypes and mock-ups.

Adobe Creative Cloud

We use Photoshop, Illustrator, After Effects and Animate to create illustrations, images, icons and animations that are used in more polished mockups and prototypes.

Visual Design Repository

Abstract

Abstract is crucial in our design delivery process. It is our main repository and version control solution for all of our design work. It allows us to share and collaborate on different projects within our product ecosystem. It maintains solid version control and data redundancy. It allows us to share design with development and stakeholders – each getting something valuable from the tool’s inspect mode. Stakeholders and product owners can comment on design and developers can pull code from or get the meta (sizing, spacing, margin, etc.) from the design once the link has been shared. Developers can also export any design component, image or library directly from Abstract.

Design Tokens

Theo (by Salesforce UX)

Theo consumes Design Token files which are a central location to store design related information such as colors, fonts, widths, animations, etc. These raw values can then be transformed and formatted to meet the needs of any platform.

Let’s say you have a web, native iOS, and native Android application that would like to share information such as background colors.

The web might like to consume the colors as hsla values formatted as Sass variables in an .scss file.

iOS might like rgba values formatted as .json.

Finally, Android might like 8 Digit Hex (AARRGGBB) values formatted as .xml.

Instead of hard coding this information in each platform/format, Theo can consume the centralized Design Tokens and output files for each platform.

Component Repo

Storybook

Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient. We used Storybook to share and before we built the theme and builder tool, it was a sandbox to test out different variations of components using different data sets and feeds and styling options.

Custom Development Tools

Theme Genius

We wanted to create an easy way for developers and our commercial partners to quickly generate themed components, widgets and ad creatives. We built a tool called Theme Genius which allows the user to see color, font and other CSS attribute edits in real time against live data and components in our library. The theme could be exported as a json file or a URL hash that could be inserted into other delivery platforms like our Builder tool.

Builder Tool

This one didn’t have a fancy name, but did do quite a bit. We developed a build tool that allowed developers, product owners and our commercial teams to quickly generate components built from a nifty drag and drop interface and a library of dozens of atomic components, widgets, and data feeds from our libraries. The builder could be paired with our theming tool or built into a product that required a more “on rail” approach. The tool could be configured to allow for different kinds access. It was used to build many of our dynamic ad creative products as well as our hosted data solutions. This allowed for open (yet controlled) contributions to the design system and its growing library of components. Eventually, we enhanced this tool to allow for it to be used on our various tools and data platforms and could be quickly rolled out for various client needs as a quick and easy WYSIWYG tool.

Governance

Part of establishing the design system as a living product was to create a set of governing standards and processes to ensure that there were viable pathways to extend and scale the design system to meet the needs of our ever evolving product ecosystem. The last thing we wanted to do was to plan our own obsolescence through a lack of diligence.

As product teams focused on completing tasks and getting releases out the door to keep up with delivery milestones, our focus was to make sure that the tools they were using didn’t become blockers in that well-oiled machine. After all, product was mature, development teams had fully staffed supportive roles that ensure that those teams stayed on track.

We were absolutely aware of this: Product teams will find a way without the design system – if it gets in their way they’ll hack around it until it becomes another useless tool on a heap of useless tools from the past. 

What happens when:

  • Developer can’t find a component that meets the need of the functional requirement.
  • A component comes close – but doesn’t quite solve the problem.
  • Product owner has concerns about the performance standards of DS components.
  • An entirely new component is required.

There were three pathways that we had to consider when adding to or modifying components in the design system.

  • It exists and meets the need of the requirement completely
  • It exists, but doesn’t meet the need of the requirement completely
  • It doesn’t exist at all, but it needs to

We had a set of “vanilla” components – standard components that would remain concrete – a “visual north star” that we would use to build other components from. We would try and reuse as much of vanilla without breaking it.

What did “breaking it” mean? Simply – if a vanilla component is modified to extend/alter its intended purpose (such as a drop down with a single select function), we would consider that “breaking” the component and harming the integrity of our core set of components. Modification would only be non-destructive if:

  • Changes can be applied through Theming Tool (color, padding, margin, typeface, typescale, borders, hover states)
  • Changes can be applied Globally (no one-off styling of component -no hard coded style values)

In order to eliminate all avenues of possibility, we’d ask the Product Owner and Tech Lead if they could modify requirements without breaking their acceptance criteria. The most common answer was “no” – as expected.

So how do continue to add to the design system without it being a free-for-all?

This is where the value of governance comes in.

 

Scenarios

Scenario 1: It Just Works

The product teams look for and find exactly what they’re looking for in our component repository. They design and built to spec without the breaking or modification of existing components.

Best case scenarios are often the most sporadic. 

Scenario 2: It doesn’t exist – It doesn’t meet needs

The product team has come to the conclusion that what they’re looking for just isn’t there. Or it’s just there, but doesn’t meet requirements. In this case, the product team should be raising a ticket to the design system team.

To better understand the issue, the teams will have a conversation and then determine whether or not changes to the design system need to happen. The design system team can often help the product team towards a solution without new components.

Scenario 3: Ok, but we actually need something new

The teams have reached a point where new additions/modifications MUST be made to the design system. There’s nothing that exists or comes close to meeting the needs of the product team.

We have to decide how to approach this new work. Is this a “one-off” or does this new component add to the design system?

  1. We consider a one-off component to be something used that solves a single, siloed and unique problem for a specific product. We can’t assume that this component will be used anywhere else for any other product to solve any other problem. This component will not be added to our design system library.
  2. A component becomes part of the design system if it it can serve more than just a single product and single problem for a product team. It is agnostic to some degree in its use, but serves a global purpose.

If the work is considered a one-off, then it will be added to the technical debt and backlog of the requesting product team. They will define scope, definitions of done and acceptance criteria. Although this component will not be part of the design system, it is tagged and the design system team is made aware. We have found, that after some soak time, one off components may very well meet needs down the road and we would consider insertion into the design system.

If the component is going to be a part of the design system, the DS team will prioritize and insert into their backlog where the work will be defined and done. It will be tagged and categorized and become part of the design system library.

Work Process

1. Prototyping

After both product and design system teams determine who will own the component – it feeds through a well-defined UX discovery and design process, the difference being who is working on it. There are embedded UX strategists and visual designers on the product teams that handle the execution of the component in the same way the design system team would. Initial concepts are created via sketching, whiteboarding, paper proto, browser prototype or any other work product that clearly defines the work to be done by development.

2. Concept Review

Both product and DS teams will review the conceptual work to make sure that it meets all requirement needs. If there are things that haven’t been addressed, the team responsible for delivery will continue to iterate and review.

3. Design and Development

At this stage the conceptual work has been approved and the originating story or task is amended with any additional or changed information that came out of the prototyping process. The work will then be assigned formally, wireframes and prototypes turned into fully rendered dev ready design.

The development of a component varies by how complex it might be – it could be a simple breadcrumb nav, or a fully featured sports score center with dozens of visualizations and data points.

4. Testing

At different stages of the development process the component will undergo testing in the following areas to ensure that it meets the standards set by both UX and development leadership.

  • Content – The component displays its intended information correctly, it scales to different content types (as defined) and adheres to localization standards
  • Accessibility – Most of our components meet or exceed WCAG 2.1 AA standards.
  • Device Requirements – Since most of our components are browser rendered, they must meet or exceed target browser support standards. In other cases, where the component is rendered in native applications, it must adhere to those device specific requirements and standards.
  • Functionality – Good ol’ unit testing
  • Stress – Depending on where this component will be delivered, it may undergo stress testing to capture performance data in edge cases
  • Must Pass Internal Code Review
  • Must Pass Internal Design Review
  • Other QA – There might be other delivery requirements set by our customers or delivery platform. In this case, we usually work with a third-party to conduct this testing and QA.

5. Documentation

This really isn’t a set point in the process, documentation happens all the time. Documentation may include things such as design & usage guidelines, technical documentation, customer integration communications, change logs and other artifacts like commit messages.

6. Staging and Delivery

Sticking to the product team’s release cycle, because we’re meeting a product requirement. The teams prepare a release candidate and push to UAT for final acceptance. The component development work is merged with our core production branch on the design system once all tests are complete. The design system team then prepares for support and global roll-out (if we’re not working on a one off).