Design systems for products: ecosystem of design systems
This article is part of a short series exploring a model for a layered design system ecosystem beyond interfaces in complex organisations. This article outlines thoughts about what might sit under design systems for product.
Read part 1: Beyond design systems for interfaces. Exploring a topology of design systems
Design system for products
A design system for products contains the conventions and approaches to follow to design and build products; as well as key building blocks.
When it comes to creating (digital) products, sketching an interface usually isn’t the first step of the process. Even when the brief is seemingly clear and straightforward. Exploring the problem area, critically thinking about the ask, gathering insights, and defining user and business needs are key to shaping a solution — a solution that might ultimately be expressed through an interface.
A design system for (digital) product inserts itself at the moment between requirements gathering and solution definition, when teams are exploring the conceptual user journeys, flows and logic — the foundational elements preceding the translation into tangible interfaces.
This design system layer helps steer teams through some key questions: ‘What principles govern our user journeys?’ ‘How do we approach the crafting of new journeys or refining existing ones?’ ‘Are there recurring steps that could elevate our journeys, and how do we harness them?’ ‘What standardised methods exist to lead users towards specific objectives?’
Imagine the design system for interfaces is a well-stocked pantry, equipped with the essential ingredients for creating captivating visual experiences. In contrast, the design system for products transforms into a culinary handbook — a guide on inventing tasteful and memorable dishes, effortlessly weaving fresh ideas with a nod to the classics.
Inside a design system for products
A non-exhaustive list.
Product experience principles
Every great experience is based on certain values and principles. They often manifest as aspirational statements and keywords elucidating the ‘what,’ ‘how,’ and ‘why’ behind the products.
These principles are overarching and might apply within the organisation across all products, a specific portfolio of products. There’s usually not a single set of principles, but rather a collection covering different channels and aspects of a product. For example:
- overarching product design principles
- IA principles
- digital art direction
- content principles & guidelines
- motion principles
- accessibility principles
- coding best practices
- etc.
Most design systems today include some kind of product design and/or content principles as part of their documentation. They often sit outside component libraries as part of a “foundation” layer.
Because design systems tend to focus on interface, it is not unusual to see interface examples next to the principles as a way to illustrate how principles are applied. This differs from team to team. When it comes to how best to organise this content, there’s no one-size-fits-all: it depends on your audience and your content.
Since a design system for products is a tool applicable to several products, it’s important to remember that anything that applies specifically to 1 product only shouldn’t be part of a design system. Principles here should apply to several products, just like UI components in a design system for interfaces can be used in different contexts. If the principles only apply to a specific brand and specific product within that brand — it’s then a part of a handbook for that product, not the design system.
The governing principles dictated in the Design System for Products will often act as a kind of ‘checklist’ to sign off components, interfaces and user flow.
Below is an example from Adobe’s Spectrum, where design system components go through a final checklist. As illustrated below, some items link directly to higher-level principles.
It’s of course not the only way to do it. And I’m not saying Adobe has nailed it either. After diving into their documentation site, some things don’t work for me personally, or things I believe could be clearer when it comes to the structure of their principles and guidelines. However I have no insights into their ways of working, how teams use the design systems, how they maintain them, or any of the constraints and realities that have informed decisions. This is where the process layer of Design Systems comes back in in the picture.
Product patterns: sequences & user flows
In a design system for interfaces, the building blocks consist of UI components that form cohesive UI solutions. Conversely, in a design system for products, these building blocks take the shape of higher-level solutions, encompassing sequences and flows. In both scenarios, these building blocks represent best-practice solutions that empower users to achieve goals while aligning with business objectives.
Typically when we talk about “patterns” in design systems — we mean UI patterns. Things like elevation, usage of cards, how forms are handled,.. But if we take a step back and look at products without being concerned about the interface solution, then we can look at a different kind of product pattern. Stripping away product patterns from their interface counterparts, we are left with the essence of the underlying user flows — their rationale, the requirements that shape them, and the insights that inform their design.
If you’ve ever done journey mapping or service blueprint exercises to examine an end-to-end user experience, you may know that the common practice is to break down a journey into distinct stages. These stages traditionally lean on some kind of variation of the LBGUPS framework (Learn, buy, get, use, and pay; or its variant of awareness, consideration, decision, retention, and advocacy). Each stage is broken down into a series of step representing key user actions. Each step is then detailed in terms of user flows by product teams, outlining possible paths rather than a single scenario.
When certain steps in user journeys become recurrent and/or repeatable, either within an individual journey or across different ones, they qualify as patterns.
These patterns focus both on the user-facing flows, as well as the ‘backstage’ processes required: technical orchestration, or other human processes.
In service design circles, these repeatable steps are often called “service design patterns”. I’ve heard some people using the term “product patterns”…which, I wonder, could be more appropriate.
In all honesty, I have also been scratching my head a lot about whether a product pattern and service might be the same, and if not, where the boundaries lie. If anyone wants to play on the semantics of it all, by all means, go for it. Personally, I feel the distinction is not needed. It feels like dividing things risks perpetuating some kind of organisational structure. The desired outcomes of design systems, even complex ones, is to foster collaboration, break siloes and create some level of a unified way of doing things. As I wrote in the previous article: boundaries between the different levels of design systems won’t be a clear-cut.
Because “service patterns” and “microservice” patterns are a thing in software, I’m inclined to favour the term “product pattern” here.
I know that within digital teams of government services, the term “service pattern” is used. After all, they provide services and don’t consider their websites as ‘products’ per sei.
Anatomy of a product pattern (service pattern)
The basics:
- A name: favour verb-oriented names based on user action, goal or outcome rather than interface elements or nouns. E.g. “Register for something” vs “Registration”
- User flow diagram(s): a sequence of detailed steps that users go through to fulfil their goal, including edge cases and other “unhappy” paths.
- Backstage technical building blocks: key technical services, APIs or components that belong to this pattern, if relevant.
Every pattern should have a certain level of documentation regarding the rationale behind the pattern, and any requirements and guidance to take into account when using it:
- User needs & insights
- Business objectives & requirements
- Legal requirements & guidance
- Content guidance
- Technical requirements/constraints
- Do’s and don’ts
- Variants and deviations guidance
- Links to examples if relevant
When composing new user journeys in products, the documented pattern with its user flows helps fill in gaps by using established frameworks and solutions; without dictating specific interaction solutions. Think of it as a way to create an outline of a story, without having defined all the details and the full script. Like how the classic “Hero’s journey” storytelling framework defines key story stages, without dictating exactly the content of a story and how it comes out.
As a pattern, each user flows could apply to different products, which may choose to apply the pattern through different UI compositions.
Within a given product, the design system pattern sort of becomes a product-specific pattern tied to a UI solution that can be re-used within that product scope: a series of modules or pages that follow a specific sequence and logic, using a specific combination of design system UI components.
Most of the design system discussions tend revolve around digital interfaces, but let’s remember that design systems are relevant beyond digital. If your organisation handles services that include both digital and non-digital channels, it’s worth considering how a design system for products could apply across channels — leading to more holistic approaches and coherent experiences that go beyond single channels — they create better end-to-end journeys and services. They encourage cross-channel thinking and strategies to foster collaboration and innovation.
Processes
Every design system comes with processes, and this design system for products is no different. The same considerations need to happen when it comes to setting up the right processes when it comes to creating, maintaining, and evolving the ways of working — especially when they have wide ramifications. How might you manage change? When should a given micro-journey be upgraded to a pattern? Who is responsible for documenting what? The assumption that ‘people will figure it out’ only works for so long, and when it comes to scaling operations there is always a bit more rigour needed.
Design system operations are a shared effort between product teams, designOps, devOps, researchOps but also involve key stakeholders and contributors who sit outside digital product teams: think legal, branding, and more. A big part of defining processes and ways of working is to first understand who needs to be involved vs who uses what, how they work now versus how they would work in an ideal situation; and then manage change.
Design systems for products:
- Used by: product teams (PO, designers, software engineers, business analysts, architects..) to shape how products work, people who care about slightly bigger pictures than implementation details
- Maintained by: design system teams and more?
- With contributions from: product teams, brand teams, legal teams, finance team, service designers, operations team,…
Design systems for interfaces:
- Used by: product delivery teams (content & product designers, software engineers) to design and build the interfaces of a product.
- Maintained by: design system team
- Contributors: product teams mostly
Coherence over consistency
Over the years, many people have argued that design systems as a framework lead to digital products looking, feeling and working the same way. The death of design originality, the extinction of creativity, and so on. So it’s important to keep a certain level of flexibility in the process and design of the assets that go in any design system: there needs to be enough guidance to help people create experiences with solved solutions, and enough flexibility to enable people to have agency and control how they use the systems based on their specialty areas.
Always remember that:
- Design systems are a collection of settled solutions to problems people have faced again and again. They are meant to help us divert our energy to solving novel challenges rather than re-invent the wheel.
- They are tools to help us create coherent experiences over consistent experiences. Keeping enough of the same flavours and core philosophies, but allowing variations.
- Anyone who uses a design system has the responsibility to question whether the off-the-shelf solution from the design system is suitable, given the context of their problem. And if not, what might be the adaptations needed to make it work? What that adaption work, or does it need a more tailored solution? Can the problem be reframed, so that the off-the-shelf solution fits? How does it affect the experience and implementation?
Just like the previous article, the thoughts outlined above are a work in progress and are imperfect and not completely thought through nor tested. They are fuelled by my experience working as both a service designer shaping larger services and as a UX designer within delivery teams.
If you’ve enjoyed this article, consider buying me a coffee as a thank you, fuelling my caffeine habit while I write more articles on service design & design systems.
Or if you want to chat or bounce some thoughts on this topic, drop me a message.
Special thank you to the BT/EE Service design team for introducing me to service design patterns during my time there, which spurred some of this thinking.
Complementary reads:
- Brad Frost: Design system ecosystem
- Sparkbox: anatomy of a design system
- Service patterns as a strategic approach for digital transformation
- GDS Service patterns
- FutureGov x Essex Council: Sharing and prioritising our common service patterns
- Davis Levines: Service design patterns
- Using service patterns to improve efficiency at BT
