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)