Background

There are a number of reasons why a design system was marked as a priority for the team. First and foremost, our ability to deliver features with consistent design was not good. Secondly and related, the design team and engineering team spoke in different design languages. Meaning our engineering team were being slowed down due to having to translate the various design elements into their code based language.

Deliverables

Design tokens, component library, automated code updates, shared design language

Other contributors

Engineering, Marketing, Dev Ops, Product

Lead Product Designer

I led this project from start to finish. I aligned team members and stakeholders from across the business on the importance of the project. I researched some of the best design systems in the world and progressive methods like token based systems. I worked with multiple contributors to ensure we had a design system that met our immediate needs and the future needs of the business.

Create a single design language for Aktiia

The team wanted a single design language shared across the company. We required a design system to ensure consistency across all product experiences and that could scale as more product verticals were added to the company. Eventually the design system would be utilised in the marketing website where applicable.

Problem statements

• Software and Product/Design team use different terminology to describe design elements

• Inconsistent experience across the consumer apps

• Inconsistent experience across the company

• Lot’s of repeated work for design and software team because there are no reusable elements or components

Objectives

• Single design language across the entire company

• Shared method of managing design elements between the software and design team

• Create a consistent experience for our digital products

Stretch goals

• Empower the entire company to utilise our design system in all design aspects

• Create a design system that can be automatically codified and launched for the engineering team

Researched design system best practices

One of the objectives of this project was to set up the team for success now and in the future. For that reason I conducted some research in best approaches to design systems. I studied design system best practices and investigated popular systems in the design industry.

Understanding the design token approach

What some of the most popular systems had in common was that they were in the process of or had already moved to a token based approach. A little bit more reading helped me discover that this approach originated from a piece of work a Salesforce Designer had completed.

The design token approach had become so popular that the group, Design Tokens Community Group, had been formed to standardise the philosophy and method in which design tokens were implemented. This is how they described the design token methodology.
‍

Design tokens are a methodology for expressing design decisions in a platform-agnostic way so that they can be shared across different disciplines, tools, and technologies. They help establish a common vocabulary across organisations.

We chose a token based system approach

The team is small so we required a workflow that would require as little ongoing input as possible. This meant taking advantage of a token based design system that could automatically be translated into native code for the software team.

We utilised a workflow spoken about in design communities where Token Studio translated our design system into a language that could be converted into native code by another tool called Style Dictionary.

The design system was codified and automated

I worked with our Dev Ops team to create a solution that would build the code automatically as our design system was updated in Bitbucket. Our front end engineers could in turn pull the updated code into the native app files.

This was exciting because not only could we generate our design system in our current native applications, we could also generate the required code for our new web app and marketing website. This was a stretch goal we had for the project that we essentially got for free!

The token structure

In order for the token system to work, the naming convention had to follow a strict pattern dictated by Token Studio and Style Dictionary. Our system included 2 levels of hierarchy. The first level is called Global and was where “raw” style values were given categories and names to define them. The second level is called Alias. This is where styles were given more meaningful names and purpose.

Building components

Now that we had a systematic approach to applying styles, the next obvious step was to build the components that would be utilised to create screens in our applications.

I had already started building the components in Figma using Brad Frost’s Atomic Design methodology. This was a well defined and commonly used method of creating hierarchy and levels of complexity in a component library. We also wanted to utilise a similar naming convention for our components so that we again had a shared language with the software team.

Sharing the components became even easier with Figma’s new Dev Mode which provided a playground to visualise the different states of a component.

Slow rollout

The design system codebase sat separately from the native application project files. This meant that we could slowly roll out the new approach to defining styles in the apps without breaking anything app wide. This approach allowed us to fix any issues we had with the design system as we discovered them.

Lot’s of learning

The design token methodology was new to a lot of the software team. And therefore it required some coaching and assistance in the beginning before implementing features became second nature.

This methodology was also completely foreign to the company outside of the design, product and software team. We would need a clear and simple approach to coaching the team members outside of that group.

Communication and delivery increased dramatically

Although we initially had to go slower, the end result was a much faster pace of delivering features for the consumer app. The software team were now empowered to implement features without constant back and forth with the design team.

We also empowered the design team with access to the bitbucket repository to add new token styles to the system when required. We had a change request workflow which meant that communication between the software and design team was at an all new high.

Documentation

We had documented the design system tokens and methodology but not how to utilise the system. If we wanted company wide consistency, we would need to create some education and provide our time so that our colleagues could reap the benefits of the Aktiia Design System (ADS).

Figma’s new Variables feature

Shortly after launch our design system, Figma launched a native approach in their app to create tokens called Variables (I know, awful timing). The next step would be to test the robustness if their native implementation to see whether it would fit our needs. If yes, then the natural progression would be utilise their functionality to reduce reliance on 3rd party tools and libraries.