Sector - Staff duty of care
Timeframe - 3 months + ongoing
Deliverables - Component & pattern library. Documentation & guidelines.
Having inherited a partially complete design system with little handover, inevitably over time we would experience more and more design/tech debt. Slowing decision-making, reducing visual consistency, and an increasing proportion of bugs from each product release. It was clear - for us to remain agile - that we’d need to address this sooner rather than later.
With the company undergoing a rebrand led by the Marketing team, it was the perfect time to propose a design system overhaul. Including the new logos, colours and typography to boot.
With the help of Janis - a freelance designer helping as an additional resource - we teamed up to create a brand new library from the ground up. In which time, the company had taken the decision to start rebuilding the product on a new tech stack, which our new system would be applied to.
I started by conducting a full audit of the current apps (web & mobile). The aim was to find each and all permutations of the components to understand the use cases they were serving. This provided the basis for understanding what should be consolidated or removed for simplicity. It was also an opportunity to think of other relevant use cases which weren’t accounted for in the current designs. Only very typical ones mind you, as not to over-engineer, but in an effort to help ‘future-proof’ them.
.png)
The product had recently undergone a rebrand, handled prior by an external marketing agency. So we had an already agreed set of guidelines to work from which included colour palettes, typography etc.
.png)
These guidelines were more than sufficient for creating marketing content, however in the context of application design, we quickly identified a number of issues. After experimenting by playing with and applying to existing components.
I experimented by playing with different variations of the new typography and colours, to see how they might apply to existing components and pages. The key problems were:
.png)
All in all this wasn’t workable, so I proposed to explore some alternatives for the team that could work as a compromise. I built out a new colour palette based on the same core colours, and scouted for similar typefaces. The key was to strike a balance between consistency vs. the pre-agreed guidelines, and enough versatility to form a basis for the design system.
.png)
This just highlights the importance of making sure to engage all key stakeholders, particularly when it comes to projects that the business has invested significantly in.
Another important step before diving in was to run our plan by the engineering team to understand what limitations or preferences they might have. We discussed some of the existing UX patterns and how we could approach them differently. For instance opting for side panels (to contain information and interactions) rather than overlays. This was for a number of reasons, one being they are simpler to manage on different screen sizes.
Also, with the platforms written in React, this was a consideration as to which design systems we’d draw most inspiration from as part of ideation. This would help expedite the development process, knowing certain components (and their interaction behaviour) had already been achieved with the same frontend language.
We approached this using the Atomic design methodology. A tried and tested way of building complex systems with modular pieces (or ‘atoms’), that can be easily reused or combined to create larger entities, referred to as ‘molecules’ and ‘organisms’.
With 40+ components to design (for Web alone), Janis and I started to make our way through them. As this was essentially a side project, it was important to have regular reviews in the calendar to not only give us a chance to improve on each other’s work, but have a consistent weekly deadline in the diary to help keep good pace and momentum.
Each component needed careful consideration, accounting for the multiple variations and states to handle the current use cases. Not only that, but for likely future use cases as well. I cast the net far and wide for inspiration across many well-renowned systems. With particular focus on those which were built for similarly complex B2B SaaS products. E.g. Attlasian, Carbon (IBM), Lightning (Salesforce) to name a few.
Components were categorised in terms of their function, for instance Navigation, Messaging, Data Visualisation etc. As we were adding to the collection, we could begin stress testing them together to see how cohesive they were, and iterate accordingly.
Usually thought of as the ‘boring’ part, documentation is incredibly important for the longevity of the design system as a whole. I learnt this the hard way, having inherited one without it.
Documentation gives a central source of truth to speed up the decision-making for designers and developers as to how they should consistently implement a system. Keeping maintained, it will evolve over time, so can live across teams with personnel changes, providing value well into the future.
Being the first iteration, we didn’t want to over-engineer anything, so opted to include the key elements:
With the build phase in motion - a significant part of the process was in the hands of our trusted engineers to bring to life. Once implemented, it’s up to the Design team to lead the focus of maintaining the health of the design system.
I’d learnt first hand - particularly when workload intensifies for the team - how standards will naturally erode without a framework in place. So aside from individual component and pattern documentation, there should be some guidance on:
This could be more exhaustive but again, with the realistic time and resources available with the current team size it’s important to not over commit to something that isn’t feasible.
