Tips on building and growing a design system from Cody Fitzgerald
Meet the members of DocuSign’s Product Experience team who are shaping the future of agreements
Design systems bring many advantages. Particularly to growing teams, like DocuSign! As DocuSign has grown in complexity, so has the need for a useful design system to help keep our user experiences consistent.
Over the past year, our design systems team has been hard at work creating a new design system to support and modernize our growing suite of products. If you’re a DocuSign user, you may have seen glimpses of our new look and feel, or will soon!
However, design systems can be challenging to set up. To help others in the field establish and scale their system, we interviewed one of our design system experts, Cody Fitzgerald. In this interview, he reflects on the benefits and challenges of creating and governing our new design system in a way that will help product designers and developers become more efficient and focused on elevating the customer experience of the entire DocuSign Agreement Cloud.
Let’s meet Cody!
Hi Cody! Tell us a bit about yourself!
I’m a designer in the Seattle area working alongside a team of incredibly talented individuals to build DocuSign’s next design system, Ink. When I’m not in the middle of component specs or platform discussions, I’m relaxing with my dog, Snickers, looking for new spots to photograph, or listening to some lo-fi sci-fi while I doodle in Photoshop.
What led you into systems design?
I worked as a graphic designer for about a year and a half before I transitioned to a UI/UX role. I worked at LinkedIn as a part of the Design System team, which, at the time, focused on a wide range of projects beyond the design system. What I loved about the system itself was how simple pieces and shapes culminated into complex organisms that were then assembled to create products that had a real impact on people. I was also captivated by the challenges of bringing the brand strategy into the product in a way that was flexible enough for hundreds of designers working on different features to use.
I spent the next few years learning about building foundations and components, implementation strategies and roll-outs, and juggling the complexities of aligning an existing design system to a new brand. Coming to DocuSign gave me the opportunity to apply all of these learnings to help craft a design system that would support a fast-growing team and an even larger platform.
How would you describe a “design system” and in what ways have you seen them provide value to teams and organizations that invest in them?
I’ve seen design systems described in dozens of ways, but I personally think of them as the starting point to building better products, faster. When you commit to a design system, whether you have one team focused on one product or thirty teams focused on a suite of products, your investment pays off in the way of capturing decisions that establish consistency and generate efficiency. A product designer can trade the time that would be spent on choosing button colors for time spent on better optimizing for a particular user challenge. A developer can scope more meaningful work because the design system delivers more efficient code and design tokens. Product managers can harmonize solutions across product areas because the foundations of how the product operates at an atomic level are established.
What signaled the need for a new design system at DocuSign?
Our marketing team had developed a bold new look for the company’s external brand, but our products were trailing that visual evolution. Additionally, our existing design system was hitting its limits as a CSS library with few foundations in place and no mechanism to scale efficiently.
Where did you start to create the new system and how did the process evolve over time?
Since we were building a new library on top of an existing one, my first goal was to understand how teams were already using the design system, the challenges of working with it, and the hopes they shared for the future. Many of the challenges were rooted in the lack of solid foundations from the design system, so that’s where I focused much of my attention in the first phase. Our team developed a compliant color system, typography scale, iconography language, and spacing systems.
After we had the foundations in place, we started building our component library. This involved looking to other systems for inspiration and focusing on the unique problems DocuSign needed to solve for customers. We took an approach of “build 20% of the library that covered 80% of our product use cases,” which helped us narrow our focus on critical components that were used throughout the entire DocuSign product suite, including buttons, text inputs, and selection controls. As a team of 5 supporting 13 product teams, this allowed us to stay nimble and handle other aspects of building the new system such as design tooling, documentation, and product application.
We also focused on providing strong baselines for the component library to support elements of the system, such as accessibility and localization. Each component spec contains sections tied to accessibility and localization that allow component authors to detail how the component should behave and facilitate more detailed conversations with developers during implementation. We involved these teams in component reviews to ensure we were delivering on key features such as screen reader and keyboard capabilities, color contrast, and responsiveness for situations like browser zoom or text translation.
What was the biggest challenge you encountered while establishing the new design system?
One challenge we faced during the initial construction of Ink was keeping product designers in the loop on the construction of the system and the decisions and rules that governed it. To address this problem, our team created what we called “component pop-ups:” informal sessions that any member of our Product Experience (PX) team could attend to learn more about the new components, see them applied to new features, and provide feedback or ask questions. Each session was run by the component author from the design systems team, allowing them to absorb feedback first-hand and expand on design decisions made throughout component development. Along with a follow-up survey, this forum provided our team with invaluable feedback on highly desired component properties and helped us understand what product design teams needed to support and delight the customers they design for.
Now that the foundations are in place, how does the systems team govern and expand Ink?
Our design system relies on a fusion of central and federated models to continue to grow efficiently. On one end, a core group of individuals who are dedicated to the craft, maintain the library and define the “natural laws” that govern the system. In addition, product design folx apply the system to real applications and identify gaps in coverage or opportunities to expand the system.
When new components or adjustments to components are needed, product design teams can file tickets in Jira and vote on improvements they want to see. The most important aspect to any enhancement, especially a new component, is that it can be broadly applied to multiple product areas.
We also have a multi-tiered design contribution workflow that looks at a set of criteria and places designers on the most efficient path to create new components based on the desired outcome and their users’ needs. We’ve seen some great contributions from teams around components and design patterns, and we anticipate more will come as additional projects apply the new design system next year.
In addition, we maintain a shared component library that allows design and engineering teams to guest develop more complex components or organisms. This library is great for building on functionality provided by our core library and allows us to provide a bit more specificity to components, like applying type-ahead to a text field.
What advice do you have for teams who are setting out to build a design system?
- Communicate as often as you can. So much of building a design system is relationship building across different people, teams, and organizations. Being able to communicate the system’s goals, progress, successes, and failures becomes crucial as the system starts to mature.
- Spend time to develop principles that guide your design system. Use these principles to establish your foundations, then use those foundations to build your components. Having principles the team is committed to will help guide every aspect of the design system, from how you define colors and build components to how product teams layout pages and establish patterns.
- Listen to your adopters. Use the feedback you receive to inform where you make impact with the design system. Focus on ensuring everyone feels invested in how the design system is applied and how it grows to face new challenges.
- Make informed mistakes and learn from them. The beauty of design systems is that they’re in constant evolution. When defining any aspect of your design system, make a decision based on the available information you have, but be comfortable with the fact that it may be the wrong one. Understanding why those decisions were made and learning from the outcome will organically grow the system into the best possible version of itself.
Want to learn more about Cody? Connect with him on LinkedIn.
👋 Want more from the DocuSign PX team? Follow us on Medium and on Dribbble. Want to work together? We’re hiring!
