Converge US

I spoke at Converge US, zeroheight's design systems conference in San Francisco on the evolution of design systems.

Slides here and the main points of the talk below 👇

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.

A funny chart showing the journey I have been on raising a child with many ups and down
The journey I've been on raising a child
A funny chart showing the journey I have been on raising a design system with many ups and down
The journey I've been on raising a design system

I'm not just here for the cheap laughs! This talk had serious content too...

Themes

☞ 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?

A screen from Dal-E with the question What will a design systems team look like in the future? The image generated shows three white men in black t shirts with white typographic designs on them.
According to Dal-E, it’s the same group of white guys, all wearing the same black ironic typographic t shirts, poised to mansplain CSS variables to you.

In this section I covered:

  1. Accessibility is non-negotiable
  2. Set the rules but not the output
  3. Make the system mandatory
  4. Keep the conversation going
  5. Automate the boring stuff
A side view of Geri on stage at Converge conference in front of a slide with a list that reads: 1. Accessibility is non-negotiable, 2. Set the rules but not the output, 3. Make the system mandatory, 4. Keep the conversation going, 5. 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.

Quote from Jeremy Keith: Setting up the rules and ratios in advance but leaving the detail of the final implementation to the browser at runtime.
Jeremy Keith on declarative design

This sentiment is echoed in talks by Andy Bell, Jen Simmons and many other clever folks who are advocating for this common sense approach.

Quote from me: setting up the rules and ratios in advance but leaving the detail of the final shitshow to your child at runtime.
My take on declarative parenting #cheapLaughs

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.

A diagram showing the NewsKit core design system. Consumers can also build their own local design system that consumes from the core

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?

A diagram showing a global design system, in place of the NewsKit core. Consumers can build their own local design system themed to their brand

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:

A photo of the zeroheight zine
The zeroheight zine that came with Converge conference swag showing the ways ChatGPT is helping designers and engineers on NewsKit

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.

A ChatGPT window showing this joke: Why did the design system go on a diet? Because it had too many components!

Finally

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 ❤️

Talk sources:

Continue reading

WCAG 3.0 at WDC

Prev project

WCAG for designers

Next project
Headshot of Geri Reid, a white woman with long dark hair, wearing a blue and white striped top, looking off to the side

About me

I've designed digital products for the past two decades.

As design and accessibility lead on NewsKit design system, I helped some of the UK's largest media and broadcast brands to design at scale. I was design lead on the Constellation design system at Lloyds Banking Group and set up design system foundations at Checkout.com and BPP. Way back, I designed digital products at UBS and Bank of America.

Over time, my design roles have become more strategic: planning, training and writing technical specs and docs. My work on systems has also made me a keen accessibility advocate. Through care and attention, I've learned how a design system can provide a solid foundation for product accessibility.