Raising a design system is a bit like raising a child
During the time I’ve watched design systems grow up, I’ve watched my children grow up. I was at a recent Design Systems London Meetup where Henry Daggett presented a chart on the stages of a design system. Looking at Henry's chart, it occurred to me how raising a design system is a bit like raising a child.
I'm not just here for the cheap laughs! This talk had serious content too...
☞ Being to prescriptive
I work on NewsKit, a design system that supports media and broadcast brands across News Corp. I spoke about ways my team at NewsKit has perhaps been too prescriptive in the way components should be used. By offering anything larger than molecules are we making the system too opinionated?
This played out in the journey NewsKit has been on building an audio player component. Consuming teams found the audio player hard to integrate because the component lacked flexibility. We've since had more success introducing composable components, breaking down complex components into smaller subcomponents with their own props. Instead of giving consumers complete, prescriptive organisms, taking it back to a molecule level and giving them much simpler pieces to theme and assemble how they want has proved more effective.
☞ Lack of diversity in systems teams
As a design systems team we pride ourselves on being experts in UX and component best practice. But systems teams, at least in the UK, are generally not all that representative of a wide and diverse range of users.
I recommended Amy Hupe’s new podcast Systems of Harm. The first episode is about cognitive bias and how design systems teams making opinionated decisions on systems components can perpetuate systemic bias. Amy uses the example of title fields in forms - like Mr and Mrs - and the assumptions these make around gender identity.
As a largely homogenised systems team, it makes me question if we’re the right people to be making prescriptive rules on component use and assumptions about end users?
☞ Offering more flexibility
As systems grow and evolve I think we have to stop being so opinionated. A design system like NewsKit is consumed by such different brands with wildly different users. In my experience if you’re too prescriptive, teams will just build the things they want from scratch. Then you lose control over coding standards, accessibility and all the core stuff the systems team is good at and can plug in from the start.
It’s all about finding the right balance of flex for your organisation, then empowering teams to make sensible, balanced decisions. Of course, there will be instances where using a component a certain way or adding in different features is just not accessible or appropriate. Use tools like Storybook, your docs site or your design libraries to show best practice examples, call out the accessibility considerations and the semantics.
For me, the important bit is consumers are using the core atoms fed by tokens. In NewsKit, our opinionated molecules and organisms? We’re slowly learning to chill out a bit over.
☞ The future of design systems
Want to see what a design systems team looks like in the future?
In this section I covered:
- Accessibility is non-negotiable
- Set the rules but not the output
- Make the system mandatory
- Keep the conversation going
- Automate the boring stuff
1. Accessibility is non negotiable
One of the best things that design systems have brought to the table is the importance of accessibility, meeting WCAG standards, testing with users with disabilities and considering users of assistive technology. We’ve still got a mountain to climb but the tireless work of accessibility advocates in design systems teams is slowly bringing product teams to account. Keep fighting the good fight people, I feel like at least in systems we have reached the point where accessibility is non-negotiable.
2. Set the rules but not the output
I love this approach that’s emerging on being less prescriptive and more declarative. My thinking on this started after a chat with the legendary Jeremy Keith from Clearleft who had just written an interesting piece that sparked a talk on declarative design systems. Jeremy uses the imperative/declarative paradigm that comes from software development:
- Imperative programming describes code in a step-by-step process giving explicit instructions
- Declarative programming describes what you want the program to achieve rather than how it should run
Design systems tend to be imperative. Here are a set of pre-made components, the systems team has made all the decisions on everything for you. Rather than a true 'design system' for generating components.
A systemic approach sets the rules but not the output. Jeremy gives some examples in his blog like - say, instead of specifying a hex value for a button hover state you specify on hover reduce lightness by 5%. Rather than designing to fixed breakpoints you spec out the minimum and maximum layout and let the browser make the decisions on what happens in between.
3. Make the design system mandatory
I firmly believe unless you make a design system mandatory you will never get total engagement and contribution. There is always going to be a team or an external agency that doesn’t like the current tech stack and rebuilds the existing component library from scratch in Material UI or whatever this weeks new hotness is. When I worked on the design system at Lloyds Banking Group, three external teams did a complete rebuild of our component and design libraries because of politics and opinions.
I think the point we’re missing is the mandatory bit isn’t how the components look which is what folks often get hung up on. The value of the system isn’t in the artifacts, it’s in the systems thinking and the scalable ways of working and that’s what should be mandatory. The design system provides a set of flexible base components which have been accessibility tested, have considered ARIA tags and work for users of assistive tech - take these foundations and build on them.
As a super simplified diagram of how NewsKit works 👇 we have the core NewsKit design system with its base components - components are themed and consumed into products. Title teams can also create their own local design system. If they want to build their own complex components atomically, they have all the base atoms and utilities from the core. If the core design system is mandatory, it doesn’t limit what teams can build with it or impact how the product looks, it just ensures a solid foundation. It’s the foundation that’s the bit that I think should be mandatory.
The core system doesn’t have to be NewsKit code, it could be Brad Frost's idea of One Global Design System To Rule Them All. All the individual design systems teams are rebuilding and documenting the SAME COMPONENTS over and over again. If we all shared a single, headless system we could pull from one core, apply tokens that prescribe to the new tokens standard and build the stuff we want from one shared foundation. Imagine the joy of never having to build and document another date picker! Who is up for pitching in on a World Hack Day to make this?
4. Keep the conversation going
It’s hard to keep teams engaged with the design system, especially if you’ve been down a rocky path or in some cases even a messy divorce. It’s a cliche but design systems are all about people, look after your consumers, listen to them, 100% own your failings and mistakes and find ways forward together.
5. Automate the boring stuff
At NewsKit, we’re using plugins to automate process like our tokens pipeline which alleviates a lot of manual cut and paste. AI integration is stealthily creeping into our tools like code editors and content management systems. Here's some of the things ChatGPT is helping us with:
Let’s make a pact to only give AI the boring jobs so we can focus on the fun, human stuff!
Admittedly, while AI can’t replace the creativity and problem solving skills of my team, it does write cracking design systems jokes.
The evolution of design systems has shown us you can code the shiniest, most accessible system but business priorities and brand decisions will never allow for perfect cycles of iteration, adoption and growth. Product teams have their own roadmap, their unique user needs, and will always want to do their own thing. We have to learn to flex, trust our consumers and stop being so prescriptive.
What the last few years have taught me is to learn to roll with the punches, constantly reinvent yourself and adapt. This sounds like equally good parenting advice!
Thanks for the kind feedback on this talk ❤️
- Henry Daggett – How to Survive Design Systems
- Yahoo – Design Pattern Library 2006, via Wayback Machine
- Brad Frost – Atomic design
- Darren Yeo – Atomic design 2022
- Imani Beauford – Cake design system
- NewsKit – NewsKit design system
- Times Radio – Times Radio listen live
- Amy Hupe – Systems of Harm podcast
- Nathan Curtis – Subcomponents
- Nathan Curtis – How to make and share more flexible UI components, WebExpo
- zeroheight – How we document 2023
- DAL-E – AI system that can create realistic images and art
- Sudarshan Kadam – Unrealistic Applications Series, Dribbble
- Jeremy Keith – Declarative design
- Jeremy Keith – Declarative design systems
- Andy Bell – Be the browser’s mentor, not its micromanager
- Jen Simmons – Designing intrinsic layouts
- ChatGPT – Natural language processing tool driven by AI