Design System

Our UX design team was looking for ways to improve, optimize and scale design workflows while achieving cohesive experience accross multiple applications.

Design System

Improve UX team efficiency and cohesive look of several applications.

Overview

As our UX design team expanded to 16 members, the need for a systematic and structured approach to our work became imperative. It was our responsibility to ensure a reusable and consistent design methodology to align with the development process. After evaluating various options for sharing project-specific design knowledge, we ultimately decided to establish a component-based design system.

Painpoints discovered

  • Designers need a better way to share knowledge
  • Similar components are designed and coded differently in each application
  • Adding features in products increased complexity exponentially and designers did not have time to solve bigger problems
  • Decisions around colors, buttons, fonts were not centralized
  • Developers did not share their code beyond their product team

Solutions

  • Build a design system that can unite teams across several products
  • Bring designers and engineers together through a shared language of components
  • Help designers focus on experience over style
  • Improve accessibility for all products by setting up design rules and standards

Team

16 Designers, 3 Developers

My responsibilities

  • Inspiring UX team towards this "side project"
  • Communicating benefits to other product teams
  • Promoting and discussing with developers
  • Scheduling design system review meeting mockups
  • Documenting design decisions



Gathering knowledge

First we had to start with auditing existing applications and their style guides. Also, gathering a team and bringing everyone onboard was a huge challenge. It was a side project, some designers loved it, they became dedicated to it, and some did not... but it scaled quickly.

Design system

Developers interviews

Design systems are easy to sell because everyone loves the idea of doing more, faster and consistently. However, asking developers for time out of their regular jobs required some convincing. One of the discussions outcome was an agreement on at what point would a Design System Element be ready. We agreed on:

Design system

Creating MVP

We started with a big future vision, but since we had limited resources, agreed to start with a smaller MVP. We started with one larger project and started documenting only few basic components. Creating MVP in Confluence became a good foundation for the future version of the design system. Later we created a basic Sketch ‘UI kit’ with symbols as closely aligned to the code as the design tool would allow. Flat images of components were displayed later on InVision with the corresponding Sketch source files to download. We went through few iterations. Everytime taking a feedback from a team and improving it.

Design system

Keep momentum & DOR

We scheduled bi-weekly meetings to discuss new patterns. We soon realized that setting up design decisions in components really speeds up everyone's work and makes decisions easier. It also improves product teams’ accessibility skills and system thinking. We defined a pattern ready when it was included in our master Sketch file but also discussed the following conditions:

  • The element's design decisions and evolution have been documented
  • In Sketch DSM, all visual states have been represented, format requirements met, naming conventions followed, and proper descriptions given
  • The element follows the overall look and feel of the design system
  • The element has been approved by the design team
  • Gatekeeper has added the element to the Master File
  • Gatekeeper has uploaded to Bitbucket
  • Gatekeeper has included the element into InVision UI Library

Design system

Outcome

It's a product. Now what? The next natural step was to treat this DS like a product consumed by internal "customers. At that point we discussed the following questions:

NEXT: EXECUTIVE TOOL