designsystem.png

Design Library

Superannuation Platform : Design Library


Challenges

I was presented with the task of developing new screens and flows for the administration platform. Upon embarking on this project, I was faced with the following challenges:

  • The design files did not use reusable components making it difficult to create new screens quickly and consistently.

  • New design components and patterns had to be created to solve for new problems. 

  • Design files did not match build. 

In order to deliver this piece of work and make it easier to deliver subsequent work it was clear there needed to be a system to improve the design workflow.

Tools

Figma, Illustrator

My ROLE

As part of my role I initiated and conducted an audit of the existing components used in the platform. 

I also conducted workshops with product managers and engineers to understand the root causes for these issues and how we could improve the workflow.  Based on the audit and discussions I created, organised and documented the design assets in Figma.


goal

The goal was to create a design library of reusable and accessible components in Figma which would be the basis for the components in build. 

Creating a design library would have a range of benefits including improving design to engineer handover and also make it easier to see what existing components we had so that we could work more efficiently. 

The design library would eventually become the basis for a design system.

“A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.” (Source: Invision app).

Component audit

The first step in understanding the scope of the problem was to conduct a component audit of the platform. 

As a result of the audit it was clear that there was a lot of inconsistency in how components were built and used throughout the platform. Without a single source of truth for components - developers and designers were doing a lot of unnecessary development and rework.

ACCESSIBILITY

As a designer it is important to advocate for the users of the platform and ensure we build an inclusive product that is catered to people with vision, hearing, cognitive, or motor impairments. 

When I joined the team there had been a pivot of the product from an API solution heavily focused on back end functionality to an administration platform interface that administrations would use to conduct their work. At this point in the development there was little thought given to how the users would interact with the platform and perform their tasks. Reviewing the accessibility of the platform raised multiple issues including around colour contrast, focus states, labelling and validation.

As a company it was important that accessibility considerations were the foundation for how we would build, design and improve components and screens moving forward.

Example of revised “teal” colour which passes AA colour contrasts. Prior to the accessibility audit the “teal” colour did not pass colour contrasts when used in copy and call to actions throughout the platform.

Example of revised “teal” colour which passes AA colour contrasts. Prior to the accessibility audit the “teal” colour did not pass colour contrasts when used in copy and call to actions throughout the platform.

Documentation

When I joined the team there had been a recent migration of design files from Sketch/Invision to Figma and developers were also referring to screenshots in tickets to build features. As a result of this a lot of interactions and components were inconsistent due to the lack of documentation and uncertainty of which design files to reference. 

Using Figma it was easy to comment and annotate directly on design files so that Project Managers, Quality Assurance and engineers could see supporting information about a component/interaction while also inspecting the designs.

It was also important that different departments were speaking the same language and using the same terminology when it came to components in order to improve collaboration and communication. I worked with engineers and project managers to determine how we should name and group components in the design library.

Example of button documentation.

Example of button documentation.

Example of components and their states.

Example of components and their states.

NEXT STEPS

The design library is a living system that is forever being added to when new components need to be developed. The next steps that would add value and extend the design library would be to:

  • Develop a design system using the design library as a starting point - components built in code rather than static designs. 

  • Deliver value incrementally by focusing on creating/improving components that are used often and for important tasks.

  • Review other aspects of design such as tone of voice and design principles to help guide designs.

TAKEAWAYS

The creation of the design library took a few weeks to create. The approach we undertook was to focus on the designers as the main users. Focusing on one user (the designers) to start off with allowed us to prioritise work more effectively in order to deliver along with other priorities.

The design library solved a key problem for designers as they had a library of components to use in their designs making it easier/quicker to mockup screens. By optimising and improving internal workflows we were able to focus on solving more meaningful problems for the user.