Design systems can represent an obvious panacea for multi-products design issues when viewed from within the Design and UX community, but their benefits and challenges are far from transparent and even alien when viewed from different perspectives within a reasonable sized distributed global software company

Here are some main points from my recent experiences in developing a design system from scratch in one such environment.

Getting that buy in: Design debt.
Ah, my favourite flavour of technical debt. The results of even a brief UI Audit will starkly bring the outcome of divergent, possibly siloed and organic software development into sharp focus and should be the first port-of-call in demonstrating an incoherent and inconsistent user experience. This variation on technical debt: design debt here then will in turn result in user confusion between being presented with different design patterns and slow development due to lack of common guiding standards, possibly even duplication of work across teams.

In advocating and evangelising design system development it’s key to frame the proposition in terms that both teams working on and using the system as well as major stakeholders will relate to.

I echo the opinion that it's best to garner the support both of one key team and one key stakeholder as key advocates in the early days. This duel approach will hopefully result in key players also turning into advocates - and is far easier that trying to convert many teams at once - and who could blame them for some resistance. It wouldn’t come as a surprise to have someone parachute in and immediately tell everyone they’ve been doing it all wrong - especially if these people are highly skilled experts in their fields.

For the business as a whole its important to frame the benefits from a Return on Investment (ROI) point of view. ROI of design is difficult to evaluate but the following benefits are tangible advantages: Improved performance, consistent UI / UX, better use of resources, quicker builds, brand consistency, leaner and cleaner code and
easier maintenance.

A rising tide.
Also key is the benefits across a suite of products from the requirements of one - that all products will benefit from incremental improvements across the suite

Requirements
It is paramount when developing specific UX design patterns, say a date picker, or upload mechanic for example, that product requirements are seen to be the pushers of the UI development agenda. However it's also key where multiple products are involved to ensure requirements are gathered and discussed across the Product Manager/Owners. New collaboration tools may be required - we used individual forums to start debate and gather edge cases across 3 different time zones to help in this area.

Principles
At the beginning of this journey we set out to identify principles which could serve as guiding lights for our discussions, large and small, about products and UX patterns. We were dealing with highly complex IT software management interfaces - perhaps talking about how filters might be returning results with millions of rows but still we wanted to stay true to simplifying options and tasks where possible. Drawing up these guidelines were essential. Many firms have taken this approach.

A11y (Accessibility)
Chief amongst our principles was accessibility - both from an ethical point of view - everyone should be able to use our software regardless of differences in how they interact. Key legislation in the US and UK also stipulates this requirement - so adding the idea that all UX patterns needed to be navigable from a keyboard and screen reader perspective was fundamental.

Design thinking
Evolution vs revolution in the UCD transformation

Most journeys cannot be completed in a single step - the transformation from a feature driven engineering led approach to a user centric one is not an easy one. With buy in from key teams and stakeholders change can be achieved but assessing that appetite and deciding which pieces of a process are key to introduce and which might be worth adding down the line when more people are onboard is a tricky one.

Initially we forewent some of the prototyping stages to keep up release cadences and realise some of the early benefits. This enabled us to add in more rounds of user research further down the line after some of our more expertise led and heuristic analysis based approach had paid early dividends.