Design systems at scale
How to tackle main challenges in design system adoption in complex products development workflows with a responsive design organisation.
Since I joined BPCE, second french banking group with roots in a two centuries old financial institution, I have dedicated a large part of my time insuring the quality of the digital experiences delivered to customers.
Indeed, ability to deliver great digital user experiences at reasonable costs and schedules is critical for the organisation’s digital transformation just as it is for its competitors.
Execution is key. Bad execution can obliterate all the efforts and spendings in the release of a product. No surprises here : inconsistant and unfinished user experience prevent conversion or user adoption.
Larges organizations processes involve internal or external services providers, teams located in multiple localisation or cultural differences. It makes adoption of common frameworks for design and development harder.
In this kind of environment, design systems are triggers for change. Not only for the user experience but for the organisation.
Design systems challenge existing routines and process. They push boundaries between silos of expertises and responsibilities. They go beyond the product design framework they first intended to be and contribute to define the organisation itself.
As organisations transform, the implementation of a design system is a strategic plan and may go through phases. Starting from a first repository of visual assets shared among designers to an integrated framework connecting all technologies and expertises involved into product design and deployment.
So far, I have been confronted with three main models in the companies I’ve been working for. I think each of them reflect company’s digital maturity, goals, culture or the complexity of its supply chain. They can also be seen as indicators of company user experience maturity. But organizations are not static, so they can also be phases. Steps in a design transformation strategic roadmap.
In an essay on the diversity of designs systems implementation Nathan Curtis defined a visual vocabulary to illustrate the many forms taken by design systems. It was a very interesting exercice revealing invisible organisations behind the product. I conducted a similar exercise in order to show how design systems fit into the companies workflows and how they spread along the product development processes.
Keys for the following diagrams
1. the UI studio
UI components and UX patterns are shared among the design team and the design team only.
This workflow looks very close to a waterfall model : A team of senior projects designers (product design team) delivers wireframes and a set of nominal screens (specifications). A team of ui designer (UI studio) manages the delivery of all UI specifications and packages of assets for the development team (Factory) working in traditional IT delivery mode (no incentive on user experience quality and no recognition of the frontend dev expertise).
GOOD FOR
- Not yet mature organisation
- Standalone projects
PRO
- Resilient
- Accelerate design delivery
- Facilitate focus of product designers by moving asset production to a dedicated team.
- Creates a buffer between User Experience & development teams and prevent designer burnouts
CONS
- No capitalisation on the work done on development side
- Doesn’t support a mutually beneficial conversation between tech and design
2. Industrial
A prototype is designed and developed in agile mode by a versatile team. Then the code is used as very detailed specification by the team or services provider in charge of the development and release of the final product.
Design system is shared between designers and a smaller team of expert frontend developers (frontend dev) in charge of releasing a prototype of the product. Final coding and delivery is still managed by the factory.
GOOD FOR
- Industry
- Complex Supply chain
PRO
- Maintain an existing contractual chain
- Set clear responsibilities between parties
- Prototype built in agile mode can be used to validate the user experience with a good level of confidence before the product is sent to dev
- Code is the best specification
CONS
- Design has a small control on the last phase of the development
- generates a huge amount of documentation
- More expensive
- Time consuming
3. The design ops
The design system has a dedicated team of designers and developers. Fully integrated into the workflow. It is both a repository of design assets for designers and of front end components for developers.
Design and development sections of the design system are fully synchronized. Designers contribute to the design side of the system. Developers contribute to the technical side in a very iterative and inductive process.
Basically the model of all advanced design systems : one system with two faces. Each one dedicated to a different audiences.
PRO
- Streamlined workflow
- Best control of the user experience delivered
- Design system is a common asset providing value across all projects
- Accelerate deployments of evolutions across projects
CONS
- Challenging for legacy organisations where it is not natural to invest in user experience and to facilitate informal communication between project management, design and development.
Conclusion
On the tactical side many references and guidelines are available such as Brad Frost’s “Atomic Design” which teaches how to set up a design system from elementary particles to higher level elements. Or Multi-authors and inVision supported “Design System Handbook” provides very useful tips from where to start, how to build and expand .
In complex organization however, following the instructions is not enough. Trying to implement, short term, a model that doesn’t fit could even be counter-productive. The more a design system is integrated into the product delivery sequence, the more efficient it will be. Ambitions must take the context into account, and be supported by a strategy.
