Design systems, it could be argued, are foundational to the long-term success of a company.
Consider what a design system can — and should — contain: a company’s design philosophies, features of a product’s digital elements (from typography to colors to a logo), front-end coding elements, brand guidelines and voice, and much more.
Without this documented source of truth, what’s to keep, for example, one-off alterations to a company’s voice? And how many “one-off” alterations need to happen before unintended changes begin to occur?
Put it another way, “a design system acts as the connective tissue that holds together your entire platform,” wrote design specialist Drew Bridewell for digital product design platform Invision’s blog. Without that “connective tissue,” platforms will unintentionally create operational silos.
But creating a design system is not an overnight process. It requires stakeholders from across an organization to come together to agree on and build a really critical foundation of the business. And, of course, it’s not without its challenges.
In interviews with Built In Austin, design leaders at grocery retailer H-E-B and note-taking app Evernote explain how they implemented their respective design systems, the biggest challenges they faced from the onset, and the processes they picked up to ensure their design systems remain as relevant as the day they were created.
For Skoog and other designers at grocer H-E-B, consolidating all design elements was foundational to building a design language system. “These efforts have helped educate on our design system initiative and build a solid foundation that we can continue to build on,” Skoog said.
In the initial planning phase, what were your key requirements for the design system? How did you determine how you would build it?
In the planning phase of our design language system (DLS), the first step was to decide on the kind of governing model we wanted to employ. After reviewing the structure and culture of our organization with the long-term vision, we decided on a hybrid approach of a centralized team with a federated contribution model. This structure allows a dedicated team to carry the momentum of the work with the flexibility of product squad contributions. Then we looked inward to research and understand what makes H-E-B, well, H-E-B. We wanted our DLS to be a reflection of our values, history and culture. It became apparent that our DLS should ladder up to our core brand.
We looked at our digital org to understand what our users — designers and engineers — need from a DLS. It was essential for our users to retain their creative agency to evolve our products and maintain a culture of innovation and autonomy. To understand the engineering landscape, we looked at our ecosystem of products. A DSL is equal parts design and engineering, so we defined a common language. Our system is built to serve our omnichannel experience for all our digital products to look and feel like H-E-B.
What was the biggest challenge your team faced while building and implementing a design system? And how did you tackle that challenge?
Our biggest challenge was consolidating everything that our team had built before our DLS rollout while shipping new features and patterns. We employed a phased approach to defining foundational elements, including design tokens, colors, grids, spacing, typography, iconography, border radius and shadows.
With the strategy in place, we conducted heavy audits across our apps, the assets designed in our old design tool, and the assets that lived in our new design tool. Once we understood what was there, we began migrating old designs and defining and applying the foundational pieces of our system through design and code. Whole-team collaboration was imperative in this process. Our DLS designers and engineers worked hand in hand to create a consistent solution across all designs and platforms. To help increase adoption of the new DLS, our engineers created linting tools, migration guides, general documentation and established a deprecation process for phasing out old components. Our designers held design education sessions about new workflows, styles, and components. These efforts have helped educate on our design system initiative and build a solid foundation that we can continue to build on.
Whole-team collaboration was imperative in this process.”
What processes have been especially useful for keeping your design system relevant, up to date and/or bug-free?
Because our digital experiences were built before we kicked off DLS, some components and styles were created naturally and iteratively over time. We used these existing styles to create our base-level styles. Then, we created a second set of styles based on use in existing components.
Migrating to a DLS involved constant collaboration and support. To facilitate this, we set up office hours and encouraged designers to “visit” and bring designs for DLS guidance and recommendations. Office hours is still something we do each week. It allows us to further validate our approach and make improvements in real-time based on user needs.
Another critical part of migrating to our DLS was defining a process to deprecate older styles in our code base. In addition to code deprecation, it was important to provide documentation to show engineers how to migrate their code using the new design system. We frequently communicate with our entire team to notify them of upcoming focus areas and updates to the DLS. When we make a change, we reach out for input to ensure that engineers and designers feel like peers whose feedback is important to help shape the future of our DLS.
“Designing a [design] system at scale is challenging,” Fortin, the SVP of design at Evernote, said. Considering that millions of global users use Evernote, the team realized that it needed a system that would seamlessly fit into stakeholders’ workflows and make it easy to make good decisions.
In the initial planning phase, what were your key requirements for the design system? How did you determine how you would build it?
First, we focused on our existing users, their goals, and the need to deliver a more coherent experience across the various devices used to access their information. This required extensive user research and a comprehensive audit of the current experience to identify and eliminate arbitrary differences across the desktop, web and mobile apps.
Second, we looked for opportunities to streamline, sharpen and modernize the aging design language, not just to deliver a more clear and compelling experience for our existing users, but also to provide a more approachable and accessible interface, particularly for new users.
Finally, we prioritized focusing on opportunities for innovation to ensure that we were not just incrementally improving the past experience but also moving the design system forward on a path to invent the future of the product. This included new patterns for suggestions and filtering in search, a completely redesigned and better-organized Note Editor, and a brand new home screen that brings everything together into a helpful, customizable place to start getting things done.
What was the biggest challenge your team faced while building and implementing a design system? And how did you tackle that challenge?
Designing a system at scale is challenging. We needed to converge five very different expressions of Evernote (each individually tailored to the web, Windows, Mac, iOS and Android platforms over many years) into a more coherent, consolidated and compelling approach. Given the tens of millions of active users accessing Evernote from almost every country on the planet, and the diverse set of essential use cases involved, almost every decision we made represented a change or a trade-off for a significant population of people.
It was critical to test our assumptions continually throughout the entire process, integrating data from user research, beta programs and analytics. We also found it helpful to clearly define who we were — and were not — designing for. One of the biggest challenges our team faced was navigating the tension between the majority population of new or more casual users who prize ease of use and simplicity compared to the minority, yet highly-valued group of long-time users who demand maximum efficiency and flexibility. For us, optimizing the system defaults for the former and accommodating the latter with shortcuts, settings and advanced options has generally worked best.
It’s a hyper-pragmatic, incremental approach that results in a living design system.”
What processes have been especially useful for keeping your design system relevant, up to date and/or bug-free?
From the start, it was critical to avoid spending all of our time on documentation at the expense of turning ideas into shipping software. To this end, we were not looking for a pretty document that we could showcase in a blog post. Instead, we needed a system that fit seamlessly into our workflows and made it easy to make good choices and harder to make bad choices. Because of this, we decided not to form a centralized, dedicated design systems team to document decisions in isolation.
With a team of fewer than 20, it made more sense to develop a mechanism to review, debate and align on best practices utilizing the very designers working in the trenches every day to solve problems. Rather than trying to imagine all of the possible applications and solutions upfront, we instead capture what works best directly from the work-in-progress itself. These guidelines and patterns are documented as part of the same process and in the same software that we use to explore and visualize solutions, which helps us to avoid disconnects and distractions. It’s a hyper-pragmatic, incremental approach that results in a living design system that reflects what truly works and gets better over time.
