Introducing Business Design Patterns
What they are, their ROI, and further considerations
Like most designers these days, we rely on our Design System’s existing assets and guidelines to reuse in our designs. With these patterns we can easily share well-tested ways of solving our user’s needs, speeding up both the design and development processes.
As a design team that covers the entire Corporate and Investment Banking business design needs at Societe Generale, we started to notice recurring business needs that can be solved in a similar way in digital products. So it became a habit in the team to check with other designers if they have explored the same business use case in their projects.
Just like how our guidelines solve user needs, we used the same thinking to start developing Business Design Patterns (in short, Business Patterns), reusable solutions to business use cases.
Business Patterns: an example
So what kind of patterns come from the business side? Let’s take the “4 eyes check” as an example.
A 4 eyes check process is used when a sensitive action requires the confirmation of a different person than the original user. This is regularly used in the enterprise world, and aims to limit errors that can have large impacts such as incorrect amounts inputted or data breaches. To be efficient, the process has to show the risky areas of the content created, and also has to highlight the errors raised by validators to streamline communication.
When a new project I was working on needed a 4 eyes check, I checked (as usual) to see if there was an existing similar design. There was! Reusing the design from another product saved a significant amount of design time so, for the future, instead of having to ask around we could instead formalise this use case into a Business Pattern, with usage guidelines, business rules, associated UI, and even code examples.
Although I knew I was saving time reusing 4 eyes, we still had to see how useful this approach was, so while working on the rest of my new project I had a side mission: see how many business patterns apply, and asses any benefits.
ROI in practice: savings and re-investments
My method for the study was to inventory use cases coming from the business side, estimate how much of the design workload they account for, then see if they have existing examples across our other products. The estimate considered the time for initial research, high fidelity prototyping, specifications, and user testing. The results? I saw that for this project around 80% of the design workload could be found in use cases from other products.
Not only did I see that reusing these patterns could save me a lot of design time, but I could be confident using them as I could also see the research/testing behind them, and the feedback from real users. Thanks to re-using existing patterns (even though they were not formalised or documented), I can safely say that I was able to design most of the screens faster.
Avoiding the “magic solution” trap
After sharing the results of the study around our team (and presenting it to business stakeholders, including our COO!), a few common questions jumped to mind, especially after seeing that up to 80% of a product can be built using existing work:
When should we use a pattern and when should we not?
Even if a pattern seems straight forward to apply, the pattern shouldn’t just be reused blindly — we still went through our standard scoping, focusing on the initial concepts with advanced user flows and wireframes.
Without this initial work, imagining the product version and concrete pages/features for applying business patterns would have been impossible. We have to make sure before we apply any pattern that we’re scoping PROPERLY.
Then when actually applying the Design Pattern, it’s not a template. Designers must still respect the overall design consistency so information hierarchy or familiar interactions aren’t disrupted. This is why Patterns can focus more on the guidelines of how to solve their associated problems, instead of just templating UI components.
How do we keep evolving these patterns?
The answer to this one is fairly simple — but it requires work and care.
Getting real feedback from users (via both specific testing & general feedback) is essential to make sure a pattern is actually solving its problem. This feedback must then be integrated and ‘fed back’ into the pattern. It takes work to keep the patterns alive and maintain all of their assets, but once feedback loops are established and the Patterns are formed, continuous improvement will only increase reusability.
What about creativity?
Design Systems face this question constantly. Business Patterns are not a shortcut to save you from having to think about what you’re designing. In fact it’s the opposite — they should just give you even more time to think about what you’re designing. More time to work on scoping, research and testing. Focus on the user, and what’s best for them.
Wrapping up
The study confirmed our initial assumptions. Business Patterns help projects identify tested and effective solutions for well-known use cases. Their benefits are not just time-saving or error limitation, design consistency improves the overall user experience across products belonging to the same universe.
So if you face a business problem and you think “Ah, this might have happened before…” there might be a Business Pattern to reuse from another project. And by business pattern, we precisely refer to a set of design system components and functional rules, used to answer users’ needs in a standardised way.
This (Design) System led thinking that led us to creating Business Patterns is an example of new ways for us to work, with systemic patterns and system thinking at the core of our work at scale, across multiple businesses and services.
Additional editors: Henry Daggett and Morgane Peng
This article is the first of our Blending Systems series. Catch Morgane Peng’s keynote at Intersection conference on 26th September for more!
