Financial institutions largely recognize the appeal of implementing a design system, either within specific products or across the entire enterprise. Instituting a consistent and canonical set of principles throughout an organization’s use of styles, themes, interaction patterns and motion design across their application estate can increase developer productivity, improve user experience, and enhance brand recognition.
The business case for investing in design systems is a more complex discussion. These can be capital- and resource-intensive projects with a wide range of potential pitfalls. There are few obvious metrics for demonstrating direct return on investment from a high-quality user experience. Too often organizations make large investments in a new system to optimize productivity, only to see limited adoption and minimal impact on processes.
Knowing what good looks like is therefore a key precondition for securing backing for a new design system. But the margins between success and failure can be slender. Financial institutions face a series of ‘sliding-doors’ moments when deciding how to define, invest in, govern, drive adoption of, and manage the project. Right or wrong turns at each of these successive forks in the road can make the difference between a small investment yielding large adoption and increasing productivity, or the complete opposite outcome.
A tale of two design systems
In one hypothetical scenario, our bank is focused on the wrong outcomes from the project from the outset. Rather than seeking to establish the first principles of how design flows through all its digital assets, the bank cuts straight to what should be a third-order derivative of the design system. A new component library, which comprises the code implementation of individual design elements, takes on an outsized importance in the thinking of the project team.
In a parallel universe, the same bank avoids getting lost in the weeds of the constituent parts it will need to subsequently build. It instead engages in the high-level work required to understand the overall design system, how it will gain adoption with a target population, and how to incrementally support the needs of the enterprise as a whole. The project team plans to develop a supporting style guide that defines the topography and styles within an application, and then a pattern library of non-UI technical descriptions of individual elements of the style guide, and then finally a component library, only once this has been completed.
Right or wrong turns at each of a series of forks in the road can make the difference between a small investment in a design system yielding large adoption and increasing productivity, or the complete opposite outcome.
The bank of our first timeline, burned by a previous experience of investing in a small, centralized team whose work gained little traction within the organization, opts for a broader-based, grass-roots, ‘bottom-up’ approach. The developers who initiated the conversation after discovering they were duplicating efforts are given a budget and timeframe to get a new design system up and running. The majority of work takes place in their spare time, but this is extremely limited and, most importantly, not scalable. Allowing those leading the project to determine when they can work on it, without explicit support from management, proves a major constraint.
The lack of coordination with or involvement of the bank’s design team also compounds the project’s narrow focus on building a component library. And the likelihood of these components being configurable with multiple other use cases is remote, restricting the prospects of widespread adoption.
In our alternative scenario, the bank makes another good choice by merely tailoring its previous ‘top-down’ approach to developing the system, rather than abandoning it altogether. A designated group of designers and developers are given a strict ‘common where possible, custom in extremis’ mandate. This means that deviations from prescribed design and development standards are permissible, but need to go through a simple process that verifies the need for customization. The rank-and-file engineers and designers retain ownership of the scope and direction of the project, garnering their interest and mitigating negative perceptions of the system as a creative constraint.
The workings and governance of the bank’s two parallel design systems are very different as well. The first, already beset by problems, is disadvantaged further by a lack of communication between designers and engineers, who operate in separate, siloed teams. A developer tasked with building an app receives a series of screens – perhaps delivered in PDF format, or at most as a source file in design software – with no further guidance. From the designer’s perspective, they are simply operating within the agreed design system. The developer’s experience, however, is one of having a product thrown over the wall for them to deal with, because the new design system is set up to treat the design and development phases as discrete and independent.
The second project goes from strength to strength by organizing the design and development process to accommodate interdisciplinary collaboration. Developers don’t have finalized, sleek, visually consistent screens just dropped onto them, with the expectation that they then work out how the application will function. The design team instead works with the engineers to understand common requirements and converge on a common solution.
The bank makes a good choice by tailoring its ‘top-down’ approach, rather than abandoning it altogether. A designated group are given a ‘common where possible, custom in extremis’ mandate, meaning that deviations from prescribed standards are permissible, but go through a process that verifies the need for customization.
Divergent outcomes
The two design systems produced by our bank in these parallel universes will inevitably differ radically in terms of quality, speed of execution, traction, future possibilities, and return on investment.
The former approach risks producing a component library disguised as a design system. Without top-down oversight, the project leaders will likely have gone in different directions and discarded pre-existing standards and templates as unfit for purpose, harming prospects of broader adoption within the organization and the promise of a unified experience for end customers. The components will be configurable with a finite number of use cases. And no matter the quality of the design thinking involved, time spent building something that doesn’t see the light of day is time wasted.
The latter approach to rolling out a design system offers a much stronger basis for success across the board – subject to an important caveat. Even when perfectly executed, a design system needs to be understood as a means to an end, not the end in itself. It is an evolving, ongoing process that needs to be actively managed by product managers and stakeholders. Their job is to ensure that the bank’s brand and user experience principles can continue to be consistently and practicably transposed into new applications on an ongoing basis.
Translating success into investment (and vice versa)
Either scenario exerts a vicious/virtuous circle effect on providing return on investment and securing future backing. Limited traction and an unreceptive culture acts as a natural inhibitor on scaling the design system further across the organization. Increased productivity among developers and high levels of adoption builds momentum for further investment.
The best-practice principles for building design systems, the metrics for measuring their impact, and the complexities of making the business case for investment are therefore all closely connected. Yvonne Caravia, Lab49’s Global Head of Product Strategy and Design, will be speaking further on the topic on a FinJS virtual panel discussion on ‘Measuring the Impact of Your Design System’ at 9am EST on November 17th. You can register to watch the event here.
