Design Systems -if done right- are fundamentally the result of applying Systems Thinking to how we design and build our interfaces. However, it is common to think of these as monolithic/bureaucratic structures aiming only for consistency and alignment across our design and engineering sources. Something that focused mainly on the elements of our user interface alone while the User Experience matters live in a different realm, away from documents, libraries and storybooks. This approach is not necessarily wrong, but it definitely doesn’t live up to the full potential of an effective Design System.

The most common approach for many companies and product teams out there is to use Design Thinking when defining and building better UX solutions and only work on the Design System once we work on our interfaces. However, this leads to a very common challenge when Design Systems are freshly implemented: It gets boring to maintain it, mistakes start to happen and the aim for consistency potentially can kill innovation and out-of-the-box solutions.
This is commonly used to question the value of the design systems. Why should we build and maintain such a complex structure and put processes in place for something that can easily make our work more boring and less flexible?

I believe the problem is not the Design System per se, but the disconnection between this and everything User Experience, understanding the system as just a big clanky UI library and missing the opportunity to do more and better.

Design Thinking is not enough, Systems Thinking is here to help

Design Thinking is an extremely useful methodology to solve concrete problems as it provides us with the necessary steps to understand better our users, define the problem and identify/test potential solutions, but due to its own -tied to each problem- nature, it lacks a holistic view of how these solutions might impact our product ecosystem.

This is where Systems Thinking comes into play, and what I have been interested in developing in the past couple of years:

Building a holistic UX strategy that is not different from our systemic treatment of UI.

Product Design team structure varies from one organisation to another, but its decentralised nature is a constant. Generally, Designers are embedded in product teams together with Engineers, Product Managers and other stakeholders. These teams have their own objectives tied to company ones which make them -when lacking access to a unified vision- disconnected from the whole.

For Product Design teams this structure brings its own set of challenges when trying to define a UX strategy or push forward a parallel set of tasks:

• Product Design objectives, even though, closely linked to the company OKRs/strategy might be perceived as extra work if there is not a mature customer-centric culture in the organisation.
• Simply there won’t be time to do it all. The amount of work is very high at the product team level and as a consequence, designers and other stakeholders are lacking time to see more than the trees.
• Building and maintaining a team with our own set of rules, principles and values takes an extra mile when individuals' time and effort are split across many teams.

Achieving and Maintaining UX quality with Design Systems

There is no way around facing these challenges nor a silver bullet to solve everything, but substantial improvements can be done when focusing primarily on the system over fading goals.

“In order to improve for good, you need to solve problems at the systems level. Fix the inputs and the outputs will fix themselves.”
― James Clear, Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones

The good news is that -in most cases- we already have a system in place that, if done well, can be enhanced to incorporate a whole Product Design strategy with concrete results positively y impacting company metrics like revenue, acquisition, engagement or retention.

How to

1. Enhance and redesign the scope of the System:

Every Design System out there focuses heavily on the execution and final outcome, this takes the shape of better documentation, better-built components, stronger brand guidelines and more alignment between teams. The results are very tangible. Once shipped, anyone can see -and start using right away- that new button with a better colour contrast ratio or that input field with a new, fresh interaction. This is one of the high-value propositions of having a Design System, building tangible components at a scale that anyone can -notice and- use.

The scope for Design Systems can be increased to cover more than just tokens, assets and components. Topics that transcend from the molecular UI implementation to concrete User Experience areas where a centralised strategy can be formed. These are a combination of patterns and collaborative tasks:

• Data Tracking
  In general, the Data and Design teams can work very closely together when defining a quantitative collection strategy. Data is the first key step in any design process and by its own nature, both teams work on collecting it at the component level.
• Content & Copywriting (including localisation if applicable):
  Content is the second step in any design process before working on preliminary visuals. Content is born when data has been collected and processed, once it has an intent for our users, we need to pay attention to it as content mainly will dictate the shape of our composition and visual hierarchy.
• Navigation
  Translating common navigation behaviours into principles allows us to better understand the pattern as a more scalable concept. More about Navigation patterns in detail here.
• Modular UX Patterns
  Modular and variable solutions are linked to our users' segmentation metrics.
• Accessibility
  This is self-explanatory, an umbrella area that covers everything in our interfaces to make them usable and enjoyable for people who interact with products differently. Accessibility must be approached as a facet of user experience rather than a checklist of requirements.
• Delight
  From micro-interactions and visual/brand adoption to measuring the scale of delight in our interfaces. More about this in this brilliant article.

It is important to mention that the points above are not the responsibility of Product Design alone, but most likely a collaborative effort with different teams where Product Design will play a key role in executing and delivering.

2. Build clear ownership with defined roles & responsibilities

For the Product Design team to assume the sole responsibility for all these topics is not only unrealistic but a poor example in collaboration with other departments that can lead to many common evils.
If you already have a mature enough Design System, you know this simply can’t happen without Engineering being at the centre of the action. If we increase the scope of our system, it is only natural to expect the scope of ownership and responsibilities to expand as well. At this point, the definition of these roles is critical.

Something that worked well in the past is to create a more centralised “team-within-the-team” to cover these specific areas, ideally, this team should have designers, Engineers, Data Analysts, QAs, a Product Manager, Content Designers and Accessibility specialists. Realistically, and based on the resources we might have, at least, make sure you have the right people covering every point of this newly enhanced system.
This team will have their own set of ceremonies and should be incorporated into the Agile team's org.

3. Execution is everything: Have a roadmap, tasks and sprints.

Having a defined scope and roles and responsibilities assigned are very important steps, but a concrete plan needs to follow where the progress can be measured and incorporated into our company-wide metrics. For doing this, I like to use a (simplified) scheme that explains one of the System Thinking approaches when it comes to building or reorganizing system structures. You can read more in detail here, but it is basically a set of steps and stages that ensure we deliver on what is planned. Some of them can be seen as steps following a natural sequence, while others work more like stages usually co-existing and sharing common projects:

0. Audit your system based on the new scope
If you haven’t done an audit of the state of your product from a functional point of view, covering UI/frontend quality, building processes, accessibility, etc. It is time to do it, if you have done it recently but have increased the scope of the system, it is time we cover those new points as well.

1. Alignment
From Naming convention and sources synchronization to steps of the process. The objective is to achieve alignment across every touchpoint of the system. Alignment = clarity.

2. Optimization
We can’t optimize the system without understanding what is not working well and without organising first, the 2 previous steps ensure we can trace an optimization plan that we incorporate into our Product Design Strategy.

Here is where the plans and projects to make better the user experience will live, these might relate to other project buckets and this is totally fine.

3. Updates & Innovation
Innovation without quality grounds tends to become a source of design and tech legacy and short-lived solutions. Make sure the system is in an optimal state before developing it further.

4. Maintenance & Sunset
This is the step where those stable and outdated spaces and elements live. Here is where the decision to either continue supporting them or planning their deprecation and sunsetting takes place.

Summing Up

The benefits of having a design system apply not only to design but most importantly, to how we build and ship our front-end and interfaces, allowing us to build a product at scale with clear touchpoints on coherence, quality assurance and accessibility. But Why don’t apply this same approach to how we define and create optimal solutions for our users?

As a big advocate of Systems Thinking and knowing the unexplored potential of Design Systems, I believe that by using effectively both of them — the methodology and the framework- we can create a successful Product Design strategy at a scale that responds effectively to the needs of our business while connecting and engaging more stakeholders across the organisation in a joint mission.

Thank you for reading!

This article was written with Writty ✏️