Building a design system without a design system team | by Andrea Nguyen | Mar, 2023

Design system governance and processes at Foursquare

Design systems and Foursquare have had an off and on relationship for a few years, predating my time here. Through a series of mergers, Foursquare was left with a sizable portfolio of products and multiple design systems to accompany them. But with a combination of new feature launches and a lack of inter-product and engineering team communication channels, the design systems grew to become more individualistic than unified. This led to several different brands living under Foursquare, inconsistent UI/UX across products, and inefficient product workflows.

In Q2 of 2022, we had a choice to make. Should we continue to operate under these present conditions, with projects having a tendency to move slower than we’d hope? Or should we attempt to rectify this by building out a new system that would unify both the design and component library used across different product teams, which is critical for building consistent and efficient products?

How many designers does it take to make a button? We found out the hard way when we first started working on our design system (called Cupcake, by the way). First, each of our 6 designers audited their respective products for all of the different buttons that they had scattered across their UI. From there, we reviewed all of the different variants, and came up with a design, together. Everyone had a chance to voice their opinions. Then we went back and plugged the new button designs into a few pages of our products to see if we could identify any edge cases where the design didn’t work (e.g. broke the page layout, looked funny). We waited a week for our next meeting where we came back together and aligned on the feedback. Then we updated the button, and repeated. At last, we had a design.

Amazing collaboration, discussion, stress testing… only, it took us 3 weeks! So if it took us that long to design a button — one of the simpler components — how long would it take us to craft the more complex ones?

While the collaboration and feedback cycles we went through were useful, a couple of things slowed us down:

1. Hearing other designers’ feedback is critical to building a successful design system, but when there are too many cooks in the kitchen, it can be difficult to make decisions effectively.
2. Restricting the feedback to meetings that occurred once a week or every two weeks served as a blocker in the design process.
3. Roles weren’t clearly established, so it was difficult to understand who was responsible for what.

With the learnings from the first component, it was clear that we’d need to invest time to build a governance model and processes early on.

In an effort to minimize and streamline blockers, our design director saw it fit to establish a point person (me) for all design work. It’d be my responsibility to design components, document, and work with engineering partners to build and release. Another designer was assigned to port everything over to our design asset manager (website) — our single source of truth. And finally, all components would go through our design manager for approval before entering the ether. It’s important to note that nobody worked on the design system full time.

Working in Sprints

Having to split my time between Cupcake and other product work, I found it effective to work in two week sprints until I could design a majority of the simple MVP components. These were components that already existed in the products, but weren’t yet made into reusable components that could be shared. This process would start with story pointing my product work first. I’d also story point the work involved in designing and documenting each component for the design system. Then, I’d pick up components based on my remaining bandwidth. Sometimes, other designers would have the ability to pick up components too. As long as they went through the proper design process, and components were built consistently, it was a non-issue.

But what about components that didn’t exist yet?

We’d have to come up with a new design that fit Cupcake’s pattern guidelines, build in responsiveness, test them, gather feedback from stakeholders, and ensure that they’d work across multiple products.

I quickly found that, between my product work, catching up on old components and working through new components, my workflow wasn’t sustainable.

So I designed a new process with the goal of delegating some of the work to the other designers on the team.

The prerequisite was that designers had to ensure they’ve exhausted all of their options using the existing components before requesting a new component or variant.

For new components, they needed to think about the following questions:

1. Would other teams benefit from this component?
2. What options did you try with existing components and why didn’t they work?
3. Has this solution been tested?

For new variants, they’d answer:

1. When would you use the existing variant versus the new variant?
2. Can you show me an example of where this new variant would work better than the existing one?

After reaching a consensus that the new component or variant was needed, we made sure that the following steps adhered to our process, which included:

• Creating a Jira ticket
• Designing a first pass of the component and testing it for usability and effectiveness
• Gathering feedback for said component at design crits
• Iterating upon the feedback

From there, the ticket would get reassigned to me, so that I could “fit” it for Cupcake. This would typically entail removing product-specific data, designing for additional use cases, and writing documentation for its application and development. Finally, the component would make its last round of review through our design manager before hand off.

Development Hand Off

Component development was owned by the Solver team, which was made up of engineers from different product teams who volunteered to help with Cupcake. But much like our design team, engineers were faced with their own challenges including conflicting product priorities, staggered sprint dates, and limited bandwidth. Thus components were picked up and built sporadically, based on product needs.

Without dedicated development resources, the best we could do was claw back time from product sprints to build and integrate the design system. Components that were needed for current feature projects were prioritized first.

This process needed a lot of TLC. As I mentioned before, the momentum for building components was slow due to lack of prioritization and resource dedication. The button, for example, took us over 8 weeks to develop and launch. Often, engineers from the Solver Team wouldn’t even have enough time in the sprint to build out all of a component’s use cases, leaving some components half built until another team could pick up the rest of the work. We couldn’t plan releases or deliver predictably.

We would need both the product and engineering teams to commit time to the project. One way that we ensured that time was allocated for design systems work was by writing product initiatives for it. This allowed product teams (and their respective engineering teams) to plan around the design system at the beginning of each quarter. This partially worked, but we still needed more resources and commitment to get to a place where the design system was more helpful than burdensome. With 40 components to build, we knew that this workflow wasn’t sustainable so we actively looked for ways to increase bandwidth and push for resources for Cupcake.

But that’s a story for another article.

Like any other product, we went through many iterations and stress tests before establishing these processes. And yet, they still change frequently as we run into new issues that we hadn’t anticipated.

To conclude, I want to call out the takeaways that I found most important from this experience.

1. Do not underestimate the amount of effort and the importance of selling your design system through. I had to schedule dozens of meetings with product managers, engineering teams, and executives to gather buy-in for the system on top of designing the system itself. It takes up a lot of time,
2. Eventually, you will need resources. While we made some unprecedented progress with the design system and figured out ways to create bandwidth for ourselves to work on it, it’s clear that over time it’ll become unsustainable. Design systems are a full time job, and we can’t expect our teammates to keep volunteering their time forever! So continue pushing for resources and looking ahead to the future. Think long term.

Design systems are a relatively new topic, so it’s hard to find information about the stuff that’s behind the scenes — structuring teams, creating processes, and managing communication. To add fuel to the fire, what works for one team may not work for another. The truth of the matter is that a lot of organizations don’t have the luxury of having a dedicated design systems team yet, Foursquare included. So this is what’s working for our design team right now. Hopefully you’ll find something useful here for yours!