2019 - 2024
The Problem
The world moves fast, and businesses need to be agile and malleable when it comes to creating new experiences - design systems are a key component of this. They need to be robust, creative, integrated - but ultimately practical and scalable.
The Challenge
Understanding how a design system and component library integrates into a project, and with the culture of an organisation is key to the chosen approach.
Over the years, I've been involved in various design systems at different levels - the main challenge has overwhelmingly been (as well as creating generally great, useable, accessible UI) understanding the business needs and scoping the design system/component library appropriately.
The Solution
Through my time at EE, Jugo, and Nearform, I've been involved with large scale, enterprise level systems, as well as directly implementing smaller scale startup style libraries.
The key differences are explored in more detail below, but in short:
EE - large scale, slow moving, requiring much greater levels of oversight from a full team and extremely moderated changes to ensure consistency of look and feel, as well as functionality
Jugo - a need for a fast-moving, agile library to deal with new user patterns and UI locations, product pivots, and rebrands, working closely with engineers to stop disruption to BAU work
Nearform - creating a 'the same but different' library for a specific application, using elements from the parent organisation while maintaining some individuality to appease internal stakeholders, as well as adequately support the intended app function
All of these systems, particularly Jugo/Nearform, are taking advantage of the most up-to-date features in Figma, variables, component properties, and a concerted effort to make useable, malleable components for other designers to pick up and use day-to-day.
The results
Overall, design system adoption has been varied - the nature of the business really dictates how much development and effort is required and it's important to gauge this at the very start of the process.
However, universally these systems (and by extension my work on them) have helped to increase design efficiency and output, removing steps from ideation to high-fidelity where appropriate, guiding brand new design where required, and consolidating and preparing businesses for future design iteration.
Design Systems and component libraries
Closer Look
Jugo
Understanding the business
When I joined Jugo, the theming of the app was in disarray - for designers and engineers. Due to a breakneck early development and a focus on the 'in-event experience', the app had multiple different themes depending on where you were, with the 'in-event' and 'pre-event' experiences having entirely different aesthetics.
This made it extremely difficult to edit, and building a bespoke experience for this new technology was an uphill struggle.
I quickly began implementing an entirely new component library, partially to make our in-flight work simpler and more coherent, but also to align our experiences from end-to-end.
Starting from scratch
The first step in creating a new library is to implement the branding in styles or variables, often referred to as atoms. In the case of Jugo, branding was very undecided, with little thought or effort at this point, so branding was kept simple on the surface, with fairly minimal accent colours in order to ensure a minimum of AA accessibility in all existing states. It was understood that a rebrand was on the cards, and this thinking was brought into the structure of the library and implementation of colour.
Similarly, the typography scale was kept as straightforward as possible within the prescribed formats (albeit with updated line-height to ensure conformity to a 4px vertical rhythm) with set styles to ensure legibility, and preparedness for change.
Building components
When building the components themselves (or molecules), my initial focus was creating a single source of truth for designers and engineers, to replace the somewhat random approach to functionality from the early days of the project. This was prior to the release of Figma variables, so I made use of styles, component properties, and nested instances - this helps to keep things easily editable while covering required functionality, and giving the team useful tools to build from.
Using the button component as an example - we were building on top of Material UI already, and this wasn't about to change, so we had a set style and spec to work to when consolidating. In brief, the structure was:
Core button component controlling absolute base styling - styles, border radius, structural positioning of elements like icons/copy
These were nested into containers that controlled the layout options
These were nested into containers and then overridden with new styling for secondary and tertiary variants, as well as dark mode and sizing for all content variants
Final component had relevant content and instance swaps elevated to the top level for ease of access.
This was the most comprehensive and stable way to achieve this versatile a component at the time - however these types of components are heavy, and can be a little unreliable when pushing updates due to the slightly unpredictable nature of Figma overrides. As shown below, there are hundreds of variants - and while updates are fairly simple, it's a complex machine.
Variables and leaner components
The introduction of variables meant a much simpler approach was unlocked within Figma, that could be much more closely aligned with the eventual final product in code.
All atoms were migrated to variables, which at the time meant colours mainly - however, the core colour set could be created and then referenced as light and dark modes for specific component parts, meaning that any changes in the core brand could easily be reflected across all designs using the system.
I also created a new numbers system of variables, core measurements in 4px increments, which would allow us, through referencing, to change the sizes of various different structural parts - with specific new sizing modes for different classes of component.
Using this system on our example button component, I was able to reduce the number of component variants from 484 to only 11, without losing any functionality. This supported all the sizes, variants, states, and layouts of the button, with light and dark mode, completely editable.
This approach was applied across the component library, with all spacing and styling making use of references where possible (this was prior to the release of text variables). The use of variables increases the compatibility with the codebase, allowing for easier parity with implementation, and, once implemented, use of sematic naming in design tokens.
Keeping track
I also began creating documentation using ZeroHeight, in order to create a single source of truth for developers and designers to refer to - not just as a reference for look and feel, but also correct usage, implementation, and design ethos. This also would act as a stepping off point for anyone new to the team, or the design system.
We also began an initiative to properly cross-reference Storybook with Figma via cross-integration, such that designers and developers could view components and see both the Figma version and Storybook version side-by-side, and check that designs were consistent.
I would then create annotated components within the library, carrying information on usage into files, as well as links to documentation.
When we faced a surprise rebrand in July 2023, due to the nature of this strategy, there was no disruption to work, and the changes took only a few minutes to apply (not including testing and iterating after the fact), which helped with development of the brand as we could see it in-situ quickly.
The Jugo Design System was a lot of work for a sole designer, especially alongside leading feature design and managing the team, but it really paid off in efficiency and consistency of design, and helped us communicate our vision quickly to senior leadership, and give a better idea of final outcomes in a very fast-paced environment.
Nearform
Understanding the business
When I began work on the Community First Responder app for the Irish Health Service Executive, a few things were clear - the National Ambulance Service wanted to have their own identity without breaking too far from the Health Service Executive umbrella, the nascent HSE design system was still in development, and it was also not really applicable to the mobile app we were working on.
The decision was made to adopt a 'same but different' approach to the look and feel, using HSE colours and very base text styles, while adopting a more modern aesthetic that would lend itself more specifically to the app requirements. Notably, less clutter, chunkier interactions, and clear visual cues to help responders move through the app journeys easily.
Working in tandem - creating, updating, and refining
As shown in more detail in this case study, the app had a very early deadline that required some visual design work and prototyping to be completed. This helped to establish a baseline visual language and inform subsequent component updates, but also meant that rapid movement and quick iteration were extremely necessary, and waiting for updates to the core HSE library simply wasn't an option.
My initial strategy was to take their core colours, and whatever was useable from their typography structure, and apply it to the UI library our engineers had chosen as the basis for the app build. This way, the app would seem part of the family of services provided, while avoiding some of the pitfalls of glacial, large org systems. (I appreciate the amount of work that goes into these systems, but the project requirements dictated a different, albeit very considered, approach).
As the initial early deadline passed and the work was completed, we could begin refining and updating the look and feel to fall more in line with late developments in the project scope, as well as many pieces of new information from the client, technical changes from the engineering team, and myriad UX changes. It became necessary to develop the visual language further while building and updating the component library, which made implementing the same strategies I employed at Jugo even more important.
Building a system with purpose
The project had a fairly unique requirement for straightforward, uncluttered UI with chunky interactions and a clear steel thread for users to follow. This needed to be clear in the design system atoms and molecules, as it was imperative that this was not obfuscated in component organisms.
I took a more rudimentary approach for the MVP - only truly building out the components that were required - namely forms, buttons, notifications, a diverse modal component to consume custom content outside the component library, and more. I also included a few fully fledged organisms, such as incident cards, and custom user profile content.
Everything was referenced back to variables, which were in turn referencing styles from the HSE design system. Nothing new was added into the brand, but I was able to use what I could without obstructing the goals of the business and project.
Achieving a lot in a short time
This approach was a great way to create a design system that was as big or small as it needed to be to get the job done - while also completing the important project work around it. Without adding too much to the workload, the project was in a much more fleshed out state by the end, with plenty for future designers to pick up and build on without being too prescriptive or rigid. Components were powerful and robust, deadlines were met and the client was very happy with the overall output.
I'm happy to show more comprehensive detail of both of these libraries on request.