Sector Finance |
Challenge Our design team had had to live with working in individual project files, with components scattered all over the place and no shared library. Now that we had a shared team account, how could we structure our first Figma-based design system? |
Working alongside One other UX Designer for web, five other designers for the wider system |
My Role Workshop facilitation, design system strategy, UI auditing, component and variant creation, interaction design |
Project completion date Web design system launched January 2022, development ongoing |
In the beginning...
In the beginning...we didn't have a team Figma account.
When I joined the Bank, everyone was working in their own individual Figma accounts. We copied and pasted components between different files - and of course they morphed along the way. It had become murky what the real source of 'truth' was.
Many platforms, many buttons
It didn't help that there wasn't only one platform at the Bank, but four:
Website
Onboarding forms (via Salesforce)
Online banking (with both Retail and SME using different tech providers and components)
Mobile app
Then there was the Co-op sub-brand smile, which is almost a theme of the main Co-op Bank brand.
None of the development teams shared a code base, and the designers hadn't had a shared space either. This had left us with a staggering inconsistency of basic components. We didn't have one button, we had many buttons. And the buttons we designed in Figma didn't look much at all like what ended up on the website.
How to untangle it all?
Setting up the structure
Then, a month after I started, we finally got gifted a team Figma subscription.
After we got over our excitement, we asked - how do we structure our system? How many files do we even need, and how should they work together?
This took a while to figure out, and we had several long discussions on how to deal with it.
I hosted a workshop on how we could group components, based on the principles of Atomic Design. We tried to pinpoint:
the components that were unique to each platform
the components that were shared
how components might nest within each other into atoms and molecules
Learning point
It was useful to see how much overlap there was between our platforms. But I don't think I was asking the right question with this workshop.
The problem wasn't necessarily that we didn't use any of the same components, just that a lot of our core components just didn't look or function in identical ways. The basics like input fields, checkboxes, alerts and buttons had big inconsistencies between platforms.
So we set up our initial file structure. Our Daly Core file would store all our platform-agnostic styles like:
Colour
Typography
Logos
Spacing
Icons
This Core file would nest styles into all platform components. We would have a 'Daly Mobile' file for the app, and a 'Daly Web' file for the non-app based platforms (online banking, the Salesforce forms and the website).
At this stage, it felt like the real outlier was Salesforce. Since it was an external platform, should it be conforming to our design system? Or should we be compromising with something that we had less control over? And where should its components live?
A diversion
It was at this point where I got fixated on how our design system approvals process and rollout strategy worked. I had seen Content Design release a strategy document for their part of the design system. I became convinced we needed something like that too, and began drafting and pushing for one.
In hindsight I think I was searching for some clear direction or vision for what we were doing. In the end I succumbed to some gentle and kind persuasion from the rest of the team that I might be overthinking things.
Learning point:
When I don't trust or feel like I can control a process, my energy can sometimes become fixated in a far-off stage of it. At that point we weren't even close to needing an approvals process for the design system. Partly because we didn't have a system yet, and also because we are its guardians and trusted to make good decisions without too much oversight. I wish I could have trusted myself more with that knowledge.
A deep dive into the audit realm
Trying to merge components or solve inconsistencies as we went wasn't working. We decided as a team that, rather than trying to change anything just yet, we'd start with an audit.
I spearheaded building an audit table in Daly Web. Me and the other website designer hunted for components in all the project files we could find. Our audit file had an alphabetised list of common components that grew as we found more. This included Salesforce and online banking components as well as web ones.
Auditing and refining
We then began to work through these components one by one, moving them into an audited space.
Our legacy components were static, built before auto-layout using spacers. We had to reconfigure most from scratch, using the tick-list that I made for the file.
Moreover, I made sure that the components were as true to life as possible, to better serve our prototypes. I was looking at the public website the whole way as a reference point. I built responsive variants for different breakpoint sizes. I also cross-checked and updated components which had gone out of date, like the header and footer navigation.
Splitting the files out
One of my main mistakes was thinking that it was better to have everything in one file.
I wanted one source of truth, and to be able to compare and contrast components across platforms. So, for a while I advocated keeping Salesforce, website and online banking components in the same file.
I worried that if we split them out, then:
Components would continue to diverge in style and usage patterns
It would be more difficult in the long run to merge them if we couldn't keep them side by side
Divergent naming patterns would proliferate. We would call the same component different things in different files.
But eventually colleagues convinced me that we should split out components further into:
App
Website
Salesforce
Online banking
This has been a good call. Not only are the files clearer and easier to use, but also it hasn't had the detrimental impact I worried about - at least so far.
Outlining in-production inconsistencies
As we'd been auditing, I'd started gathering more detailed notes on the inconsistencies between design and production. Even though we haven't been able to resolve these yet, I hope they serve as a useful resource to prioritise changes on the website, for greater consistency between design and dev.
Refining the final version
I was responsible for Daly Web, and decided to launch this one first before Daly Salesforce. There was still too much to sort out there.
Before launch, I met with the product owner for the web development team. I walked them through the UI kit, and they outlined:
Which components had been designed but not built
Which components had extra variants we didn't know about
Where some of the most glaring inconsistencies between design and build lay
I extracted any non-built components into a draft page and hid from publishing.
The PO confirmed that we had covered all the components available for the website. This had been our initial goal, so we were delighted.
The internal launch
I decided to do a proper internal launch with all the UX Team, including Content, Research and Optimisation. There I ran through the entire components set one by one, along with use cases and constraints. A colleague was there to give a tutorial on how to pull these assets from our main libraries and how to customise them.
Because of what we've been able to achieve, Optimisation are considering switching from Photoshop to Figma in order to speed up their workflow using our optimised components.
Overall I'm very pleased with the progress we've made so far.
What could still be done
Launching this first draft is only the beginning. We could concentrate on so many things, but are currently prioritising:
Consolidating core component designs across platforms and ironing out inconsistencies
Creating better usage guidelines on Zeroheight for all components
How we design new components and what our criteria for inclusion is