5 things I’ve learned building the Constellation Design System
1. Community is everything ❤️
A design system can’t go the distance without the support of the community. The most enjoyable part of building the Constellation Design System has been meeting people, even for an introvert like me!
The team have run a weekly drop-in clinic for the past 3 years. I wrote a post about it here. It’s an open invite for designers, engineers and product people to swing by and share their problems. Prior to Covid we ran it in person but it’s actually been more successful over video call as folks from around the country can phone in.
We troubleshoot bugs, fix code, solve UX problems, discuss contributions and review work from agencies. I figure I’ve spent around 350+ hours in this clinic. It’s been an epic immersion in brand, UX patterns and problem solving. Common themes emerge. If you want to get to know your users and their pain points I would highly recommend an initiative like this.
As our reach grew we spent a lot of time reactively answering queries over email and chat. We clung fast to our scrappy roots but ultimately this sort of service doesn’t scale. We had a keen graduate who designed us a Jira service desk and we slowly coaxed our users to start logging tickets, rather than contacting us directly. This helped time-box requests and increased productivity. It’s also a transparent way to show tasks are being assigned and progressed.
Ermahgerd, writing positive things about Jira. Am I finally . . . a grown-up?
2. Contribution requires a dedicated herdsperson 🙋
Back in 2019, Nathan Curtis introduced the idea of a contribution shepherd. I fell in love with this idea, my subconscious conjuring a be-robed herdsperson, moving complex components across the rich mountain pastures of Andalusia.
To become systems-approved and ready for release, a component needs the work of many specialisms; research, interaction design, conversation design, visual design, accessibility and engineering. We considered three routes:
- we only accept complete components
- we accept incomplete components and the design systems team undertakes the work to get the component into shape
- we accept incomplete components and shepherd the community to make the component production ready
We opted for the third approach, keen to act as curators. If the system only accepts complete components, everyone misses out on valuable insight, thinking and ideas that may not have made it through to a finished component. If teams can contribute just part of the process, other teams can potentially pick up where they left off and benefit from their learning.
We published our contribution strategy, some straightforward acceptance criteria and a process for follow. But what we lacked was the dedicated shepherd oversee the process. Contributions were often lost with team members prioritising their sprint work or moving on, then the product lab who contributed the component would disband. We’d awkwardly eye the contribution in the backlog like an abandoned puppy.
Without a dedicated shepherd or shepherds to keep on top of contributions as a considered part of their role, contribution is a tough. I’d love to hear if anyone has successfully achieved this, sans shepherd.
3. Document everything ✍️
Even if guidance or thinking never makes it to the official design system website, keep a record of it. We used a Confluence space with the same taxonomy as the design system where we collated research, wireframes, links, discussions and notes. In a systems team you’re regularly asked why you’ve made a decision and having the research or documentation to share helps build confidence in the service.
4. Make the design system mandatory, mofos! 🚨
If the design system isn’t mandatory then it is tough to get everyone onboard. During my time at Lloyds I’ve seen product teams and agencies rebuild the design system from scratch a few times over. I totally appreciate labs have their own deadlines and priorities. Teams are hindered by different tech stacks and legacy jank. Our system is not accessible externally, a massive blocker. And there is always a shiny new way of doing things.
For the systems team, the duplication of effort and slow creep of inconsistency is disheartening. If the funding and effort can be put into building one system, it will benefit everyone. Rebrands and change becomes straightforward and more cost-effective. This will ultimately ensure a more consistent, accessible experience.
5. Content is king 👑
Before I worked on Constellation, I thought I wrote pretty decent web copy. Turns out, my writing is actually pretty average. Congrats for even getting to this paragraph, my dude. Our brilliant conversation designer would take my words, remove 50% of them and turn them into something structured and meaningful.
Design and code might be the system’s focus but don’t forget about the words. A good content designer will bring consistency, standardise language use in components and structure your systems guidance. They’ll help your brand voice sound distinctive and recognisable across everything from onboarding to error messages.
Many of the accessibility and usability issues we saw in our drop-in were attributed to copy and content structure, rather than design or code.
I’m sad to be leaving Lloyds Banking Group today but so proud of what our small team has achieved over the past three and a half years. 💪
Lloyds is a great place to work. It's full of thoughtful product people who genuinely care and champion the needs of both colleagues and customers.
Building a design system at a bank is a tough gig, amidst compliance, process and legacy tech. It's easy to be critical and compare your system to others but given the constraints and limited budget, I think we made a pretty decent job of Constellation 1.0. I just wish we could open source and share all our documentation and research goodness.
On a personal level, this role has taught me it’s okay to fail. Not an easy task for someone who over-analyses EVERYTHING. I’ve lost sleep over big releases and deprecated components.
As a design systems team you probably won’t get it right the first time. Or the second time. Or the third. Be accountable. Own it, learn from it and improve. I guess this goes for everything in life, not just design systems.