Migrating Design Systems
Sometimes, migrating a Design System might seem like an easy task to accomplish. Unfortunately, it’s not as easy as pie. It’s only normal to start questioning what are some of the first steps you need to take, or what to check and validate before even thinking about migrating a DS from one software to another.
The following document will help you prep everything you need in order to accomplish this.
Main Goal?
Offer an easy guide to assess what you need to have beforehand and steps for migrating a Design System from one platform/software to another. Let's strengthen and validate important features in this process.
What to expect?
This guide will show you in 4 steps what you need to consider for a successful Design System migration. Each step has a check list and a description with backup information and links.
This document is NOT INTENDED to teach what a Design System is or how to do them. It won’t teach how to create components, symbols and so on as each platform/software has its unique features and their usage may vary depending on team workflows and standards.
Before starting...
The idea behind this document came from a specific task:
“We need to migrate the Design System from Sketch to Figma but we don’t know what comes first, when and how.”
Putting this into perspective and using the STAR Method:
-
Need to migrate a Design System from one platform to another
Design System – the complete set of design standards, documentation, and principles along with the toolkit (UI patterns and code components) to achieve those standards.
-
Identify and define the process to do that migration
-
1. Define the current status of the Design System
2. Define roles and owners
3. Define key actions -
Start transitioning the Design System per bits
Further reading: Flow to make a good Design System Migration. Get the basics in the following document:
Follow this 4-step process to see the big picture, identify possible flaws and improvements before migrating the system.
Step 1. Reviewing Needs
Map the Process Identify who does who and how things currently work
[ ] Identify who delivers and who approves
[ ] Identify who will use it
[ ] Identify the product or products that the Design System will impact
Define the Target Who is going to use the Design system? (Designs, PMs, Developers, Stakeholders... etc)
[ ] List all decision-makers
[ ] Target includes core values of the company
Define Purpose What’s the reason for creating the Design System?
[ ] List of people who take decisions
Define Objectives What are the goals of the Design System? (Solve issues, have a single source... etc)
[ ] List of goals (Specific, Measurable, Achievable, Relevant and Timed)
Step 2. Define Design System Maturity
Not implemented Components/Symbols exist but there is not a defined structure or you have a basic ‘Style Guide’
[ ] Define type of Design System.
Is it a Modular system (interchangeable and reusable) or Integrated system (parts are not interchangeable)?
Is it a Strict system (needs to be very detailed) or Loose system (provides a framework but exists freedom to use it)?
Is it a Centralized system (one team is in charge) or Distributed system (several teams works on it)?
[ ] Perform a Visual Audit
[ ] Gather all components/symbols in one place
Could be in a page, in a frame, etc... (Read more about Atomic Design. This lecture will help in the organization and structure of your Design System) Atomic Design Methodology | Atomic Design by Brad Frost
[ ] Define prioritization of components.
Identify which components are critical for your product and prioritize which needs to be organized and documented.
Designed but not Coded/Documented properly There's a structure and/or organization. Designers can use components to create flows but it's not coded (exists a repository where you can see the components live) or documentation is missing
[ ] Identify what is the current process
[ ] Identify where it’s located
Coded There's a repository where developers put coded components. These components are used on the product(s)
[ ] Identify the Coded Library
Step 3. Define Governance
Players You already identified the process, who is involved, and the status of the design system. Now you need to define who will work with the Design System
[ ] Define Players
Further reading: RACI Matrix
You can use a RACI matrix to determine/identify players and roles for setting a Governance. Source
Roles Clarify who leads the team, who’s making key decisions and who does the operational tasks. As a tip, you can define here a Scrum Master role if possible and a Quality Control* role
[ ] Define Roles
Further reading:
UX Design Systems | Create & Maintain | Adobe XD Ideas
*Quality control is a subset of QA. In QC, teams ensure that the developed product meets the organization’s quality standards. Defects in a software product, such as UI glitches, design imperfections or accessibility issues. Source
Work Cadence Each role needs to have a list of tasks and what needs to be done with realistic times (allocation and meetings).
[ ] Define Work Cadence*
[ ] Define communication channels
Cadence can be referred to when, where and how a leader or manager and his team regularly meet and where team members and staff have an opportunity to share views and information.
Step 4. Structure of Design System
Visual Audit Depending on the implementation stage, probably the Design System will have, or not, certain documentation around it.
[ ] Describe Problem-Solution
[ ] Identify Functional Documentation
[ ] Identify Technical Documentation
Further reading: How to govern a design system that is continuously evolving
Setting a structure Organize your Design System and define a structure for it. You can have a single or multiple pages or even files. (Depends on how big and detailed the Design System is)
[ ] Includes Branding rules & Language
[ ] Include Style Guide*
Style guide – Another subclass in the design system, this static documentation describes the design system itself: how products should look and feel, use cases for UI patterns, correct typographic scales, etc.
[ ] Include Pattern Library*
Pattern Library – A subclass in the design system, this is the set of design patterns for use across a company.
A 4-step process than can help you to set a structure. This process can be applied to Style Guides and Pattern Libraries. Discover: audit and gather requirements and specific considerations Define: taxonomy, properties and variations Design: Leveraging existing designs and requirements and start building Deliver: Review and iterate with stakeholders until approval.
General thoughts
This is just a guide that can be replicated and adapted to any type of Design System and its maturity. If your team just has a Style Guide, try to adapt this 4-step to it. Or if you only have a few components or a collection of symbols, give it a try and shape your Design System.
The key of success is framing the whole picture (what do you have, who is involved and how you manage it all) no matter the level of maturity your Design System has.
Also, don’t worry about the operational process (eg. creating components in Figma or symbols in Sketch), first get your stuff organized and then get to action. It will take you more time (and resources) to fix things.
You can download for free a cheat sheet for the Design Systems clicking the button below