One ‘design system’ doesn’t fit all

There are a LOT of conversations around the Government of Canada about design systems right now. I love it!

But for all the excitement about consolidation, consistency and efficiencies, I’m worried we’re missing something.

The user experience. The fact that different people are trying to do different things at different times.

We can’t expect a limited library of components and patterns to meet all needs in all contexts. So there are two options.

1. We create a huge library that has all the components for all possible products, services and context
2. We break apart the library so people only access the pieces that are relevant for what they’re working on.

The huge library is easier to create, but harder to use. The more granular libraries take more effort to create and maintain, but they support users better, especially over time.

The focus of this post is going to be on the second option. I do not believe a single design system or library will meet the disparate needs of designers and developers across the Government of Canada, and the sooner we acknowledge that, the better.

Context is critical

In my two years with the Government of Canada, I’ve worked across three different groups designing technical solutions for different users.

1. Public Works and Procurement Canada (as part of a fellowship with Code for Canada, working on “re-imagining Government travel”)
2. Transport Canada (working on the Enterprise Architecture team supporting multiple development teams and internal applications)
3. Canada Revenue Agency (focusing on our public-facing web presence, https://www.canada.ca/en/revenue-agency.html )

There has been a lot of work done on the canada.ca web presence, so there are already some standards in place, documented in a design system.

But what has been documented here wasn’t particularly relevant for the applications I was working on at Transport, nor the conceptual work we were doing at PSPC.

The audience was different. What they were trying to get done when engaging with the product was different. The components and patterns as outlined on the Canada.ca design system didn’t “fit”.

This is not to say this system isn’t robust enough. It’s to say that when an railroad safety inspector is using a Windows tablet application to document his inspection out in the field, his needs are different than a Canadian visiting Canada.ca to learn whether the tax deadline has been extended. We should be designing in a user-centred way. Focusing on meeting users’ needs, not on being consistent for consistency’s sake.

I used to work at a company called LexisNexis. We had dozens of products, including international versions of our core research platform. I spent some time working on their US-based products before I moved back to Canada and started working on our flagship Canadian product.

I remember we had a file (we used Zeplin to share design specs with our developers) that was just all of the headers for all the products. They were very similar, but the US product had slightly more features, the Canadian product had a language toggle, etc.

I couldn’t use their components directly, but I could refer to them in working on the designs for my own product.

The way components were designed for the US didn’t quite work for us, so often our work would look like a cousin to the American rendition. That was ok. We knew that our codebase was different. We could use their work as a starting point and then extend it.

There were some discussions that “the US team could consider our needs too, and design a component that works for everyone right off the bat”, but that stuff is hard, y’all. It’s already hard enough to negotiate timelines and budgets to deliver on your own requirements, much less someone elses’.

Bringing it back to the GC, can you imagine if those working in TBS came out and dictated interface patterns for highly specialized applications for food inspectors or aviation security officers? We want user research to be happening to understand the contexts and needs of those users, ideally as close to the team that is equipped to solve them as possible.

Now, we don’t want to go overboard..

This is not to say that every team should just go do its own thing. Not at all! But ideally we are learning from each other and applying what’s useful to our own context, and discarding what’s not.

There may be atomic/primitive/foundational components that we are used in multiple contexts. Then we can overlay some specific context or need, that may build upon that foundation.

If I am working on canada.ca, I may not need your specifications for how you handle offline sync with your Windows tablet app. That’s a pattern that is specific to a context, and doesn’t need to live in the global system.

A design system can be seen as a way to build on the efforts of others, but it shouldn’t become a dumping ground of every one-off design that is conceived. It needs to help those who are seeking to design, and that means providing guidance as well as examples. A design system shouldn’t just be a catalog of anything you COULD do — of anything that’s ever been done before. Rather, it should provide the options and support to help identify an optimal next step based on what your user is trying to achieve.

So.. what then?

There are some great resources in the private sector that are working on resolving these issues now for themselves, looking at a “system of systems” or “global-local” model.

Rather than try to regurgitate, I’ll just leave these here:

Reimagining Design Systems at Spotify

https://ux.shopify.com/building-a-local-design-system-b2810c6e01f 2