Update: I changed the title of this post from “Design Systems for Small Teams” to “Building a Design System Without a Team.” This is a more accurate description of the content of this post and addresses the key issues: building a design system when it is impossible to dedicate full-time resources.
When a new design system is announced, I’m right in there with everyone else, digging into the public documentation website, examining the versatility of their responsive assets, clicking through to examples, and, of course, visualizing my own team’s ability to do the same. But the shine wears off quickly and it gradually seems impossible.
Looking at design systems from AirBnB, Google, IBM… Eventually, there’s a wake-up call: You’re not in the FAANG. The design systems you’re looking at online are built by dedicated teams, specialists hired to do that work. They develop specific skills and processes, whether they are full time members of the team or agencies with highly capable teams of their own.
If you are on a small product team, it is unlikely that you are in a situation fitting the above description. You’re more likely to be generalists and stretched thin.
If you maintain the expectation that you will be able to deliver what those big teams deliver, at the same cadence, and in the same manner, you’re going to have a long string of bad days.
How am I going to pull this off with 20% of one designer’s time and sporadic development commitment? We can’t be this detailed or specific or thorough. We can’t dedicate a team to the design system. We don’t have engineers dedicated to the design system. We can’t even fully dedicate a designer to the design system. We don’t have a ‘design ops’ person, let alone a team.
Your Responsibility
I’m speaking here to design leaders. That may include senior IC’s. That may include management-only types. But If you’re someone who takes on the design system project and helps define the process and infrastructure for creating and maintaining that system, then I’m talking to you.
For the sake of this discussion, a design system lives in four places:
Design Assets: The library of assets that designers use in their work in accordance with the design. Sketch symbols, Figma components, etc. These tools are specifically for the design team.
Codebase: The front-end code base, that lives actively in production that executes the design ecosystem, reflects the design tools. This is specifically for the engineering team. Naturally, in organizations where designers also code, there can be relationships drawn for collaboration & contribution, again depending on the team’s dynamics.
System site: A realization of the design ecosystem in the format of a publicly accessible site. This tends to include visual examples and code snippets for each component. This also reveals the taxonomy and hierarchy of components, along with the intentions and limitations around their use. There are ways to split the responsibility for this between the design and engineering teams, depending on the team’s dynamics.
The design ecosystem: devoid of medium, this is the set of rules and guidelines made visible that define the brand, product, and resulting experience. The design team owns this, in tight collaboration with stakeholders like content strategy, marketing, leadership, etc, if your company has each of those.
A functioning, living, breathing design system will be realized through the creation and maintenance of these four things.
So, what first?
While you may not be able to commit a full-sized team to the effort, the system will need an owner, an individual contributor on the team who can be the steward of the system for the long run. This does not mean they need to be the final arbiter of what goes in the system, although that can help a lot. On my team, it was our intrepid designer Mai who took the reins.
Out of the four concentration areas, you need to start somewhere. I advocated for starting with design tools, namely a pattern library for the design team to use while creating new designs.
It may sound selfish, but if you have any hope of propagating any design standards through the organization, you have to start with the design team and assure that work in flight is designed to spec with consistent execution.
Build out a shared library of patterns for the team. Make sure everyone is using the same grid, type, form fields, buttons. As projects com into the team, apply the new assets. Look at every project as an opportunity to bring more of the digital experience into alignment.
Keep your side of the street clean.
Gain allies
Seeing the design team get in order and deliver consistent, high-quality work has a positive downstream effect as work is delivered.
Development team members, realizing that the work from the design team is consistent, will soon realize that they save time component-izing their work, too. The challenge is getting both teams to accept the immediate reality that components in the code base will just trickle in, project by project, Jira ticket by Jira ticket. At this point, there’s a bit of a leap of faith; building components in the hopes that components will make a system.
It’s not unreasonable for members of any team to second-guess the need for a design system. It is reasonable, predictable, and manageable.
Project by project, the components stack up, and the proof is in the engineering team’s estimates; as components take hold, front end estimates shrink due to efficiencies built in re-use.
My team saw the best results focusing on projects that included form fields: the components are a little complex so the savings associated with reuse is significant.
Gradual Reach
Two more tools can be powerful in extending this lightweight approach to building out the design system.
A kanban board with tickets created for each component to be made. First column on the left is a great inventory of all components that have not yet been built as part of any project. Final column on the right is components released to production. A few columns in between for design stages, accepted for for development, etc. We’ve used this simple set up as a complement to what’s in the codebase.
A tool like Zeroheight helps a lot for building out a first iteration for your system site. Those geniuses have set up a way to point their site at your Figma, Sketch, or XD pattern library file and–BAM!–it spits out a site of the design system. Not bad! It makes another great tool, in conjunction with the kanban board, for engaging an engineering team on the intended output of the design system.
Once there is some momentum in place, then it sets the stage to begin conversations over the design ecosystem. How can this system be extended to other design materials, content strategy, and brand assets? In some ways, it feels remedial to revisit the system from these other angles, but it is part of the process of extending the reach of the system.
Leveling up the product experience this way takes time, but it gets there. It’s cheap, it’s scrappy, and it’s doable when there’s no team to commit to the work.
So, don’t be intimidated by what IBM, Google, Adobe and other big companies are doing. The most important thing to do is to make progress in standardizing the experience of your product, period. On a small team, it doesn’t have to happen overnight.