The Challenge
Akari operated without a design team for almost a decade, resulting in a very loose approach to UX and UI that relied on one-off solutions from various stakeholders. The company added features without a comprehensive design language or documentation, resulting in a mix of fragile, inconsistent designs with similar functionality. This made it difficult to keep track of implemented designs and make changes. Without a cohesive visual design language, the only consistent element was the typeface.
Atomic Breakdown
In creating the design system, it was very important to build it on solid foundations. Atomic Design principles were at the core of how the design system was started. Start with the small pieces with big influences - the colour, typography, spacing, and icon style. Then create the components from those.
'EPIC' Jira Story: Design System
When I joined the project, a UI Guideline had already existed based on Material.io. It was a good foundation, but it required tweaking to tailor it for the product's needs. The project was extensive, and needed buy-in from various stakeholders in order to invest the time and effort that would be involved in making this a priority for the organisation.
I laid out a plan and broke them down into several different tasks which would all take significant time and several sprints to complete. These tasks were done in 3 phases - the 3rd being a repeatable process for adding new components:
PHASE 1 - Research
Design System Research (Atomic Design, general good practices)
Accessibility Research (WCAG Requirements)
Product UI Audit
Accessibility Research (WCAG Requirements)
Product UI Audit
PHASE 2 - Foundation Building
Track Branding Details and Style Exploration
Document Grid System
Research Accessible Product Colour Options
Systemise Product Colours and Neutrals Systemise Typography, Spacing, and Drop Shadows
Audit & Systemise Icons
Document Grid System
Research Accessible Product Colour Options
Systemise Product Colours and Neutrals Systemise Typography, Spacing, and Drop Shadows
Audit & Systemise Icons
PHASE 3 - Component Building
Requirement Gathering
Analysing Wireframes
Identify Component Properties and Requirements
Compare to Existina Components
Design New Component
Review New Component
Collaborate with Devs in Speccing Component
Documentation of New Component
Integration to the Product
Analysing Wireframes
Identify Component Properties and Requirements
Compare to Existina Components
Design New Component
Review New Component
Collaborate with Devs in Speccing Component
Documentation of New Component
Integration to the Product
Aligning Use of Language
When implementing the design system, the lack of appropriate names for different aspects of a component became apparent. To help bridge the gap between Designers and Developers, as well as other stakeholders, Attributes (a.k.a design tokens) were outlined in the document produced for the Design System. This helped in communicating design decisions and better improve the communication around components in a granular level.
A very simple example is that some people call a button, a CTA, a button, or an action. Often times, discussions around a component can get quite detailed and problems can start to arise from miscommunication. From this observation, I found it important to highlight the 'Anatomy' of a component, like the one below, showing the different variables of a button.
Component Breakdown
XD lacks the ability to communicate responsiveness to various screen sizes, which is a crucial element for design flexibility. To improve the hand-off process from design to development, component breakdown was introduced as a means of communicating this aspect. It has also proven to be a valuable documentation tool for component behaviour and attributes.
Retrospective
A design system is like a living organism in that they are complex and are constantly growing. Adopting the system enabled the team to rapidly prototype new features, improved the onboarding process for new designers and developers, as well as speeding up the handover process.
Something important I learned throughout the process is that it's very important to recognise what is required by the company and also its limitations. Akari's design system is different from others because it's quite tailored to the needs of the company. For example, the information contained in the system is mostly intended for Developers because the system is currently at the creation stage where the Devs are still implementing the components. I
can see it grow to accommodate for other stakeholders within the company in the future.
can see it grow to accommodate for other stakeholders within the company in the future.
