Prisma libraries
Truelayer's design system
Back in 2019, we started really focussing on creating TrueLayer's design system. A major part of that was of course our asset libraries. This was to be brand, product and code.
The other part being the documentation which you can read about by clicking these words. Or check out why documentation really matters and my experience building TrueLayers design system.
I'm just going to focus on the UI libraries I and the team worked on. I will do my best to shove together 3 years of work into something readable. I'm sure I'll miss a whole lot.
When I joined TrueLayer, there was the bones of a component library. This was on Sketch which we'll get to later. But the team I joined were a great team and they cared about consistency and the importance of scalable design. However this we were a small team with a huge tasks, these things fall by the way side. Which is one of the reasons the team was formed.
Where to begin?
This was a few years ago and I didn't think ahead to write all of our processes for future references, I'm sorry, but here's how we got started on our new design system
Audit - We pulled together every style, every component, every screenshot we could.
Sort the mess - We took the audit and compared UI, shook our head at inconsistencies, discussed future direction and the like.
From scratch - We decided as a team it made more sense to start from scratch, rather than creating a Frankenstein library, we would create the library we wanted and what worked best for us as a team (development included)
Later Sketch, Hi Figma - Because of this we looked at tooling and decided to start using Figma. We did a lot of research, and spoke with a lot of people at the company, not just designers, and decided we would create our new library in the young and exciting Figma
More organising - TrueLayers products are simple yet also complicated. To simplify months of discussions we decided to create themes. Based on the audience of the product. For example out main product is used by developers however we also have screens that consumers use. These have a different visual approach but we wanted to keep the same UX patterns and structure.
Unblocking designers
Another thing to keep in mind, was our designers were asking for libraries and work wasn't stopping to let us spend months creating our fancy new components. Here's another handy list of things we did to get it going:
Prioritisation
We worked with product teams and created an exciting spreadsheet to direct our work. So we could tackle the most in demand theme first, and then the components within that theme. This was based on company need, usage and difficulty.
Rebuild
We also decided in this initial version, we would recreate what we already had without any major sweeping changes. This was to create alignment for the designers and product (we did't want a library too far ahead of our live product) and also to unblock designers. This way they could start using the component library right away without causing a headache for their developers.
Below is a small group of components for the Developer and End user theme. We currently have 6 themes, which is adds a lot of complexity. Something I'm looking to resolve this year.
This was not a quick fix or something that was created in a few months. Any designer would (should) tell you, design whether UX or UI evolves. It's no different for component libraries, we have to keep evolving and experimenting and helping our internal users and de facto users.
Personally as the team changed and I took a leading role on managing the design system I realised there's much more to it than just creating UI libraries. It's much more ambiguous and takes a lot of effort. You should be the source of truth, the lamp light for not just design but experiences. Making sure teams are aligned, not just on visuals but user experience to, but you cannot shackle experimentation and creativity for the sake of a clean unchanged design system.
The majority of my time is assisting with the execution of design. The goal of a design system is to elevate experience design. Whether thats product, brand, copy, code. It doesn't matter.
Of course there are deliverables:
Figma libraries
We are product designers for designers, so our designs are just like any other. They need to be easy to use, scalable, well built and have a good UX for their users. These have changed a lot over the past few years, since Figma has released some great new features, every time we have to make sure our components are up to date and built in the best way. Saving hours of designers time.
Documentation
I spoke about this already on Prisma docs, but it's vital designers have clear documentation, that is easy to follow. We also created in Figma guides (some examples below) so designers didn't need to visit our documentation every time.
Collaboration
Maybe not a deliverable but just as important. Collaboration and communication is key, always being available for review, updates and feedback. I try and position the team as the experts on TrueLayer design whenever possible, our job is to keep that quality high across every product, every screen.
We recently had a rebrand so there's lots going on in our team, trying to update, realign and improve our products. We are also introducing design tokens since Figma introduced variables, this will make our lives much easier...eventually.
As always, on the face of it everything seems simple, we don't have to do large user research projects or worry about tight product deadlines. However we have to consider the structure, the core foundations of multiple teams and products, trying to align everyone from brand to development is never easy.