Stewardship of a design ecology

We have 12 teams at Achievers and each works on a different part of the product. To the end-user however, this is generally invisible. A user consumes a product as a whole, jumping across workflows with no concern for team boundaries. And although teams want a singular experience for users, each feature has individual challenges to meet and it isn’t always possible to consult all other teams in that process.

The design system then, is a shared language that keeps the user familiar with their surroundings, even as they switch tasks, abandon carefully constructed journeys, or run multiple tabs concurrently using different features. To use a metaphor, a design system is like a langauge: the grammar is shared, and teams have a unique vocabulary of words to meet their needs. As a design system designer, I help ensure that words mean the same thing everywhere.

One key boundary to consider is what part of a flow should be driven by the feature team, and what the design system. Our starting point was to see the system as a set of shared rules, and the feature teams would attempt to follow those rules.

Our core rules tended to be primitive, eg: icons should be 24px, solid. This meant that although our icons shared a visual similarity, they didn’t share meaning. We developed different icons with the same meaning, and also used the same icon to convey different meanings.

Switching to semantic icon names created a shared vocabulary that every team could use. This changes the design problem from the question “how do I make a right arrow” to “what is the icon for expanding forwards”. Conversations across teams then, are not focussed on icon agreement, but on what the user is doing. And this process scales for typography and colour as well.

• Sans-serif 24px, becomes PageHeader and also includes heading level, colour and accessibility label connections to the parent section
• Color #f31256, becomes Error/Alert, which can also inform screen reader urgency

Getting abstract

As this semantic layer covered more of the platform, it could include more abstract concepts. These product more complex reusable patterns, that makes the product feel more natural to a user jumping between different parts of the app.

• an input field focussed on selecting a person could be semantically improved into a PersonSelect with autocomplete that displays avatars and an optional org chart
• date and time selectors focussed on scheduling can be combined into a higher level pattern with resolution settings like “morning/evening” and “month”… or handy shortcuts like “Tomorrow”, or “First Monday of the quarter”

A design system is a community resource. Although there is a team focussed on maintaining and evolving it, its purpose is fulfilled by every other team. It seems counter-productive then, to consider “ownership” and instead I see design system designers as stewards—caring for the property of another. When something needs changing then, it cannot be enforced by its owners alone.

Here, I take two lessons from the Toyota Way. Instead of building consensus all at once in a large meeting, I spend time with each designer likely to be affected by the change — a new component, an update, a core principle — to take questions and feedback. This tests the change in small ways, leaving space to adjust it (tatakidai) and lays the ground work (nemawashi) for the update announcement when it is ready. This way, many people were involved in its creation to a great level of detail, and it has been through many rounds of testing as a part of its development.

The resulting announcement is also a more positive process. Most people are already familiar with details behind the change, and their concerns have either been addressed, or at least noted for future consideration.

In order to improve visibility into the changelog, I also wrote a weekly snippet of an ongoing adventure saga reflecting the journey the design system itself was going through. This added a bit of fun to the release process and got the team used to updates.

Designing for semantics also has a strong positive benefit on development. Discussions between design and dev teams can be on concept and focus on the objects themselves without concern for their literal construction. A PageHeader component can be assumed to exist, and a feature team can focus entirely on its use to the user without worrying about the size, colour or level it might need to be. To create space for these discussions, we wrote type definitions for proposed components before we started building them.

Example

type PageHeader = {
		title: string;
		subTitle?: string;
		backAction?: {
			label: string;
			onClick: () => void;
		};
	}

This creates an agreement between all parties for what information is required to render a PageHeader component. Therefore content, is the primary concern.