Is your Design System designed to encourage or to enforce behaviour?
I’ve been in a few cross-governmental discussions lately about design systems and shared component libraries (if you’re part of the GC, join us over in the design-gc-conception.slack.com group!).
Some of my favourite conversations have been around the purpose and intended audience of a design system, which have been really interesting as they’ve forced me to re-examine my assumptions.
I’ve spent the bulk of my career in software organizations, where as part of the UX team I worked closely with software developers to implement rich interactive applications. When I first worked on developing a component library (we called them “UI Building Blocks”), it was intended to help us prototype quicker and more consistently. Different members of the team didn’t have to keep trying to solve the same problem over and over again, and introducing unintentional deviations or incompatibilities.
Design systems have evolved to encompass a lot more than just component libraries, including usage guidelines, patterns and conventions. Once upon a time I remember “style guides” would be a deliverable of themselves, and then once created almost immediately become outdated. A design system has to be seen like a product in its own right, with ongoing support and improvements, if it is to serve its audience.
One thing that’s struck me a bit since joining the GC is that I’m .. less sure I know who that audience is. UX designers are few and far between, UX or front-end developers even more rare.
The canada.ca web site is considered a comms platform, which seems different than a software application.
I crave a system that supports UXers in creating and proposing new patterns, and developers in implementing those patterns. A system that can help us scale design because we’re sharing knowledge, learnings and implementation details, and in turn providing a more usable, better web experience for Canadians.
Instead, I have gotten the sense that we actually see the design system as a way to set up guardrails. To tell people what NOT to do. Which seems like a somewhat typical government risk-averse approach to things.
I feel really passionately about scaling design and UX. How can we have “more good design, not less bad design”?
One concern about having a shared component library is that it may be too easy for someone to mock something up that “doesn’t follow the guidelines”. But that’s not the component library’s fault — people misuse tools all the time! (Plus, if we don’t give them anything, they may completely mock up something from scratch that’s nothing at all like the guidelines).
Instead, if we can provide a component library, people can spend less time doing the low-impact work of drawing boxes and arrows, and more time actually doing the creative work of ‘good design’.
If you’ve read my blog before, you know that I loath the idea of designers being considered “order-takers”. Someone draws a rough wireframe in powerpoint and says “make this pretty”. That’s not UX design! A component library can help a designer work more quickly, but of course it doesn’t make someone a designer, any more than my owning a saw makes me a carpenter (jk I don’t own a saw).
Sorry — side rant.
If we want to offer Canadians a better web experience on canada.ca, we should promote more good design, not try to throw up barriers to inhibit bad design. Web pages are going to get updated whether people have the ability to mock up things up first anyway, so why not make it easier for people to try things? Perhaps that dip into the pool of laying things out will spark some interest in UX. Lowering barriers can introduce more people to our field, and having more allies seems like an overall positive step, doesn’t it?
One example I’m pretty sure I’ve mentioned before — currently, in order to run usability tests at Canada Revenue Agency, we create HTML prototypes and host them on GitHub. Officially, our team has zero developers. But if you want to test a prototype with users, you have to figure out how to get something out there on GitHub. That’s a barrier. It inhibits creativity, and has the potential to feed into a sunk cost fallacy, where if we’ve spent a bunch of time already building something, its harder to throw it away.
If we want to test and iterate more, we should make that easier.
If we’re concerned that our teammates will abuse Figma and create crazy designs that can’t be implemented, that’s a culture problem, not a tool problem. And really, crazy things can equally be created in HTML, so we’re not really achieving this quality control lockdown by only prototyping in HTML anyway.
I suppose I’ll end here by saying that I think we need to reflect on who this system is for, and how we believe it will change how work is done. Tools can only do so much, and they shouldn’t be put in place to fix human problems. If we have concerns about people not doing things “right”, let’s provide them with the resources to learn how to do them right, rather than just make it really difficult for them to do anything. 🤷♀️
Edit: tune in next week while I try to talk my way out of my flippant comments about what ‘makes a designer’.. I’m worried that I accidentally expressed the opposite of what I meant…
