Creating a Design System for Banking — Things to think about before you start
This post is the first in a series about the Lloyds Banking Group Design System.
If you’re looking for the specifics of implementing a design system, check the ‘resources’ links at the bottom of this page. This post highlights some of the managerial challenges we encountered during the ‘Discovery and planning’ phase of our design system rollout.
At Lloyds Banking Group product teams often designs customer journeys for 3–4 banking brands in parallel - once for Lloyds bank, once for Halifax and once Scottish Widows etc… delivering all design and code assets simultaneously.
Understanding and applying 3 or 4 different design languages is challenging and receiving a bank wide email along the lines of, ‘Can anyone tell me where the latest version of a Halifax calendar picker for public websites is?’ Became an almost daily occurrence.
Having a team and system to promote consistency, reduce build time and increase end-product quality became a priority for Lloyds and once the newly formed ‘Design Operations’ team had been given the green light, our early time was spent on:
- Trying to understand which design tools we could use in a secure banking environment.
- Creating a snapshot of the banking various brand landscapes — People, products and platforms.
- Developing terminology everyone (not just designers and developers) understands.
- Finding a safe space to make mistakes and have difficult conversations.
- Sharing our progress via a dedicated Wiki space and weekly emails
1.Trying to understand which design tools we could and couldn’t use in a secure banking environment
If you’ve ever worked in a bank you’ll know security is everything. You may also know that any system that pulls or pushes data to the banks servers will undergo a good deal of scrutiny before approval, same goes for any system which stores design assets.
This meant ‘on-the-fly’ experimentation with Invision, Zeplin, Sketch libraries, dropbox or any cloud hosted software was out of the question for our MVP. It wasn’t impossible to use these services but if we wanted to live the MVP ‘learn quick, fail fast’ mantra, cloud hosted software was a potential blocker.
To save time, we instead chose to focus on solutions we could develop internally by utilising the tools that had already been approved. To get us started we decided on creating a simple CMS to manage our online styleguide, leveraging the pre-approved wiki software ‘Confluence’ for pretty much everything else.
2. Creating a snapshot of the banking landscape
Mapping people, products and platforms during the discovery phase paid off big in the longterm. In an organisation as large as Lloyds Banking Group there’s a degree of complexity in understanding who was responsible for which products and how those products were maintained and related to other offerings.
Creating documentation to explain the ‘landscape’ to new team members and isolated parts of the business helped ground us in the size of the challenge ahead. It also proved a useful tool in building relationships with stakeholders as we conducted 1–1 interviews and workshops, learning more about the challenges facing each product.
3. Creating (and sticking to) language everyone understands, not just designers and developers.
Design systems, style guides, UI toolkits, atoms, molecules and organisms . If you’re not regularly exposed to the nuances of design or development, understanding the difference between these concepts is not easy.
We had to canonise our terminology and educate stakeholders in plain english if we ever hoped to succeed. Creating a glossary helped break down language barriers and kept us all on the same page.
4. Creating a safe space to make mistakes and have difficult conversations
Failure is a important step in learning something new. It’s also a word no bank wants to be associated with.
We learnt that sometimes it’s valuable to expose our ‘fails’ to colleagues and other times its best to consider them as a team and move on (….shhh!).
Knowing when and how to do this meant creating an environment that gave us the flexibility to choose when to share. Over the first few months of the project, the Design System team floated from Lloyds Customer Experience HQ to a separate office in WeWork. Here we could openly discuss the strengths and weakness of every visual language, invite colleagues over for private discussions and gained focal point for the project, very useful in a busy hot desking environment.
5.Sharing our progress via a dedicated Wiki space and weekly emails
Setting up a space to share our ‘brand landscape’ maps, newly refined design system terminology and weekly movements helped us keep in mind the community we were serving.
Documenting our processes in a central location opened up channels for new conversations and also brought a degree of transparency that would eventually develop into a principle for not only the Design Operations team but the whole digital production effort in the bank.
- Try to map out any obvious limitations and design around them, always bearing your main goal in mind.
- Communicate in terms everyone understands and create centralised support docs for the complex stuff.
- Get a war room — Having a safe space to make mistakes was more important than we initially thought.
- Communicate with with your ‘users’ early and often. Break down silo’s and build relationships that you may be too busy to engage in, in a later phase.
Check out Marco Lopes medium post on setting up a design system. Marco and team leverage sketch as the heartbeat of their new system and he does a great job of explain the methodology behind each team decision.
Mariah Muscato details the principles and processes behind hubspots new Design system ‘Canvas’.
Fabricio Teixeira comprehensive list of design system articles, videos and references is sure to help boost your products chances of sucess.
Illustrations thanks to Pablo Maroñas