Design within the Government of Canada
Last week, I wrote about design systems, and there’s so much more to unpack, I don’t even know where to start. So, I’m going to list a few topics here for now, and then hopefully work my way through them in the future.
If you want to engage in the discussion, join the conversation on the design-gc-conception.slack.com group or on twitter — I’m at @afhill.
What do we consider ‘design’ in the GC?
We have some people with ‘designer’ in their title, but a lot more people who make design decisions without realizing. Do we — or how do we — bridge the gap so we’re all working in concert?
Global vs local systems
Having a single design system that every designer across the GC can use may seem attractive for consistency’s sake, but is it realistic? We risk offering a sub-par experience for Canadians if we are designing for efficiency on the design side, and not for usability on the users’ side.
A take I like, but may be somewhat controversial: Consistency in design in the wrong approach.
“The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. “Is what I’m designing consistent with other things we’ve designed (or others have designed)?” is the wrong question to ask.” — Jared M. Spool
This isn’t to say we should have zero consistency, but we should be intentional.
Plenty more to go into here: we could look at atomic design, or I like to think about inheritance or things cascading like CSS, where you have generic rules that can be over-written in a more specific context.
Pace layers and evolving systems
Another concept that was discussed at CANUX 2019 (I miss that event!!) was pace layering, where different types of changes happen at different paces. From a design system perspective, we could start to look at how there are some base elements that would change very infrequently; perhaps these make up our core or global system. Then there are layers that change more frequently: these may be more closely aligned with colours or styles. The underlying foundation remains the same, but the interface changes. Is this a way to think about how we approach design at the GC? Does TBS (for example) focus on the foundation, and then different more specific departments and context work at a ‘faster’ pace?
I consider this related to the evolution of a system because, well, systems have inputs and outputs. They shouldn’t be static. But as I mentioned last week, I think we tend to look at the design system at the GC as a way to inhibit rather than encourage change. I was in a meeting just last week where someone said “we don’t want everyone to just go design a different button..”
Surely there is a way to identify areas for improvement — because really, don’t we want to be improving the design and experience on an ongoing basis?
With ongoing improvements, we can lower the risks of having to do giant replatforming or redesign efforts every few years.
Establishing contribution guidelines and processes
To add to that (and yet give it its own heading..), perhaps we can be explicit about what we are open to revisiting (navigation patterns-sure, core brand elements-no).
Or we create a backlog of ‘things we know we could stand to improve’ and then efforts can be focused there. Perhaps we go through a process of ideation, design, and testing at a component or pattern level, and if a new approach seems to do better than what we have, we look at incorporating it.
Right now, it’s unclear how new patterns get introduced into the Canada.ca design system. What are the criteria? What documentation or rationale needs to be provided? Opening this system up could go a long way to promoting improvements (assuming of course that’s a goal we have).
Ok, that’s enough for this morning’s stream of thoughts. Look forward to talking through this with some of you!
