I've been following the design system space for a while, and it's mildly entertaining to watch from the perspective of an engineer. Because you see designers fall into the exact same traps and encounter the exact same issues that engineers have long faced.<p>Optimize for flexibility and you'll end up with something that's way too complex. Optimize for speed and you'll regret it down the road. Everything's a tradeoff, but the only guarantee is that at some point, you'll feel a distinct urge to throw it all away and start over.
> The mere existence of a design system warping the design process and the value of design as a discipline.<p>Despite having a lot of experience making them and using them, and despite them being a keyword a lot of companies ask for in job postings, I took any mention of "design systems" out of my resume because I would prefer to work for a company that didn't index on designers who rely on design systems. I've just seen them used as bludgeons too often, i.e. "why would we implement this design when it doesn't match our design system?" well, because it's the right way to do it in this new case we've never seen before. I think design systems and component libraries become a way to reuse existing work instead of rethink and rework, which is convenient but often antithetical to doing the right thing in a changing environment. I understand that product teams have to move quickly. I'm here to do work I'm proud of, which sometimes brings me into tension with the organization's desire to save time and labor, which is to say money. Design systems—not the theoretical idea of them, but the way they are applied in the real world—are becoming a symbol of that for me.
This article aligns with a lot of my person experience. I'd add a few of my own observations on design systems:<p>1. The team making the design system needs to be really passionate about making a design system specifically<p>2. Everyone on the design system (DS) team needs to be pretty far in their careers, and have a few failed or quasi-successful attempts in their past experience.<p>3. Everyone's skills should overlap but each individual should bring their own depth/area of expertise.<p>4. I've never seen a "contributing back" model work, really. There can be some collaboration, or specific asks, but when you have a really cohesive DS team, they took the time to become that cohesive and it shows.<p>5. No matter how good the docs are, there will always be people who don't read the docs. I'm tempted to go as far as to say that I think there should be an onboarding course on how to use the design system that teams have to take before they can use it. (I legit don't know how else to reasonably solve this issue).<p>6. Make it compliant with accessibility requirements (at least bare minimum WCAG Success Criteria). I've seen that alone drive adoption for design systems.<p>I've been creating for web for 25+ years now, and I've only seen 1 or 2 successful design systems. It's so easy to get it completely wrong, or get off track.
One of the few un-nuanced takes I have is that every component library/DS should be built on top of Radix or React-Aria or some other thorough but extensible library. If you’re implementing your own tooltips and menus, you’ve lost the plot. We need to stop reimplementing bad versions of commoditized bits of UI that overlook accessibility, appropriately generic prop APIs, boundary detection, composability, documentation, testing, etc.<p>It pains me to see dev teams spending time on rebuilding solved problems. I understand brownfield constraints, but the greenfield situations are particularly painful.
> A lack of actual (not assumed) alignment within teams and leadership around what a design system is, what problems it solves, and how it will provide value.<p>I would describe it as "design systems are difficult because people are difficult".<p>Working with the average SaaS component can lead you into a muddy spaghetti rabbit hole where you can tell every dev who has worked with it was not following any particular way of doing things other than "making it work". Including yourself.
Observations made about design systems in my career<p>- You need seasoned designers to make it work. Design systems are akin to the technical architecture but for UI. Putting a junior on is like asking jr engineer to make decisions on your system architecture. Please don't do this, especially in a large company, it will fail.<p>- It will never be done - kinda why we have jobs in the first place right?<p>- Not everything needs to be in a design system. Only the things that repeat consistently. Obvious things are colours, buttons etc but also patterns that are key to your experience. This is dependent on what your company needs.<p>- It is a cultural & process change not just a tooling adoption. It changes how people work and how they think about building UI.<p>- Adopting a pre-built design system won't solve your in-ability to make good design decisions or guarantee you use it correctly. Often people who use pre-built systems end up outgrowing or discovering they need to customise the system or implement it without designer input which leads to another set of problems. Out-of-the-box design systems don't tell you how to solve your product experience problems. Designers are still very much needed. You need the right people to wield the tool.
I have some experience in the space as a developer, and it’s challenging mainly because design systems and component libraries are an abstraction, and frankly, most people aren’t great at generalizing. Designers especially are rarely ever taught how to think reusable patterns and components, but they are frequently the ones “put in charge of“ this type of work.<p>It's closely related to this quote:<p>> A lack of ... alignment within teams and leadership around what a design system is, what problems it solves, and how it will provide value.<p>I like working with UX and designers, but more often than not, "we need a new design system" basically means "we want a cool, new theme"
> A lack of actual (not assumed) alignment within teams and leadership around what a design system is, what problems it solves, and how it will provide value.<p>Definitely. In a retro recently I heard, "We need a design system!" followed shortly by, "We already have a design system!" and "What's a design system?" Speaking as a developer, this discussion is slightly out of my lane, but I appreciate the article's discussion of when to start investing in a design system and what you might get in return.
My very modest claim to "fame" is having founded the Elastic UI Framework [1]. My experience with these kinds of design systems taught me two lessons:<p>1. You'll iterate towards the most useful version of your design system in the least amount of time if maintainers spend time consuming it, and vice versa.<p>2. Code is the source of truth, in the form of the component library. It's an unhelpful fiction to treat the non-code design system (whether that's in Figma, Sketch, or wherever) as the source of truth. This is because people build out new parts of the UI by copying, pasting, and modifying the code of the existing UI. If you want to make a change to the design system, it has to go into the code to make a difference.<p>[1] <a href="https://elastic.github.io/eui" rel="nofollow noreferrer">https://elastic.github.io/eui</a>
This stems from a metaproblem, the average is mediocre. I've noticed better tools that have supposedly allowed us to simplify things have just made us to build more complex things. This all stems from a lack of talent. The problem is if everyone got 50% more talented over night, new things would get made, and a new average established and we'd still complain. This is because an average is relative and not absolute. Things that are "easy", on average never will be so. The trick here is to level up and try to join a better company.
I find it depressing how design systems, which come and go pretty quickly it seems, suffer from profoundly shitty design. Figma is certainly no exception.<p>Also disappointing is the state of design-system support for programming. I know not everyone wants or believes in code generation, but I find it incredible that this also still sucks. I'm building the front and back end for a new application now, and the amount of manual syncing between them hasn't changed in a decade.<p>A while ago I had to design a new API for a company's products. After some research, I defined it with OpenAPI. I then wasted weeks or months trying to find<p>A. Tools that actually supported the current version (3.1), which is the only one that's acceptable because of glaring gaffes in previous specs.<p>B. Code-generation tools that supported the languages we needed<p>C. Code-generation tools that worked at all.<p>It is an absolute shitshow. None of those things is available or works. The moral is that common problems faced by lots (if not most) of us programmers or system designers are still not solved. Don't assume that you're the problem. I made that assumption, but in the end no... the tools and ecosystem were simply shambolic and I would just have to write my own or just strap it on and do the tedious manual work.
The challenge in my experience is getting buy-in to use the system for everything, consistently. None of the benefits of a design system and UI library matter unless it's used, and used consistently.
As someone who often held the job title of "design systems specialist" (usually mobile) many times, one thing that always helped was:<p>This is what standard iOS vs. Android elements look like out of the box, this is how navigations works out of the box, this is how some ux patterns (like various pickers) work out of the box. Now this is easy to change, this is more difficult to change, and this is something you should never change.<p>There you go, we have a good spine for a design system (and not just a component library), and we have a good starting point to fix the relationship between designers and developers, which is broken way too often, and hinders progress way too much.<p>It does require serious time spent in XCode and Android Studio actually writing at least hobby projects, but that knowledge pays off tremendously in building trust between teams.
Design systems following the philosophy "Strong Opinions, Weakly Held" are the sweet spot.<p>Having a consistent reference for stuff like "what's the standard color gradient for a Generative AI placeholder" is hugely valuable, BUT UXD / Engineering must have leeway to interpret the spirit of the system and not be forced into pixel-perfect adherence.<p>Experienced this 1st hand with earlier version of Material Design. SO MUCH WHITE SPACE! This is fine for some use-cases, but when you're building an internal tool for technical users who need an information-dense experience, following padding / margin guidelines is sub optimal.
"A tendancy to over-optimize for future flexibility, rather than immediate need and impact, which eventually sabotages momentum."<p>A choice between shooting yourself in the foot later or later.
Based on some experience (designer and developer), here’s some thoughts I currently have about them:<p>- high-level idea is usually understood, although mixed with design tooling
- practical usage rarely straightforward
- most of the activities are surface level and trivial
- required effort to maintain and develop often underestimated
- maturity level rarely reaches the potential
- ”component” is not an easy concept, especially in multi-product setting
- too often design driven, when implementation driven would make more sense
- generates meetings on many meta-dimensions
- not necessarily rewarding exercise for the maintainer due to various organisational and political challenges
- does not actually help on design-to-development e2e flow as much as advertised
- even with all the work put in, does not guarantee good product
> Not using or recognizing the design system as an internal source of truth.<p>My experience has been that engineers and designers try, but can't do so. New projects tend not to be fully covered by the design system. This is almost tautological. New things are new.<p>Yes, maybe they thought about what they want calendars to look like, but only for the case of picking a date, not displaying a weekly schedule.<p>At one company this meant they kept gluing new things onto the design system, and at another company it meant we met with them every release and got told not to worry about it.
Adopting design systems isn't inherently difficult, but in most cases integrating them into legacy products is challenging. Outdated technologies and inflexible structures in these products significantly hinder alignment with modern design systems. It needs a massive amount of navigating technical constraints and legacy constrains, which adds a lot of complexity and resource demands to the process.
Let me be the first to object to the "rote" classification. Design systems are hard in a way that good design is hard. For the folks in the comments (and in the article) comparing UI libs to design systems, they are completely different.<p>EDIT: Evidently, the person writing the article seems to have a very cursory understanding of design systems & component libraries. Maybe better left as a tweet than a full article IMO.
My favorite part about design systems is when they are created in a vacuum devoid of either content strategy or technology/engineering so they look dope af but solve nothing for activation or delivery teams.
I'm just a lowly systems guy, but the definition of "what is a design system" is really confusing.<p>Is it a UI library? Like if you get a team of people together to build one, what is the actual deliverable?
Design systems seem to be due to oversupply of designers and frontend engineers in the tech industry. You get enough of them together in a company and there’s not enough for them to work on. So a design system is hatched so that they can work on things that never get used!<p>I jest somewhat but I do feel a design system is an “org smell” for all but the largest engineering organizations. My estimate is that you don’t need that unless you have 4 digit engineer count. Smaller companies with design systems usually are putting the cart before the pony, so to speak.
> When I say rote, I’m thinking about how parts of the underlying toolkit have become really easy, how pretty much any designer can work on one, and how the general idea of a design system has become understood such that it’s a reasonable expectation that a team will have one.<p>As opposed to, you know, the meaning of the word "rote."