Scalable systems design: consistency for growing products

Before expanding a library, look for repeated work: forms with similar validation rules, error messages written from scratch, filters that behave differently or journeys that use different names for the same action. Each repetition is an opportunity to investigate a shared decision.

​

Imagine three squads building registration flows. One validates fields on blur; another on submission; the third clears the data after an error. Standardizing their appearance leaves those differences in place. The pattern needs to explain when to validate, how to communicate the problem and how to preserve what the person has entered.

​

Design Systems 101, by Nielsen Norman Group, explains the relationship between reusable patterns, guidance and the people maintaining them. Start with a recurring problem and test the solution in a real journey before expanding it.

In scalable systems design, I find it useful to separate three levels of decisions. Foundations define typography, color, spacing and motion. Components solve recurring interactions such as selecting, filling in and confirming. Journey patterns combine those parts for tasks such as registering, reviewing or tracking a request.

​

Semantic tokens make intent more explicit: an error color communicates a function; an isolated red value only describes its appearance. This distinction helps design and engineering discuss changes without relying on choices scattered across individual screens.

​

Variations should address recognizable needs. A field may have help, error and size options. A product-specific rule can stay local until there is a reason to share it. IBM’s Carbon provides a reference for a shared foundation extended to different products and uses.

People need to find a component, understand when to use it and recognize its behavior in the live product. Names, states and guidance should correspond across the design library, implementation and documentation.

​

Document what changes a decision: when to use a pattern, when to choose another solution, content limits, mobile behavior, keyboard navigation and error messages. An example with real content often explains more than a screen filled with generic text.

​

In the smarters Design System, components and guidance became part of the same workspace. That experience reinforced the value of keeping references close to where the team builds. In scalable systems design, documentation should evolve with the questions that emerge during use.

Who proposes a change? Who assesses its impact? How does a team know that a solution already exists? These questions need accessible answers. Without a clear path, people improvise or depend on informal approval to move forward.

​

A contribution can start with an observed problem, usage examples, alternatives considered and the impact on existing products. The GOV.UK Design System contribution criteria offer a useful reference: proposals should demonstrate usefulness and avoid duplication; before publication, they are assessed for usability, consistency and versatility.

​

Define how to communicate releases, replace old components and allow time for migration. Maintenance belongs in delivery planning. In the article about my practice as a Lead Product Designer, I explore the responsibility of setting direction and creating conditions for teams to decide.

The number of published components says little about a system’s usefulness. Track which patterns are adopted, where local adaptations emerge, how long comparable tasks take and which questions keep returning. For people using the product, observe errors, comprehension and journey completion.

​

In the smarters case study, I present a change in average execution time from 7.4 to 5.2 hours, approximately 30%, based on averages recorded in Monday. It is evidence from that context and connects the system to the work performed by the team.

​

To evaluate scalable systems design, choose measures that address the original problem. If it was rework, investigate revisions and corrections. If it was inconsistency, track differences across equivalent journeys. This connection between decisions and evidence also appears in my article on building a product design portfolio.

Start with a journey that has enough repetition and impact to justify the effort. Create an inventory, prioritize patterns, agree on criteria with engineering and follow the implementation. Use the difficulties you observe to guide the next version.

​

AI can support exploring alternatives, organizing examples and identifying inconsistencies. The team still needs to assess whether a variation solves a real need, preserves accessibility and makes sense in the product. Generating more options makes clear selection criteria even more valuable.

​

When choosing a product designer, look at how they connect these decisions: what they share, what they keep specific and how they work with other functions to sustain the solution. This ability to coordinate turns a library into a team practice.