Big Design, Small Team

Building a Design System on a Budget

Tooling and theory have never been more robust for design groups that want to leverage the power of a systematized approach to creating software. But, for those of us doing the work at fast-moving, growth-stage companies without the resources of a dedicated team, there’s a gap in the discourse: how to move from theory to a built framework.

Design tooling and systems theory are very of the moment. From InVision introducing Studio and its “shared component libraries” to Sketch 47’s long-awaited Libraries feature to Figma’s recent Team Libraries release, makers of design tooling are responding to provocations like Airbnb’s “The Way We Build,” Brad Frost’s “Atomic Design,” and a deluge of Medium posts from designers and devs at companies large and small.

Meanwhile, we’re on the front lines, building out systems and processes to create and manage the atomic parts of our products, so designers and developers can concentrate on creating delightful flows and powerful, performant interactions. We’d like to share some of what Coursera has learned while building out these crucial resources.

It’s all about shared ownership

This was a hard-won lesson. Our previous effort was a collection of type styles and basic elements originally built as a project with a single designer and a small group of front-end engineers. A set of HTML and CSS was produced, but no shared design artifacts were distributed to the team. While this was a good start, having only one designer on the project and no ongoing involvement from other parts of the team meant that there was no energy around iteration and expansion of the library.

In contrast, the proposal for our current project was predicated on the idea that everyone on the design team should own the library. Whether by reviewing work to be added, contributing components and patterns, or exploring tooling to make use and distribution easier for designers and devs alike, there are lots of ways for team members to contribute over time. In any given quarter, there are specific design owners and approvers for the project, but we’re set up to share the load and rotate these roles throughout the team. In this way, we’ve maintained our momentum and continued to create new components while shipping roadmap features on time with high quality.

Find your partner

A library isn’t complete until there’s representation in both code and design artifacts. Our successes have only been possible by partnering with passionate engineers from the beginning.

The current library as manifested in code took shape as a project during one of Coursera’s twice-yearly Make-a-Thon hack weeks. One of our front-end engineers was interested in leveraging React components as part of a design system, and wanted to play with Storybook as a way to share her efforts with the team. Over the course of Make-a-Thon, she was able to build out a proof-of-concept that showed clear common cause with the design team.

Joining forces to evangelize the proposed React component library on both the design and engineering teams in a bottom-up fashion helped both groups create a sense of excitement and anticipation, and helped us to move parts of the proof-of-concept into production. Having collaboration between design and engineering at the individual contributor level led to early wins, helping us prove to the larger organization that the effort required to build out a complete library would be worthwhile.

Get the big wigs on board

We wanted to give the component library a fighting chance by building on the initial results of working with peers across the organization. Prioritizing work that’s not directly tied to a business need or key metric is tough in a growth-stage startup, but we knew that both design and engineering management could see how important having a robust library would be to increasing shipping velocity and UX consistency.

Getting buy-in at this level allowed us to move beyond a guerilla-style endeavor. Our design managers were unsurprisingly all-in early in the game. This helped drive alignment with their counterparts in engineering across the organization, and led to a more formal effort to complete the design side of the library and investigate ways to quickly prioritize build-out. While we haven’t marshaled resources to drop everything to do a “big bang,” large-scale effort, we created a handshake contract to bake in time to create components while building out roadmap features, normalizing the process of designing and coding for reusability and consistency. When we all agree on how to design and build, the library becomes part of the future of our product.

Always be cheerleading!

Preventing team fatigue while trying to work on both roadmap features and a design system is crucial. Tight deadlines and complex new features can sap momentum; keeping the work top-of-mind via constant communication helped us keep the ball rolling. Designers and engineers reviewing new components or investigating tooling for distribution continually share their work with others. We celebrate newly deployed components wherever and whenever possible!

Beyond clear and consistent communication to the larger team, we’re working on developing educational materials to help engineers understand the underlying principles of the design system. Clarifying concepts like baseline grids and consistent vertical rhythm, how typography and white space interact to create information hierarchy, and more can spark greater empathy between functions. The intersection of cheerleading and education helps us sustain the energy needed to keep our project on track.

Building our values

Two of Coursera’s key company values are solidarity and betterment. By encouraging collaboration between design and engineering, building and maintaining a robust and evolving component library as part of a large-scale design system, we’re embodying the value of solidarity. This shared empathy helps us work together even in fast-moving, resource-starved conditions, towards creating a consistent end-to-end experience for all our users, both learners and partners alike. We’d definitely call that betterment. As we continue to learn by doing, we’ll continue to share our learnings so our solidarity and betterment can be yours as well!