Read this article on Medium
Design Systems Beyond Basics: Unveiling Nuances and Oversights
The domain of Design Systems now is quite saturated with articles, books, insights, and post-mortems, each offering a glimpse into the multifaceted landscape. Since dipping my toes into this realm in 2017, I’ve experienced various evolution steps within different organizations, witnessing firsthand the maturation of tools and processes. With the teams we’ve been through various evolution stages and to this day, our created Design Systems are alive and well.
While Design Systems have, in many respects, become a well-known initiative and occasionally an industry standard, overall system establishment isn’t free from misconceptions that can misguide even proficient teams and companies. So in this essay featuring longer sentences and 0 button pictures, I would like to explore the ever-evolving Design System trends through the prism of practical experiences, focusing on the not-so-evident aspects. As in the end…
“All happy families are alike; each unhappy family is unhappy in its own way.”
― Leo Tolstoy, Anna Karenina
Let’s course together through Design System definition, composition, benefits and, naturally, caveats.
A Design System Defined
In its essence, a Design System is a meticulously curated library, encompassing tokens, styles, components and many other digital aspects, guided by clear standards and accompanied by documentation. Fostered by a dedicated or federated team, it serves as the unseen engineer behind multiple products, orchestrating a harmonious digital user experience.
The well-aged Design System is sitting robustly between Brand Direction and Digital Experiences while orchestrating the Target Audience’s journey. Eventually, it becomes an integral, cohesive, and structural layer within an organization, not only implementing but defining product and organization design vision.
Regardless of the requirements, resources, deadlines and ambitions, it’s crucial to remember the key point - it should
always
start
small.
Design System pillars
Hello, myself from 2019. That was the year when I coined the term “three pillars” of the Design System. Though slightly adjusted over time, I can confirm the concept is still legit in one or another form. Recently I stumbled upon a resemblance of that model in Ben Callahan’s course.
In short, the three pillars are Deliverables, Maintainers and Processes. Here’s the metaphor in action - when one of the pillars is wobbly or crumbly, the Design System either stumbles or collapses under pressure, becoming a blocker instead of the intended purpose. Not to mention when there’s just one pillar on its own - that should be either a dawn or soon decline of the initiative.
Side note - I’m not married to the “pillars” metaphor so much any longer, so let’s come up together with a more viable and illustrative analogy.
Deliverables
With deliverables, it’s rather obvious where to start and what to prioritize (UI libraries in any form) yet there are so many versatile options. Self-documenting libraries in Storybook, Figma-only documentation, code as the source of truth and more and beyond. Generally, there are 2 important things to focus on - Components and Documentation if you prefer alphabetical order. Documentation and Components if you are really being serious.
Code: Including UI libraries, design tokens, iconography.
Design Assets: Think Figma libraries and UX patterns.
Documentation: Spanning websites, code repos, Confluence etc.
Additional Assets: Illustrations, fonts and such.
Maintainers
Maintainers establish and move the Design System forward. These dedicated individuals and/or teams champion its evolution in the beginning and sustain the fidelity and reliability of the system later. They ensure it adapts and resonates with time, project and organization requirements and the landscape of technology and user expectations.
The more traditional approach in the early years - Design System originates from the design environment and is pushed forward by designer(s). The frontend-first approach was considered a rarity. Lately, there is no big distinction between the two takes, in fact - coordination of minds and efforts would work the best. If you need a deep (much deeper) dive into the topic of people behind Design System development, refer to Nathan Curtis’s article.
Designers: mandatory.
UI developers: mandatory.
Recommended ratio?
-
A) Highly depends. Usually a good start would be 2+ frontenders per 1 design specialist.
-
B) Scale is non-linear. When in doubt refer to A).
Other competencies may include but not limited to:
-
UX designers
-
Accessibility specialists
-
QA engineers
-
Motion designers
-
Content editors
-
Icon creators (this is a real thing)
What about the Product Manager? Applicable to Design Systems this role is highly versatile without traditional boundaries of the industry, ranging from roadmap communication to fully-fledged architecture. It’s worth mentioning that the weight of PM responsibilities can be owned or even shared between key maintainers, especially at the early stages. However, a dedicated role can help to push the envelope faster and assist with the priorities churn, miscoordination, excessive bureaucracy, red tape and other fun aspects of large or conservative companies.
Processes
Processes signify the operational backbone of a Design System. They are Lebowski’s valued rug, tying everything together with routines, workflows and collaborations and ensuring integration of the Design System within the organizational framework. They come especially useful at later stages, however, it’s highly advised to consider at least the basic ones in advance.
Another point of consideration is automation. You would like to save some precious time, wouldn’t you? Automate everything possible, but avoid de-humanization pitfalls. Talk to customers and each other first.
Request and Update Cycles: It is crucial to establish and hone those as soon as feasible. For the team, it’s velocity and transparency, for customers - trust and reliability.
Customer Support: Next in line - support - both technical and design-wise. Slack works for the most part!
Contributions: Prepare your fundamentals and encourage collaboration. Early insights are solid gold. Not too early though!
Onboarding: Your system would definitely benefit from a regular guided process, considering how it can change over time.
Office hours: When Slack doesn’t work. Have a weekly or 2-weekly session to chat and answer questions, provide support and announce something cool. Agenda is the key.
Features of a Design System
Most integral elements that constitute a Design System are well known and I won’t be going over them in detail again. Some less prominent building blocks might be overlooked though, so take a glimpse. Please note, that the list below only shows the median slice of features, simply because not all Design Systems mature to the level of delivering not just elements, but the whole parts of the application as micro-frontends.
Visual Style: The aesthetic glue binding the UI.
UI Components: Reusable design elements ensuring efficiency.
UX Patterns: Crafting a consistent user journey across platforms.
Accessibility: Embedding inclusivity from the get-go.
Editorial: Sculpting the tone and content consistency.
Charts: Standardizing visual data representation.
Plus more, should maturity and organization specifics demand for!
Features really shine when 3 pillars of the Design System are working cohesively. Some of them may seem to match the deliverables, but essentially it’s a more conceptual and product-oriented list. For example, ”Accessibility” can be achieved by putting together coding practices, inclusive design assets and guidelines, practical documentation and tutoring sessions. Take an element away and it falls apart. What is the value of high-contrast design if it’s not respected in code? What is the value of aria props if they are neglected in the customers’ projects? In both cases, it’s a value multiplied by zero.
Compare this to the steadier and slower but holistic approach. Yes, not all code components are compliant yet with WCAG 2.1 AA, but they match good practices in design and product teams know how to apply and test for accessibility. The value would not be 10/10 from the start, but it’s more than 0.
Finally, fully-fledged features don’t appear out of thin air - they need strategy, communication, roadmap, tickets, prioritization and so forth. Interestingly enough, most features of Design Systems won’t be finalized, but rather consistently grow in size and complexity over time.
Benefits of a Design System
If you are here and almost bored, jump to the next section NOW.
Seriously, it’s the most cliche part of the essay. It’s so corny that we should change the heading immediately. Here goes nothing!
- Benefits of a Design System
+ The Bestestest part of a Design System
While some advantages of Design System installation might be immediately noticeable and appreciated by the stakeholders, others might not be so evident. In various sources you might find more aspects, however usually they would stem from one or another more prominent points.
Top 2:
Consistency: Ensuring a uniform visual and UX across UI.
Efficiency: Saving time and thereby, financial resources, in development.
Runner-ups:
Accessibility: Integrating and fostering best practices from the jump.
Scalability: A problem solver for scaling issues across various platforms.
Practically speaking, this is what Design Systems were created for in the first place. Ironically, it’s often taking second place now…
Faster Rebranding and Refactoring: Making large-scale updates breezier.
Beyond the obvious:
Faster Onboarding: Streamlining the integration process for development and design.
Recruitment: Positioning the organization attractively for top-tier talent.
Finally, there’s a gimmick often named a ”Common Language” for an organization. Commonly, it’s the poetic interpretation of the fact that teams strive for or have achieved effective collaboration and streamlined their production processes, not without the help of a well-established Design System. Should we put it in a separate category? Sure, just remember to explain what is meant by that during a pitch. Instead of “hmm” you may count on “ohh!“.
Design System Caveats
Well, here’s the main reason why this very article was hatched in the first place. Honestly, I expected more content for this section, however, previous chapters already provide quite an extensive problematic coverage - in case you skipped it, consider going back. Remember this statement, it’s a blunt solution for the caveat number N, so we’ll see it in detail further.
Investment
Establishing a Design System demands both time and financial investment. This upfront cost, which requires management buy-in at company and project levels, predicates a future return on investment through eventual time and cost efficiencies.
Cost-Effectiveness
A Design System is fundamentally crafted for scalability, posing itself as a service particularly beneficial to multiple projects. While it can certainly manage the UI for a singular project, its cost-effectiveness truly shines when deployed across numerous ventures.
Longevity
Longevity is intrinsic to a Design System’s makeup, operating as a perpetually tuned and smoothly functioning entity. Should any of its fundamental pillars - deliverables, maintainers, or processes - become obstructed, it risks transforming into a barrier itself.
Creativity Gateway
The Design System can intentionally or inadvertently become an operated valve for creativity, often a focal point for critique. Nevertheless, in contemporary organizations, the potential stifling of creativity is typically mitigated in advance through strategic training and process establishment.
System Errors
Like all systems, a Design System is not immune to architectural pitfalls. Common missteps include initiating numerous competing projects instead of starting small and failing to plan for long-term maintenance. Both provide a misleading sense of initial control but tend to manifest as obstructions in the long term.
That’s worth a short digress.
What’s a long-term vs short-term anyway? Let’s put it on a virtual timeline. Roughly put, it’s a threshold of 1 year or so. Usually, foundations should be established after 1 year of development, and then the real work begins.
Design Systems are somewhat slow, multi-staged (also -layered and -faceted) projects, where each stage would be unique in aspects of length, growth, issues, requests, processes, maintenance effort and so on. Planning only for growth and overlooking long-term support is as dangerous as starting with all features and conflicting priorities, eventually making foundation establishment a never-ending resource-guzzler. Both examples relate to architecture and can be called system errors of Design System development. That’s an oxymoron I would shy away from.
It’s a wrap!
Creating and maintaining a Design System is naturally full of challenges. I reckon we should be more transparent and candid about possible roadblocks and considerations. Getting buy-in from stakeholders is one thing, return on investment is another.
Design Systems have been generously contributing to the realm of consistency and efficiency in the digital development terrain since 2015 or so, marking not merely a trend but an industry staple. Naturally, as we navigate the evolution of technology and design, the exploration, critique, and refinement of Design Systems forge ahead, too!
This article is an interim stage where I take a chance to analyze personal and collective experiences with Design Systems, as that needs to happen from time to time. I also hope that it will encourage us to revisit how Design Systems contribute to our digital environments now and anticipate next-gen challenges and innovations with an open yet slightly more rational mind.