I love building communities. This love started in my work as an organizer, but quickly spread into my career as a designer. Community building is exactly what it sounds like—the intentional practice of engaging a collective around a shared interest for common good. I believe that the core parts to building and maintaining a strong community are inclusion, accessibility, enablement, and collective care.
In this post, I’m going to talk about how I approached Kickstarter’s design system with these concepts in mind. I hope to change what people think of when they hear the popular phrase, “design system,” and hope to influence you and your teams to think about some new approaches that could result in more intentional and inclusive systems, processes, and conversations.
A design system is not, in itself, an artifact. It is not a Figma file, or a React component library, or a public-facing brand page. Yes, it’s surely a tool of sorts—but not in the singular sense our industry has painted it to be.
A design system is an intertwining web of mechanisms, processes, and people. It’s a constant push and pull between maintaining balanced order and allowing space for fluid, creative evolution. It’s incredibly delicate, fascinating, and is never a one-size-fits-all.
Overall, there’s so much joy in the journey of collaborating to find what’s right for a given organization. Which brings me to my first pillar of inclusion.
Inclusion
One of the first things myself and some fellow designers did at Kickstarter was exercise radical inclusion in order to ensure that people felt like they had a voice. Often times, design systems can be built in silos, and I wanted to make sure everyone at Kickstarter knew this would be a transparent process that had its doors wide open.
So, I led a giant retro! Truly…the name of the calendar invite was actually “🌈 One Big Happy Retro.” I got a bunch of engineers in a room, and led a retro with a Happy, Sad and Confused format around Kickstarter’s design system that existed at the time.
This yielded a ton of enriched findings, and fueled plenty of great conversations. But for the purposes of this post, I want to focus less on the nitty-gritty findings and more on what it meant to actually set a meeting like this.
When you intentionally make space for people, you’re going to get better results in any endeavor. Assuming people will step into a space or a conversation is doing yourself a great disservice— and even if you guarantee people that you’re “always on Slack” or “always open to feedback,” these things can feel empty. Inclusive action is the first step you can take to make sure people on your team and in your organization know you want and need them to be included.
Accessibility
This is a big one, folks. When I say accessibility, I don’t just mean making sure that the components in the design system are accessible for your users, I’m also encompassing the following:
Making you, yourself, accessible to others for conversations
Making sure you’re creating artifacts and processes that are easily accessible across all skill sets, disciplines, and knowledge levels
Making sure you are speaking and writing about your processes and rules in a way that is easily understandable, and leaves ample room for welcome change
This is a big list, and I know firsthand that it can seem daunting. But as designers, we are built to dissect big problems. Jina Anne said, “Design systems are for people.” She did not say designers, or engineers, or product minds—she said people. This means everyone from your design teams, to your operations teams, to your end users. A design system has the power to enable so much change within any organization, and this is precisely why it needs to be accessible from every angle and by every individual.
Ensuring your tools, processes, and information are all accessible gives everyone a chance to care and invest. Which leads me into my next topic: enablement.
Enablement
Enabling people within any system takes empathy, time, and deep understanding of how individuals spend their time in a given organization; it is a muscle I am constantly building.
My biggest tip here is to think about how your company and you yourself can make it more natural for others to contribute to your design system. How can you make things less manual? This could look like building Figma plugins to make user-generated content easier for designers to pull. Or it could look like setting aside design system open office hours via a company-wide calendar. Perhaps it’s something as simple as including login credentials to internal systems documentation in a new hire’s on-boarding.
At Kickstarter, me and my team did all of the aforementioned things. We also sent out a bi-weekly design systems report which gave high-level insight into changes and work being done regarding our systems. The reports were filled with links out to all of our resources: JIRA boards, internal tools, Slack channels, etc. The reports were also written collaboratively.
This may sound like transparency overkill, but this exercise in radical transparency is what began to make people feel enabled. I would receive inquiries and feedback and engage in unexpected conversations with folks all across Kickstarter as a result of these mechanisms put in place. I knew for certain the process was working when I saw other people begin to take the reigns themselves. People felt empowered to do things like make changes to documentation, create proposals, add insightful items to our systems JIRA backlog, and light the sparks they wanted to see.
The ways in which you enable people in your organization will always be unique. But uncovering what people need will come far more easily if you’ve already began to think about and exercise inclusion and accessibility.
Collective care
The process of creating and maintaining a design system is an enriched opportunity to create not just visual unity, but unity between people. If you exercise inclusion, make things accessible, and make people feel enabled to contribute when they need to, you are well on your way to building a strong community.
At Kickstarter, by engraining these pillars into systems thinking—inclusion, accessibility, and enablement—our components were built better. The concepts and pillars which we exercised in our processes trickled into the ways in which we actually built out our tech.
On the engineering side, a working group around Storybook got spun up in order to make components far more accessible. On the design side, we were constantly looking to build our components in ways that felt inclusive to how our teams were using Figma in their day to day. The pillars worked their way into the collective, and became deeply embedded into the fabric of our system.
It’s a beautiful thing, when you start to see people focus on the collective rather than the individual. And this is exactly what a design system ought to be—holistic regard for all people.
Ready for something a bit cliche? Be the spark. Yes, a design system is daunting. Yes, it can feel impossible if your organization isn’t thinking about systems in the ways you might be. But I guarantee that things will start to improve and feel genuinely good once you begin to focus on building a community around design systems, instead of focus on just building a bunch of things.