Cobalt: Creating Consistency Across Multi-Platforms

Scenario

Initially, all of Talkdesk's design libraries were built on the Sketch tool, the company's main design tool. Something that worked well, but many designers missed more agile features for prototyping and handoff components directly in the tool itself with developers. People felt the need to migrate tools, but no one believed it was possible. Since the core libraries in Sketch were very complex and supplied several projects with countless products and dedicated squads. A legacy that no one wanted to touch due to laziness, trepidation, and fear.

I spoke with stakeholders and leadership to prioritize this need and presented a strategic migration plan with deadlines and a detailed phasing of steps on how we could proceed with the migration initiated by the Ops team and subsequently connecting all design teams.

Phased migration proposal: Discovery, Restructuring, Documentation, Activation and Maintenance

Detailed phasing proposal

Squad

Initial team composition

• 1 Designer System Ops (🙋🏻‍♀️)

• 1 Product Designer

• 1 Product Writer

• 1 Product Manager

• 5 Developers

Tools

• Sketch / Figma

• Zeroheight

• Jira / Confluence

• Google Suite: Docs / Sheets / Presentations / Forms

Discovery

After validating the prioritization of this initiative, I met with the Ops team to share the next steps. The initial idea was to collect evidence about the need for migration. I understood the scenario by talking to the teams and doing some research to assess whether migrating to another tool would make sense and how much effort would be required as it would not be something that could be done overnight. After launching a quantitative survey and calling some designers to talk, we realized that the interest in migrating was valid and the biggest barrier was having someone dedicated to be responsible and involved in this initiative.

Arguments about why to change the level of features and level of interest of designers

Reinforcement on how Figma Analytics could support maintenance on the use of libraries

Reorganization

We started working to rebuild the components and libraries in the Figma tool. It wasn't something where just an import/export from one tool to another would be done. Care was taken to review each component to understand whether its use was still valid and possible usability and structure improvements within Figma in terms of the logic of properties, variables, nomenclature, and information hierarchy.

I took advantage of this initial phase to create all Design Tokens from scratch based on existing product identities, which were not very clear in their definitions and specifications following the development libraries. In other words, there were already color and typography initial definitions, for example. But there was no Design Token structured at the name + style level that guaranteed consistency independent of the library.

In the same way, I also structured the hierarchy of core libraries with what was essential for all designers, the support libraries that would serve as a guide, and complementary libraries that would provide more product and business context such as the most used templates, patterns, cases usage and much more.

Structure of core libraries built on Figma

Consistency in property taxonomy in Design x Engineering

Color Tokens (preview)

In the context of improving designers' experience in using components and construction logic, a study was carried out to review inconsistencies and restructure the information architecture of the original library components (Sketch). Previously, designers needed to go through a “Tree view” experience to arrive at a certain variation of a component. With the implementation of Figma, it was possible to facilitate this process and the designer would only need to change the properties directly in the component itself in a more intuitive way using the switch tools (activate/deactivate) certain properties and choose the necessary variation for each case.

Likewise, this improvement was later reused by developers with the arrival of Dev Mode, a Figma tool that allows people without editing access to also interact with these variations of a library's components in an interactive Playground view.

Example of improvements to the Button component - Tree view in Sketch x Figma Experience

Dev Mode and interactive variations for non-editors

Component library rebuild in Figma

Review of component name inconsistencies in different libraries

Documentation

At first, the documentation of the company's libraries and components was somewhat superficial. It did not include all components, patterns, and styles. There was no clear and objective hierarchy of categories. This documentation was then restructured in the Zeroheight tool with visual and structural improvements to components and categories in mind.

Cobalt DS documentation home page within the Zeroheight tool after new identity + restructuring of categories and quick shortcuts

Additionally, time was dedicated to the initiatives prioritized in the team's sprints to focus on improvements within Ops processes involving documentation. Some of them were:

• Create a model template to serve as a basis for creating new component pages to maintain consistency in the way of documenting.

• Create a dedicated Support page to clarify initial doubts with FAQs, useful links, an indication of support channels, and direct contact with the team.

• Create the Foundations and Assets categories bringing all token specifications, layout structure, grid, and graphic elements such as icons, illustrations, and brand files.

• Constantly improve component pages that were superficial, incomplete, and/or non-existent.

• Create a review process within the documentation deliverables. Therefore, after building each new page, this was mapped in the team's Jira (kanban) where it underwent an evaluation of Design (guidelines, coherence, consistency), Writing (use cases, spellings, good practices), and Engineering (parity with libraries code and technical feasibility).

• Start mapping possible Patterns and Most Used Templates, that is, identifying the main models and use cases most used within the products and documenting them.

• Revisit with stakeholders the opportunity to acquire the functionality of the Zeroheight plan that includes Analytics to track the percentage of page hits.

Component page containing Design, Code, Accessibility, and Content

Support page within the Getting Started category

Page with video tutorials with practical tips on themes most requested by designers

Pattern page with use cases, shortcuts to core components, and best practices

Page with most used templates and detailed applications in different viewports

Page with process instructions for adding new icons to the Assets shared library

Activation

After defining the structuring of files and components, mapping main use cases, and bringing more parity to libraries, I introduced designers to Figma, estimating a natural learning curve. A deadline was set for teams to back up all key files in Sketch and begin the gradual migration to the new tool. Initially, the focus would be to prioritize essential projects, those most used and most sensitive to users.

I held live sessions with designers to share quick tips on migration, good practices, and a suggested schedule for how to prioritize the files to be migrated based on their level of use. We also leave an open channel on Slack for emergencies and any questions related to the migration process.

Reference to FAQs that we did in sessions with designers

Maintenance

After the migration was completed and more than 90% of designers were already building new prototypes directly from Figma and having their main projects migrated, we began to focus on maintaining the new libraries and improving documentation and design processes. We built a roadmap of initiatives and determined a task prioritization hierarchy to have an idea of things to improve and what we could prioritize in the next sprints with a clear vision of DS's evolution throughout the year.

Prioritization reference within the Ops team backlog

Reference of tasks mapped in the initiative roadmap with constant maintenance and improvements

Follow-up cycle

• Monitoring the adoption of new libraries

• Figma Analytics tracking with early adopter teams, most used components, and number of detached components

• Quarterly survey with designers and developers to understand the level of satisfaction with the libraries, processes, and tools used

• Biweekly interviews with product teams with at least 1 designer and 1 developer from different squads to collect evidence and reports in greater depth. Preferably, when possible, we also involve Product.

Thanks for reading!