Design System Imposter Syndrome
A diagnosis based on creating design systems that meet your organization’s unique needs.
The first step is recognizing it in yourself and others.
Design System Imposter Syndrome is real, and it’s probably affecting more designers, developers, and organizations than you might think.
Typical symptoms of the syndrome may include:
- Spending too much time comparing your UI design language/toolkit/guide to many of the extensive systems showcased on styleguides.io.
- Second guessing or not feeling confident in the decisions you’re making because you don’t think they’re great ideas.
- Putting off sharing the work you’ve done to your boss or project stakeholders because it’s not an extremely exhaustive list of UI patterns and components.
- Coming up with random names for your design system because it doesn’t include all of the details that highly publicized design systems have.
If any of these feelings resonate, you might have Design Imposter Syndrome.
Don’t worry, you’re not alone.
The origins of Design System Imposter Syndrome
For my colleague and I, the need for a design system grew out of an extensive redesign project. Our main objective was to tame the UI inconsistencies across all of our sites and systems while building a resource to increase design and development efficiency in future products.
As a team of two (one designer and one developer), we worked slowly, but in unison, starting small and making structural decisions along the way. At every step, we learned something new that made us reevaluate some of our previous decisions.
We utilized a variety of resources to learn design system best practices (Thanks Brad Frost) or ways other teams were structuring their systems. However, some of these resources were promoting guidelines that our design system project didn’t fit into.
For example, we kept coming across the advice that if you don’t have a full-time dedicated team or complete time investment buy-in from project leaders, the success of a design system was slim. We also read a lot about the distinct differences between pattern libraries, style guides, and design systems, and how the first two were not the same as the last.
My outlook on our project shifted from complete accomplishment to slight inadequacy. I was extremely proud of the repository my teammate and I built, but couldn’t help comparing it to some of the robust, inventive, and beautiful design systems other organizations were developing.
One size fits all only applies to rain ponchos
As I’ve learned in many different aspects of my life, you really can’t trust the belief that one size fits all. This same principle applies to design systems. I started to reach out to other designers and small teams working to build a design system for their organizations.
I quickly discovered, no one truly knows what they’re doing when it comes to design systems. We’re all still learning how they can impact a product, team, or organization. How to scale to enterprise organizations and product lines, or create a categorical hierarchy for each of the different elements in our systems.
The most important guideline for teams building a design system is to focus on creating a resource that meets the specific, unique needs of your organization. For the small, five-person team at the CMMI, we needed:
- A central repository of our brand and UI design principles to share with contractors and marketing to retain a strong, visual consistency across all marketing materials and online tools and sites.
- A flexible resource that allowed us to add and remove elements in parallel development with our site redesign.
- Responsive UI components built using React and Redux for advanced state management to improve the user experience of forms across our site, an overlooked part of our old systems.
- A tangible artifact to present to executives and project leaders to communicate the value of the tool and the potential ROI from decreased design and development time on future projects.
We didn’t requrie the most extensive, pixel-perfect design system platform to meet our organization’s current needs. The resource we built not only helped us accomplish the goals we set out to achieve, but improved other aspects of our team, specifically onboarding new team members to quickly get them up to speed on the principles that guide our design and all of the code he or she would need to start building prototypes in the browser.
An increasing epidemic
I believe every team has a little bit of Design System Syndrome. Most design and development teams are aware of the value of a design system resource but are still learning how it fits into their processes or other areas of value the resource can provide to an organization.
Although there isn’t an exact cure for this syndrome, symptoms may be alleviated.
- Take time to focus on what your organization needs or what gap a design system can fill.
- Reach out to other teams building design systems. It will remind you we’re all still learning, and may provide some helpful tips.
- Always remember to make decisions with your product’s user needs in mind. At the end of the day, design systems are used to build products that help each organization’s specific users achieve their goals.
