Cooking up ezCater's Design System
Can we build a design system from scratch in only 12 weeks?
Context
ezCater, a two-sided marketplace for restaurants and catering buyers, had multiple products, each with a unique visual style. One product had three different codebases, and while teams tried to keep each consistent, the visual styles of each codebase started to diverge. Teams were rebuilding multiple versions of a single element. Our sketch libraries were basic and cobbled together by designers working in their spaces. All of this led to designers spending time creating things from scratch and engineers implementing those things slightly differently. Ultimately, the users of ezCater suffered for it.
Proposal
My team set out to propose a design system to solve the problems the organization was facing. To present a compelling business case, we surveyed PMs, engineers, and designers on squads across the organization, measuring how much of their time was spent on problems we suspected the design system would solve for. From the results of the survey, and using an average dev team’s weekly cost figure provided from leadership, we estimated that the waste in our current process was costing ezCater ~$600,000 per week. We pitched to senior leadership and were given a 12-week runway to deliver the most value and solve the most pain.
Research
We looked externally to see how other organizations approached their design system structurally and philosophically, while auditing our current products to understand what components would be necessary for the design system to have parity with 80% of our interfaces.
We also explored upcoming projects on roadmaps and any corresponding design work to understand any gaps we’d need to fill by the time we would roll the design system out.
We listed all of our components out, prioritized them, and planned out what sequence would give us the best results in 12 weeks.
Implementation
I led design work for all new components and began creating a library of Sketch symbols for teams to start using. I worked with design leadership and our procurement department to make the case for and purchase Abstract to help our design team manage our files and the centralized delivery of our component library.
As I completed a component, concept, or family of components, I’d write guidance and engineers would build behind me while I moved on to the next set. Not all of our components were atom-level, we included components for a couple of key organisms and templates, too.
During the incremental roll out of design components in Sketch, I’d observed designers struggling with some higher-level concepts that, while we didn’t yet intend to codify, we wanted to have an opinion on early and watch how teams ran with those concepts. This meant exploring the effectiveness of those concepts, from a visual, system, and accessibility standpoint.
Results
After twelve weeks, we launched our “core” design system to half of the teams to see how using it would affect their output. We worked closely with team engineers and designers to help answer questions, iterate on rough edges that we observed, and started creating a list of feedback to triage and implement if the project was a success.
We surveyed both halves of the tech organization to compare how the design system was affecting teams’ day-to-day.
3
Hours saved
On redundant front-end tasks compared to teams not using the design system.
We had positive qualitative feedback from teams on both the benefits of the design system along with enthusiastic and constructive feedback on how it could improve or what was missing.
The company agreed to make my team a permanent design system team, and we set goals for our next major version:
- Expand component coverage to a bar we felt was “complete”.
- Begin the transition from a centralized governance model to a more federated one.
- Create better guidance and organization for designers using the sketch libraries.
- Get one of our products to be fully using the design system.
- Use the foundation we’ve built to give our products a brand refresh and visual design overhaul.
Challenges and Learnings
There is tension between a team meeting their own individual metrics and contributing to the design system, which doesn’t directly move those metrics. We planned to make it easier for teams to contribute when they encountered something that wasn’t in the design system to help reduce that tension, and began positioning this work as proactively avoiding tech debt: as components are updated you reap the benefits of not needing to maintain them over time.
Good documentation was worth the time investment. For features where we tried to be scrappier with the amount of guidance we provided, we noticed more questions or people reaching for them when other patterns were better suited for the task. While there will always be a balancing act between time invested in writing documentation and output, biasing towards better documentation (and ways for designers and developers to consume it in more organic ways than searching a documentation site) will yield better results.
Legacy products that used pre-React codebases were a serious challenge. We began to investigate the cost of rolling out a native HTML/CSS/JS version of some components and compare that with the timeline and cost of rebuilding or replacing the legacy interface.