The purpose of a design system is to serve the needs of a team, not just an individual designer. You know that creating a design system creates speed, but it’s not simply about the compound effect of cutting down on designer’s grunt work-a design system also removes burdensome communication blockers, and adds speed to the work of the overall agile team, including developers, quality practitioners, and marketing/merchandising teams.
However, the needs of the design system and associated teams are different depending on the size and stage of your business. These needs also evolve as your organization grows, and it’s more than helpful to stop and take stock of where you are.
We discussed this problem recently with our Design to Deliver professional network. In a series of workshops over three weeks, design leaders Roger Rohatgi of BP, KC Wolff-Ingham of Truist, Ben Ceaser of JPMorgan Chase, and Bob Calvano of A+E Networks, sat down with us for in-depth workshops to discuss assessing the maturity of a creative practice, how to grow cross-functionally, and what scaling well looks like.
The result is this simple maturity model. We hope that it will serve as a useful roadmap for practice leaders for growing your design practice, and understanding the larger organizational needs that will allow your team of designers to flourish at each stage of your growth.
Mapping your creative practice maturity
Assessing scale from the viewpoint of the design team, the diagram is set up so that you select the number of designers on your team from the Y axis, then move across the X axis to discover what the needs of the business are at that stage. Maturity is measured on the stage of your design system, the needs of developers at that stage, the number of touchpoints or customer-facing digital products, and the success metrics you’ll use to evaluate performance at that stage.
For example, if you have five designers currently (one squad, per the Spotify model), you’ll see that you’re at the stage where you need to evolve from a simple design language to a more sophisticated design system. The development team, accordingly, will also need a design system to standardize code and contribution to the design system and associated library. At this stage, you’ll likely have two digital products in-market, also emphasizing the need for a design system to keep standards of consistency high between the two products, and your key metric for this stage will be customer satisfaction: ensuring the scores meet and exceed the baseline metrics for your industry and across your competitors.
As a design practice grows, designers should no longer own the design system.
Within this diagram is an idea that might be slightly radical to some: As a design practice grows, designers should no longer own the design system. This is partly because the design system has to become an organization-wide tool, and partly because it becomes more critical for developers to control the inputs into the design system and ensure adherence to the governance model. Iterations in design must correspond with iterations in code, and the development team is better poised to assess if changes or variations within the design system will have a beneficial impact on the end users of the products.
This model is based on the combined expertise and hard-won experience of our group of design leaders. When scaling your design practice, if you fail to follow the steps from Language though to System, Operations and Platform, you stall the efficacy and impact of your scaling and growth efforts. It’s easy to hit a plateau after each stage of growth. There is an uptick in speed, but it inevitably plateaus. The solution is evolving the design system to scale appropriately with the size of the design team and the needs of the developers.
It’s also important to note that there’s a big blocker waiting for you when you’re ready to scale past five designers: Operations. An effective DesignOps practice is crucial at this stage because there is inevitable push and pull between decision-making autonomy for the teams, and the need for centralized decision making on behalf of the customer experience.
These patterns are consistent across industries, and we’ve captured them here in the hope that you’ll be able to use this tool to understand where you are, where you’re going, and what you need to get there. If you’re interested in our Design to Deliver community, please reach out to us.
Originally published at https://rangle.io on May 28, 2021.
