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.
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.
This is similar to linguistics. People often rank languages in terms of difficulty, but in reality complexity is just moved around.
For example in English words are often uninflected. Languages like Hungarian/Turkish have a lot of prefixes/suffixes. You'd think that means they're a lot more complicated, but in reality their prefixes/suffixes are very predictable whereas English is all over the place. Is it noninflected, disinflected, deinflected, ininflected, flected?
Isn't that why English is usually the near the top of language difficulty rankings? I mean, your point is true, but I don't know of anyone actually confused about it.
How difficult you'll find a language depends on what languages you already know, and the teaching materials available for it in your own language. These pages distinguish between first languages:
Is it objectively at the top, or is that more an easy thing people love to assume is truly difficult? I don't think we have any evidence that kids are slower to learn in any particular language, do we? (Oddly, we do have evidence that moving away from a primarily phonics based teaching method was a terrible idea, but I haven't seen much to compare with other languages at the same ages.)
Fair. I'm more than a little worried on the perceptions, though. Having arguments with people who think that the English alphabet is not phonetic really hurt my views there.
It's very much only approximately phonetic. This is painfully obvious when you compare with a language like Spanish that has very few exceptions to the 1-1 letter-sound mapping (and even those are fairly consistent). And yes, I did learn to read with phonics.
But for the real difficulty learning English, consider all the forms of "be" and the weird rules for which one to use. (Spanish is only dubiously better in this respect; there are still a lot of verb forms you just have to memorize, but at least you can follow actual rules on which form to use.)
See: through, rough, cough, bough, dough, all of which are pronounced differently. My 5-year-old daughter is learning to read, and trying to explain all this is...challenging.
Are you truly starting with those words for a 5-year-old? Curious why?
Hands down, teaching phonics is far and away the fastest route to being able to decode words. Similarly, reading to your kids is the fastest way to get them interested in reading. Using the motivation to learn to get going on the phonics is more than adequate to teach reading.
And don't expect things outside of spelling/reading to be any more "logical." Try explaining the rules of any sport in a way that isn't dominated by the exceptions.
Having a set of related wordforms of a single word expressing various grammatical features by (usually systematic) modifications of the word, such as the English 'work'->'worked', but on a much larger scale for most languages worldwide. See https://en.wikipedia.org/wiki/Inflection
I think it's like designing an API. Create the wireframe components you need and use them for a while before codifying them into a design system (API).
In other words, observe the function in order to allow form to follow it.
Agreed. I think part of the challenge is that design systems are inherently owned across design and engineering (not just the design team), but the overall understanding of what a design system is means that few folks involved really understand where and how to make decisions about those tradeoffs.
Yep. As for what a design system "is", one thing I've always disagreed with is that it's referred to as a thing, like it's an artifact or output. I like to think of it as a process, as in designing systematically. I also think that the notion of systematic design comes into play even at very small scale - it's not something that's only relevant to large teams. I call it vertical vs horizontal design.
Before the digital era, designers typically worked on things like posters, advertisements, book covers, etc - scenarios where you have a single context and multiple graphical elements that need to co-exist in harmony. This is vertical design - one context with multiple elements.
For digital applications, another dimension is introduced. Because now you'll have multiple pages, views, etc, with some repeating elements. So like a button that exists on both the signup page as well as a checkout page. You may not need the buttons to look exactly the same, but they need to co-exist in harmony with one another just as they do in their surrounding context. So now you have one element with multiple contexts - what I call horizontal design. This second dimension is what requires a shift in thinking from designers to an approach I would call "systematic."
Figma is the first product that takes horizontal design seriously, with the introduction of variants and variables and all that. But there hasn't really been a tool that bakes it in from the beginning.
There is a bit of history in this; Pantone made a whole business out of color consistency across media for branding, coming out of any possible print shop or factory or whatever. And fonts have a similar history.
You might be interested in “Integrated branding” and/or visual identity systems, including the use of “parametric” design, grids, and variables, going back at least 50 years. You’re 100% right that there is a tension between the outputs/artifacts and the generator (process/logic). This often is a challenging aspect of design education programs. Figma’s explicit structure, and certainly their community as well as the rise of design within software, have made this more visible and tangible. But this is an old tension rather than a new one.
Interesting, will check it out. I've done some research on parametric design, but from what I've read, it's mostly been applied to architecture and some aspects of 3D modeling. Which is kind of a shame, because it's really neat. I'm actually building a "programming language" for designers that is essentially a parametric design language.
I'm building a documentation site, but nothing is usable yet. I'm probably 5-10% of the way towards being ready to really showcase anything. But there's some introductory material you can read here: https://matry.design/
Nah nah gotta disagree (well I heartily agree with the basic characterization vertical vs horizontal here) but disagree that designers have not historically done both.
A magazine has multiple pages, views, etc., some with repeating elements. This craft has been honed for the past 100+ years. Read Bringhurst (The Elements of Typographic Style) and you'll see that book design has had both for even longer. Systematic thinking is part of any design education. Can't make a brand's various treatments congeal into a solid brand without it.
In 20th century print design, the grid emerged as a way for designers to systematize their work. And there's something interesting about working with the grid which is extremely relevant for design systems. Here's the thing -- the grid doesn't quite work.
Most designers know that, when you set up a grid, you end up making all these exceptions to make things actually look good. The one most people encounter first this issue: what happens when you put your text in a colored box? If the colored box aligns with the grid, the text doesn't (and vice versa). So people are like ¯\_(ツ)_/¯ and let one of the rules slide. And this kind of thing keeps happening as you work on a big design.
Curiously enough, the best way to see this viscerally is to read the bible on the grid in design -- Grid Systems by Müller-Brockmann. The grid is followed religiously and the book's design is stilted as a result.
Anyway in apps we have the same problem. We have a design system say in Figma. We try to design with it. We find.... exceptions. But we try to make it all work within the system. When we turn to building the app, there are yet more exceptions.
And we've all seen this in the code. These pristine components, over time, get filled with more and more little switches and settings, to gracefully handle the exceptions. And then someone comes around and says "let's refactor all of this", it ends up being quite bulky.
It seems we've reached "peak design systems", they are widely adopted, we love the benefits but are seeing hard limitations and perhaps it's time for the pendulum to swing another direction.
Designers feel more and more limited by working with a DS. They can't make exceptions so their work ends up being stilted. Or they expand the DS (requiring meetings). On the code level, there are more and more variations to manage, and also the exceptions that design-oriented devs add. Things get to be a mess. And the managers are saying "where's the ROI" so we spend time developing tools to measure DS ROI.
And so we apply more and more process, organization, more meetings, and more documentation, to make the design system work. It all gets kinda bureaucratic, against the spirit of agile. And the kicker is, the design isn't necessarily better as a result.
And so even though I kinda disagree I also agree when you say a design system should not be a thing. We treat it as a thing, try to force it to be an artifact, but it's not healthy for the set of design choices to be forced into this kind of form.
Really well explained, and I'm definitely eating my words about the history of systematic design thought. Makes a ton of sense.
Also I think you're spot on about the current state of design systems. I believe the solution is to create some kind of design toolchain that shepherds designers into the pit of success[1], where the "system" simply reveals itself over time as the design is created. That way it isn't thought of as some external artifact, but the byproduct of the process itself. But this requires a complete rethinking, from first principles, what a design tool even is. Figma, for all its impressive technology, is really a traditional design tool with some modern features bolted on (collaboration, variants, variables, etc).
Nice share! And glad to hear your good spirits about our debate, seems not every thread is subject to Godwin's law
I agree with you -- a complete rethinking -- I've actually spent the past couple years thinking a lot a lot a lot about this. And it seems that it's not just a matter of a better design tool, but also a way of how design works in relation to code, and perhaps how the code itself changes!
Sometimes I think that Design Systems, which feel like they came from the design side of the divide, actually was a motion that started with engineering. All the componentization of React etc under the hood really powered the process where designers make components. Before that it was more typical for designers to provide these 1-page sheets with the colors, margins, etc that were more like a style guide than a system. And perhaps the strict component-based approach is part of what's throwing us into the pit of despair from time to time.
Same, I've been thinking about it a lot as well. Actually, since 2014. I'm kinda obsessed with the problem, because I used to be an artist so I'm really interested in the design/development divide. It would take too long to explain, but I've come to the conclusion that designers could benefit from having a textual interface. For a while I've been building a "programming language" for them: https://matry.design/
Agreed. I'd take it even further, framing it as more of a 3-way venn intersection of design/ux + engineering + product. I have lots of related experience and many more thoughts to share, if others are interested....
Adoption is a big issue with design systems. More complex it is, the less adoption you're going to see (or incorrect usage).
It's amusing to see deeply nested and abstracted components with fancy properties in a design system. Makes you wonder who they're building the system for.
If you look at mature publicly available design systems, they have all evolved over the years towards more simplicity and flatter structure. Google, Atlassian, etc.
I'd be curious to hear about those. To be clear, the intent of my comment was not to be condescending. It's not like engineers are any closer to resolving those problems. We've just suffered through them for a long time now.
I think the examples you listed were fine examples. I see designers and engineers are in the Same field and one can get the same results from either profession.
An engineer would most likely put more discipline into their deliverables.
I couldn’t really tell if you were being snarky.
> 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 biggest problem I see with design systems implementations is too much variation, which I think stems from the fact designers have not actually thought out what the User Experience is going to be and how the design system is suppose to facilitate that, for the whole product line
Yes, the whole product line. If you want consistency in a product, it has to start with deciding what UX modalities you want to adopt, and sticking to that. Less is more, usually. Don't add a new component until you have actually exhausted the ability to use the ones you started with, if you decide to pivot UX you need to pivot wholesale etc.
Getting people to stay on the rails as it were, is seemingly impossible, but when you can, it works very well.
I'm abridging a bit (its a iterative process, start with wireframes over full flesh designs and other things) however this does, in a nutshell, work and has a forcing function of actually focusing on the user and product rather than design in and of itself
There are approaches that try to get the best of both worlds. Interestingly, the micro-services architecture is just like that, but it gets a bad reputation for being easy to devolve into a distributed monolith anti-pattern. Another cool model is maybe the propagator model. The point is maybe to find a way that you don't have to opt either for generic or specific implementations, but have many models of the same domain through different lenses operating cooperatively.
Microservices are 100% in the "Optimize for flexibility and you'll end up with something that's way too complex" territory.
(I am watching this right now at my workplace: team next to us has updated the microservice in repo A, and accidentally made incompatible change, so that integration tests in repo B which make calls to that microservice are now falling. Is it a solvable problem? Certainly. But back before we had microservices, this problem just could not occur, as client/server versions were always identical)
They are definitely not autonomous then. Seems like a distributed monolith.
Micro-services are supposed to be simple and independent, but they get crammed with more and more features and complexity and suddenly they just can't be maintained without breaking other parts of the architecture.
Yeah, I've only seen microservices used in a couple of places, but in both cases I felt they were introduced far too early. The first time I saw them was for a 2 page note-taking web app, and it had something like 65 microservices.
> The mere existence of a design system warping the design process and the value of design as a discipline.
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.
It's a double-edged sword. Design systems constrain designers, so each greenfield project isn't a delightful creative experience for designers and a hard slog for the engineers making another similar-but-different interface. However, this constraint can be over-applied.
And even you have multiple projects or products at one company, and they don't talk to each other, and they work on different aspects of the same problem, and each of them has their own designer, they all invent similar tools with different, inconsistent designs that are a nightmare to use.
A very realistic step of my design system is to go back and update the design to match the assorted minor differences discovered as ideal during implementation.
It all depends on how much the customers depend on uniformity between use cases. One thing that a strong design system does is force uniformity between products which can be a boon to confused customers.
The things you list as criticism are exactly the reason places implement design systems. You're clearly an east coast school of thought person who takes pride in building the "right thing." But people who implement design systems are taking the worse is better approach on purpose. They see it as better to be clunky and contort functionality into the existing components and ship than spend time doing something custom.
And unless the design system is really bad it shouldn’t be that clunky. Design is design, not art, each new app in a product suite should not be a unique snowflake, but a piece of the puzzle.
People are acting like there are actually new never-before-seen scenarios in CRUD web apps. I’ve only ever seen situations where the designer thought they needed to break the mold, never where it was actually necessary.
Feel like this especially true in design systems where they went as far as a few dozen atoms but did not progress to molecules or components (insert corollary term here). This exposes a lack of understanding the business and user needs.
genuine question because I've never heard this phrase, and search engines did not yield useful results: what do you mean by "east coast school of thought"? and then is there a corresponding "west coast school of thought"?
I will admit I was briefly even more confused reading that the "west coast" model includes New Jersey (an east coast state) and the "east coast" model includes Stanford (a west coast university)... but whatever lol.
This article aligns with a lot of my person experience. I'd add a few of my own observations on design systems:
1. The team making the design system needs to be really passionate about making a design system specifically
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.
3. Everyone's skills should overlap but each individual should bring their own depth/area of expertise.
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.
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).
6. Make it compliant with accessibility requirements (at least bare minimum WCAG Success Criteria). I've seen that alone drive adoption for design systems.
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.
On a point 5, never underestimate the amount of labor someone is willing to undergo in order not to learn something. Educators everywhere share your struggle!
You should also take into consideration that reading docs takes time. If a different designer (marketing guy) is supposed to do a simple 30m task (draft that Merry Christmas popup real quick), they probably won't get those extra 5 hours to read the docs
And after those 5 hours you spend another 5 hours beating your head against the wall until you finally realize the docs are out of date.
Stale docs are worse than no docs. IME (at non-FAANG, non-tech darling companies) docs *always* go stale pretty quickly. No one wants to take on the thankless, unbudgeted task of keeping the docs up-to-date, or browbeating all the other devs to update the docs when they make changes.
The only docs I push for are stuff like swagger where the documentation is also living code. Otherwise I say just put it in the readme, and every repo has a clear owner responsible for keeping that readme up-to-date as necessary.
I think this is an expectation thing. People expect to be able to figure it out in time x. They expect they'd have to use y time to find the solution in the docs. And people will most often estimate that x <<< y, having been burned by bad documentation before. People will often be disappointed that their search through the docs didn't get them any answers and most people will have strong memories of "figuring it out eventually" by throwing spaghetti at the wall long enough.
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.
It pains me to see dev teams spending time on rebuilding solved problems. I understand brownfield constraints, but the greenfield situations are particularly painful.
It's painful sometimes to think of the sheer number of man-hours wasted because browsers have never added a combobox or any way to style select dropdowns.
> 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.
I would describe it as "design systems are difficult because people are difficult".
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
- 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.
- It will never be done - kinda why we have jobs in the first place right?
- 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.
- It is a cultural & process change not just a tooling adoption. It changes how people work and how they think about building UI.
- 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.
It's closely related to this quote:
> A lack of ... alignment within teams and leadership around what a design system is, what problems it solves, and how it will provide value.
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"
Yep! This often happens when design systems are thought of in narrow terms of design tooling—component libraries and such in apps like Figma, without a connection to the implementation.
Edit—Responding to an edit in the OP:
>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"
This isn't so much an issue with UX and designers as a discipline, but rather points at larger issues in the organization around process, culture, expectations, and strategy, the perceived role of design in that organizational context, and the specific folks you've worked with.
> 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.
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:
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.
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.
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.
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.
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
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.
B. Code-generation tools that supported the languages we needed
C. Code-generation tools that worked at all.
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.
To offer a different perspective, I believe the ecosystem around OpenAPI has vastly improved in the last year or so, at least in my technology stack (Node.js & TypeScript).
- I am currently building a product in the space and I've got competitors tackling the problem from many different angles
- Lots of tools & libraries to choose from when working with OpenAPI specifications (yes, lots of outdated stuff too)
- New platforms like Platformatic are making big bets on OpenAPI and building features around it
- People are using OpenAPI specs with ChatGPT to make custom integrations
For code-generation in particular, there's a handful of libraries that use OpenAPI specs to "glue" the backend and frontend together in different ways (ts-rest, openapi-fetch, openapi-types, orval, feTS). Many startups also offer seamless OpenAPI -> SDK generation.
It's an obvious resource at this point, but this site[1] is a good starting point.
Interesting, thanks. I haven't looked at it in about a year. If I remember correctly, the seemingly dominant generator is OpenAPI-Generator; the one that's written in Java with lots of independent modules for various combos of language and frameworks, using Moustache templates.
Among the available generator modules, there's way too much emphasis on Node. Heaven forbid you're using C++, because there was only one generator for that and it doesn't even create code that compiles.
Trying to create a custom generator means wading through reams of duplicated and outdated documentation in various places, and never even finding a list of the data entities that OpenAPI-generator extracts from an OpenAPI document.
Later on I mentioned OpenAPI to some developers (maybe on here, even) and they agreed that the ecosystem sucked so profoundly that even bringing it up in a professional development setting might be a liability to your reputation.
I consider anything before OAS 3.1 useless because it bafflingly prohibited you from applying a description to a reference. This means if you defined a data structure and used it in various places throughout your API, you couldn't annotate each use of it... largely defeating the purpose of the entire document. WTF! A blunder of that magnitude doesn't inspire confidence.
Looking at the page you mentioned, check out the list of server generators. Almost none are up to date. Once you whittle it down to the ones that support OAS 3.1, you wind up with most languages being unsupported.
And finally, the OAS editor I was using, StopLight Studio, has been discontinued; it was never updated to OAS 3.1 anyway. I haven't found a non-Web-based replacement for it, and that resources page doesn't list one that I can see.
I think you're right. I see a lot of tools for Node.js, Python, and even Rust, but not so much for other languages.
I'm a bit frustrated with openapi.tools too, I think they could do a better job curating and keeping the tools updated. Their issues page on GitHub makes it look like they are not actively maintaining it. I actually bought openapi.cool this week and I'm thinking of building my own version of it.
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.
I've seen it go wrong where there is a design system, but none of the designs that come in actually match it, so we need to extend the standard components or create whole new ones; but timelines are set as if it's all off the shelf stuff.
As someone who often held the job title of "design systems specialist" (usually mobile) many times, one thing that always helped was:
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.
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.
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.
I've found that Android development is actually fairly easy due to the way the system handles the different display tags and how standardized they are. For web it seems like there are multiple layers of possible options - html, css, whatever framework, then the libraries and content management systems. I'm sure this exists to some extent in Android projects, but it doesn't seem to be as much spaghetti.
Design systems following the philosophy "Strong Opinions, Weakly Held" are the sweet spot.
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.
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.
I think Tailwind is phenomenal for implementing a design system on the engineering side, but it can't inherently solve many of the other reasons a design system exists: capturing and defining the patterns a specific product uses, creating consistency across the product, accelerating the design team and engineering team...
There's Tailwind as a technology, but then there's Tailwind as a set of reasonable defaults. The original comment is referring to the latter, not the former.
sorry, Tailwind is the opposite of the design system concept. Design system is built around your product, not some generic style framework that helps you avoid building such a thing.
Yep. It's an inevitable choice, but I find that in the context of design systems, we don't usually end up making that choice intentionally, and instead default to over-optimizing up front without consideration of other approaches.
Based on some experience (designer and developer), here’s some thoughts I currently have about them:
- 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.
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.
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.
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.
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.
I think you're missing some of the nuance in the article. Rote here means that on the industry level, they can feel like an established, everyday, ought-to-be-easy thing—not that they're actually easy.
I'm curious, though: what gives you the impression that the person writing the article "seems to have a very cursory understanding of design systems & component libraries?"
For me I think the definitions were quite "high level" & broad? Stuff like:
> A design system is really a high-level concept uniting various things together around shared objectives.
That isn't really true or accurate - design systems aren't abstract things. They're a set of aesthetic relationships/rules that govern appearance.
I think maybe a small gripe was the inclusion of component libraries - those are always lumped into the same bucket as design systems by folk who don't really understand design systems. Saying that though, happy to admit I may be wrong.
See you're the author - hope I didn't come off as too combative or dismissive. I think my wording could have been a bit lighter (this being the internet and all).
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.
same. i'm fairly conversant in lots of 'design' things and this is remarkably opaque. The discussion is so generic, so removed from specifics, that it looks like it's architecture astronautics.
"A design system is really a high-level concept uniting various things together around shared objectives"
so it's a concept - uniting things - around objectives.
so it's everything and therefore nothing.
back in the real world this is just graphic design and user-interface guidelines and standards on how to present information - even to the extent of actual software components you can use to implement software. sure, cool, yay.
The article describes it pretty well. If it's still not resonating, I know it might come off disingenuous but really I would suggest pasting the description from the article into chatgpt and asking it to describe it to a "lowly systems guy" as you refer to yourself.
"Design system: A complete set of standards and principles to manage design at scale. It can include, but isn’t limited to, the visual design language, typography, colour palettes, components, copywriting guidelines, and other elements that create a cohesive, scalable look and feel for the product."
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!
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.
I somewhat agree but I think your signalling factor is wrong. I don't think a high engineer count is the sign for whether or not the company needs a design system. I think it's the number of active products being developed. If you have 10 engineers working on 1 product I would agree that you don't need a design system. If you have 10 engineers building 3 products with a planned 4th future product a design system would be helpful.
To put it another way, a company with inconsistent design is likely in a better position in terms of income and culture than a company with a design system!
> 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.
As opposed to, you know, the meaning of the word "rote."
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.