Kindred UI-Kit
Design, Architecture, Governance, Process
Introduction
I am assuming you are already sold on design systems, so I will skip that part. These tools are now commonplace, and most companies will attest to having some kind of design system or pattern library. However, this can mean different things to different people and expectations vary as to what these tools can help us achieve. Having worked within several large organizations I found the biggest failing to be a lack of common language across design and development. As we work with different tools, in different locations there will always be a discrepancy as to how things should work and how we fit it all together. In order to bridge this gap, we need a single source of truth which allows us to work with live components (what our customers see). I managed to create a design system (with a lot of help from developers) that does just that. The Kindred UI-Kit (or just UI-Kit) is now well established and used by hundreds of designers and developers on a daily basis.
Application
The UI-Kit was built around three years ago, as a result of constant collaboration between design, development and domain architecture. The system is built using a React Framework which allows us to place ‘react components’ alongside our legacy code. This enables us to migrate products according to the company priorities, without having to worry too much about tech / design dept. We move forward incrementally, improving the technical solutions and the customer experience at the same time. This also gives the engineering teams autonomy over their own products, so everyone is happy (most of the time).
Did I mention multi-brand? Oh, yes, we had eleven brands at the time this was created. With this in mind, I took the decision to introduce a ‘Vanilla Theme’. A brand agnostic approach, which supplies the 'blueprints’ that auto map to our other brands. When it comes to designing a product or experience you don’t have to recreate it ten times. You just need to specify what customisation is needed, for which brands, everything else follows Vanilla. Clever right? I thought so.
Documentation
We provide documentation within the UI-Kit itself, which tends to be more tech focused. Given that engineers are the majority of our audience (we ran a survey), it’s not a big problem. At the risk of the two sources conflicting, we also maintain Figma documentation. This includes the initial spec we provide to developers (spacing, styling, brand variants ect), as well as instructions on how and when to use the Figma components, for designers.
Helping other teams to build documentation and component libraries is an additional ‘service’ we provide. This is potentially more of a design ops type of role, but we have found it necessary to get buy in from around the business.
A lot of time and resource is spent keeping everything in sync and ensuring that our Figma files are not moving ahead of the UI-Kit (or visa versa). Designs ‘not matching the design system’ can be a hot topic and hard to manage in a large company. This is where governance and process become very important.
Maintenance
Our design system is now supported by myself, and my team of four designers. While this is not our only job, we hold ourselves accountable for its upkeep (someone's gotta do it). Allot of the maintenance comes down to what we call ‘mismatch’, this is when the documentation in Figma does not match the UI-Kit. Although we want to rely on the ‘live components’ as our source of truth, some amount of manual work is needed to ensure that Figma provides an exact representation of our design system. While you can export Figma to React, there is no way to automatically sync the web components with Figma (not that I know of anyway).
Dark Mode
As the obsession with dark mode continues, the pressure to support this feature (on web) is mounting. We have some functionality built in already, but we need to expand upon it. Ideally we would switch to tokenization (as per Atlassian), but that is not possible right now. We do have a nifty work around though, one of our developers have created a proof of concept that allow us to provide light and dark components, out the box. It also empowers developers to set their own colour for backgrounds ect. This all responds to a global command, that can be configured per product. The GIF below shows part of the initial documentation concept.
Documentation — Concept
Governance
Governance works well when people feel empowered, I aim to lead by example and allow others to build on the ‘best practice’ provided. Some individuals / teams can be resistant to following a set of rules each time they design / develop. Hosting open forums where people can speak freely and have a say on how our design system works has been helpful.
We need to get everyone on board when it comes to evolving our workflow and contributing to ways of working. This can be challenging. Product teams will often prefer to ask a central team to make changes for them, which is understandable. However, this can cause conflict if they are not placed at the ‘front of the queue’. To alleviate this issue, we now encourage teams to create their own ideas (based on acceptance criteria) and submit them for integration into the central library. This workflow is more desirable and has been successful at Kindred, although the process is ongoing and far from perfect. As with all good design we rely on communication and building good relationships, above all.