Declining appeal of AXIS to new clients due to the increased time and costs of developing new apps. This was a result of:

1. Outdated and inefficient codebases with significant inconsistencies across platforms.

2. Available design files out of alignment with front-end platforms.

3. Confusion about what changes are possible out of the box without costly customisation of apps.

There were two key user groups of the AXIS Design System:

1. Client-service designers and developers: who will use the design system to build client apps.

2. AXIS product designers and developers: who will build and maintain the base design system.

We conducted kick-off sessions with key users in these groups to understand the issues they were facing and their expectations of the new design system. They were:

1. Consistency: Component and style structures should be consistent across design and development.

2. Efficiency: Centralised styling and components that can be reused in many contexts.

3. Speed: Minimise time spent skinning apps, so the focus can be on customisation.

4. Clarity: Clear understanding of what changes are possible without customisation.

Build a robust and consistent cross-platform design system to reduce design and development time by increasing consistency, skinning efficiency and reducing confusion around what changes are possible without customisation.

Following my promotion to Senior Product Designer in February 2022, I was given the opportunity to be part of leading the direction of the design and structure of the new AXIS design system. I was responsible for determining the best approach for laying the foundations and managing the direction of our design work across all platforms.

I determined our best approach would be to build each platform's components sequentially; starting with responsive web, followed by native mobile and finally TV. The latter two platforms would be based on the components and styling of their closest RW breakpoint to ensure the cross-platform design consistency needed by client-service teams. These components would also be referenced by AXIS product team developers in their rebuild of the AXIS reference apps.

To establish a baseline I audited the existing responsive web app, documenting the inconsistencies of the following:

• Colour and Text styles and usage

• Global grid and breakpoints

• Row component item counts and layout changes across breakpoints

I then simplified these and set up a basic set of foundations for us to start building out components with; design tokens would come later, as further exploration was needed to determine the best approach.

When building components, our goal was not only to create an efficient component library for designers to quickly create mockups, but also to ensure that the component structures and functionality was closely aligned with their front-end counterparts.

This required adding detailed properties on Figma components to enable designers to configure them for specific scenarios, whilst minimising breaking component instances and risking inconsistencies. Maximising the reuse of global and sub-components further reinforced design consistency and skinning efficiency, which could then be reflected on the front-end.

A designer can assume that if their changes requires significant time and affects other components, it may also require costly customisation in code.

There are three levels to the AXIS design system. In order of hierarchy:

1. Foundations file: all global styles and variables for use in components files.

2. Components files: one for each platform group, containing all platform-specific components and required sizes.

3. Page template files: one for each platform group, pre-structured pages and states for use as mockups.

With this structure in place, my attention shifted to refining our approach to design tokens.

Implementing tokens into the AXIS Design System aimed to achieve two main goals:

1. Minimise the need for developers to update hard-coded values, reducing time and costs associated with skinning.

2. Establish a clear and versatile token taxonomy following W3C specifications to streamline future adjustments and reduce ambiguity around the scope of design changes.

Creating a cross-platform token structure that functioned efficiently for a white-label design system proved to be quite a challenge, particularly for colour tokens. We needed to determine an approach that would give designers the flexibility to adjust their colour structure for any brand style, whilst retaining the same structure in code, to minimises changes for developers.

Iteration 1: Primary, Secondary, Tertiary...: Initially I chose to dramatically simplify the existing colour structures and although this would've worked efficiently for designers, it would still result in manual changes in code for any minor skinning change.

Iteration 2: Component tokens: After further research, adding another "component" level was needed. However, the level of granularity I went with was confusing to service designers and risked becoming unmanageable. The token taxonomy was also not consistent enough which added to the confusion on the usage context of tokens.

Iteration 3: Rationalised and refined: Following discussions with service designers, we rationalised some major component token groups which had become unnecessarily complex for most client use cases. Along with these improvements, the global token taxonomy was properly defined, with all token-type names now following a consistent global structure. These changes not only enhanced clarity but also would improve efficiency and consistency when skinning and customising.

The final token hierarchy has three levels:

1. Brand Colour Tokens: Full brand colour palette, adjustable without affecting code.

2. Semantic Colour Tokens: Reference brand tokens, adjustable without affecting code.

3. Component Colour Tokens: Reference semantic tokens; can be adjusted freely, however any changes or additions to the naming or structure require changes in code. Only colour tokens to be used directly in designs.

This structure combined with a standardised taxonomy ensures clarity and efficiency for any future additions, a crucial foundation for client-service teams in understanding token naming and facilitating continued improvements.

This was an amazing opportunity for me to help lead a major design project which could greatly improve design and development workflows and provide great benefit to the wider business. After being part of building the MTRIBES design system from the ground up, the scale of this project provided many learning opportunities for me, in particular: helping to manage a small team of designers, designing for a range of platforms and the value of understanding the technical side of the platforms you’re designing for.