It's weird how design systems are so rote, yet so difficult
quinnkeast.com
quinnkeast.com
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.
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.
Now, the brand is so much more than that.
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.
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).
[1] https://blog.codinghorror.com/falling-into-the-pit-of-succes...
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.
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?
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.
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.)
This is in contrast to logographic symbol sets, that do not correspond to sound encodings. Think emoji.
Advanced grammar is a trap in all languages.
https://blog.rosettastone.com/what-is-the-hardest-language-t...
https://www.reddit.com/r/languagelearning/comments/87jy70/ra...
(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)
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.
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.
An engineer would most likely put more discipline into their deliverables. I couldn’t really tell if you were being snarky.
Very well-put, quoteworthy!
In other words, observe the function in order to allow form to follow it.
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
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.
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.
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.
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.
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.
It pains me to see dev teams spending time on rebuilding solved problems. I understand brownfield constraints, but the greenfield situations are particularly painful.
The whole reason they've been bad is "We can't change `<select>` because it would break backwards compatibility".
So the new solution is to create a new element: `<selectmenu>` which is made to be customised, while still being accessible.
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.
- 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.
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"
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.
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.
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.
Amen. No point living in a Figma dreamland if what you're shipping doesn't resemble it.
If you love simplicity and tend to think about how stuff works, you'll be bothered be the fact Etcher is 80MB.
If you're a user... you'll just say "Wow, only a 1 minute download and I'll never have to worry about wiping my disk with dd again!"
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.
- 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.
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.
Thus far, it's still looking pretty weak.
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.
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.
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.
Bootstrap on the other hand does.
A choice between shooting yourself in the foot later or later.
- 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
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.
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'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?"
> 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.
Is it a UI library? Like if you get a team of people together to build one, what is the actual deliverable?
"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."
"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.
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.
As opposed to, you know, the meaning of the word "rote."