AXIS: Design System

Throughout some rapid development cycles, challenges emerged regarding the synchronization between design documentation and what was implemented. Time constraints often hindered designers from reflecting changes between the design documentation and the final product.

This discrepancy gradually led to knowledge inconsistencies, creating ambiguity regarding the product's out-of-the-box offerings, posing challenges for both sales teams and service designers.

The problem

Source of truth
The design documentation became misaligned over time with the front-end apps.
Lack of clarity
Created confusion for sales and solutions on what is available out of the box.
Outdated codebase
Contained functional and visual inconsistencies between platforms.

Users

Service Design and Solutions

Utilising figma’s robust set of functionality such as properties and variants, allows service design and solution teams to quickly apply a clients branding.

Allowing them to produce mock-ups for various scenarios effortlessly.

Product Designers

The Design System will be utilised as a framework for creating any new features.

Ensuring consistency and saving time by allowing designers to quickly create and re-use components.

Providing more time to create solutions than recreating and verifying existing functionality and components.

Developers

Developers will use the design system as a reference point for the AXIS code re-write. Translating over the established token system to allow a smoother design to development transition.

The design system will also contain spec sheets where needed to help guide developers, QA and project managers in the finer details of each component and template.

Goals

Reduce time for developers to reskin apps for clients.

1

Reduce time for designers to produce mock-ups for clients.

2

Reduce confusion about what changes are possible without further “customisation” of the apps.

3

Improve consistency of the apps without introducing too much dev work.

4

Approach summary

Plan of attack

In the early stages of planning the design system, we decided our focus should begin with the responsive web app.
The platform covers a range of breakpoints, including desktop, mobile and tablet sizes.
Most of those components would translate over to native iOS and Android platforms. Followed by completing TV designs.
This approach would also allow us to work out the structure of components built within figma on the most complex platform first.

Striking a balance

Utilising Figma’s robust component functionality, it was important to determine a balance of flexibility, but also ensure the components don’t become so complex that they’re difficult to understand or update.

Documentation

Utilising Confluence and Jira, every page template had a detailed outline of all expected adjustments as well as their original values.
This provided support for developers during the code re-write, product owners and managers in writing accurate tickets and QA with a reference for testing.

Early-Access

Providing early previews to the wider design teams within the company was a fundamental part in shaping the design system.
Gathering their feedback and building a mutual understanding was a fundamental step in ensuring we spent our time wisely.

Tokens

As my focus was on the general creation and structure of the design system. I didn’t have capacity to work towards providing a solution involving tokens. However, I worked alongside the lead and senior designers responsible.

Learning and understanding the range of complexities involved in utilising tokens in such a robust white label product, compared to an in-house product that would use them lightly.

Outcomes

Case studies

AXIS: Hero Carousel

2023
Creating a hero carousel component for a multi-platform service.
More info

MTRIBES: Recurring Schedule

2022-2023
Updating existing functionality to solve client pain points.
More info