There are many who evangelize the value of design systems, but one such article attempts to articulate the value proposition:
An estimated $1.5M+ in annual savings or 21.25% time saved for a typical product development annual budget (based on on-shore/offshore team of 100 resources). --TechMagic, 2018
It seems like common sense that the larger product teams (and product offerings) grow, the harder it is to manage resources at scale. A design sytem (also known as style guide, design framework, pattern library) attempts to reduce burdens, increase efficiencies, and provide a higher quality customer experience. While this resource varies by both scope and context, I have had the opportunity to be involved in three initiatives.
Since design systems have been an emphasis on many teams I work with, the following examples showcase how this resource (and my involvement) has impacted a specific organization:
The referenced presentation for an information architecture conference lays out, among other examples, my experience creating a design system for Blackboard. As a UX Architect, I had a great opportunity to lead the user research and work across product teams to ensure we were delivering great experience. But as teams grew and product offerings expanded, we quickly realized the need to reduce development costs while providing a consistent experience for users.
Working with design and development teams across products, we sought to determine where it was worth initil investment to create reusable code components that can be utilized across projects. In addition, we wanted to use the resource to be a focal point for both developers and designers so that design and development decisions would provide high end user value.
This resource was largely narrative in nature. Meaning, it was a document resource that took time to update. It did not include specific code, but instead referenced code resources. Of note we included some critical guidance to align designers and developers alike, including:
As a government contractor collaborating with multiple contracting organizations to support the USPTO, it became apparent very early on that a design system would help with the coordination across this multi-faceted set of development contracts. I had the good fortune, not to lead, but to play a part in helping with the early formulation of components and what guidance might be needed to include in the resource. Ultimately, this cross-functional team decided to house this resource in Github. I left before it had matured, but the goal was to eventually leverage Github so teams could define a process for pulling and contributing to this resource. Of course the biggest win here was to help multiple contracting companies remain aligned across related projects and to save design and development team and focusing on innovating rather than reinventing the wheel.
A few years after working for USPTO, GSA published the U.S. Web Design System (USWDS). This was an important milestone and made it easier to evangelize the need when working for federal government customers. While working with CMS, many of the teams I supported used, to some varying degree, what was already available to them through CMS' variant of the USWDS. The challenge here was scope. It is one thing for one contracting org supporting one system to leverage their own design system to encourage best practices across the project, but it's a completely different ask to participate in a process that may transcend contracts and vendors. The initiative here is still a work in progress.
So three examples, with mixed results. While working at Blackboard, the guidance from this resource resulted in delivering a "next generation" suite of products that reduced clicks and page loads by ~33% over previous versions. For USPTO, teams more efficiently collaborated and had better visibility across projects. Knocking down silos benefits end users because their experience with multiple systems then becomes more cohesive.
The wild card here is with CMS. At this point, I have not been able to make the case for multiple vendors across multiple contracts work together and leverage and contribute to one design system. Perhaps it is not realistic, but often a government agency driver is to reduce burdens and save taxpayer dollars. While two disparate systems may not need to be the same, leveraging a singular resource could protect individual teams from "starting from scratch" with a new project when a valuable starting point already exists. I'm not giving up. More to come...