Companies should just stop thinking they need their own design system.
There's zero value in reinventing how buttons and inputs should look like.
I've worked for many companies, big and small, and they all had the arrogance to believe they need their own component libraries, reinventing the wheel out of ego.
My advice: you're not that special, just pick a component library and spend your precious time building actual value.
I hear this take often - particularly on HN - and I think that it is well off base IME. For many small + medium sized companies, sure, this can be true. For a scaled org with 10s or even 100s of teams building UI having an internal design system aligned perfectly with brand/marketing/content/accessibility makes a ton of sense.
It's not about reinventing the wheel out of ego. It's about "We have 150 dev teams and want to make sure there's a documented way that our company is aligned upon for building things like forms for our customers". How should the company consistently apply error states? What a11y affordances are we baking into our UI? Radix and shadcn provide much of that out of the box, are they doing it in such a way that complies with our internal controls?
Maybe for some managers it's about ego and ownership above all else. Yes, those teams probably should be using MUI, or a themed Radix, or something. But those managers are going to suck no matter what.
Certainly, and to get that sort of compliance a faster, cheaper, and less likely to fall out of date mechanism is simply to document what the UX should look like and which libraries should be used to get there.
The issue with "make the framework" approach is what happened to our company. We had a team dedicated to maintaining blessed widgets that eventually got gutted as other priorities came up. So now the blessed framework is rotting on an old version of Angular with no path to upgrade.
Distributing things, making smaller dedicated UX libraries when needed, and documenting look and feel. Heck, maybe even get public facing UX sign off all work way better than having the one true company framework that gets abandoned.
Now, you might say "they shouldn't have abandoned it" but the fact is that long before the team was gutted they were spending an inordinate amount of time fixing and extending widgets and trying to add new widgets as UX needs came up. Often for 1 shot usages. Before the team was gutted they were already behind on the Angular version with a plan to update "maybe next year" as it was a fairly large hurdle.
Yeah - all of that sounds like a pain. No argument from me. Sometimes, things rot and we have a bigger mess than before.
There are many circumstances in which a design system is at best a lateral move and at worst a huge distraction. My issue with GP sentiment is that many of the hardcore pragmatists here on this lovely discussion board have one or two bad experiences and throw the baby out with the bathwater entirely. I just wanted to be a voice on the other side of the aisle.
The precious little framework idiots I worked with couldn’t even keep up with Node versions.
None of us can write most of this on our resumes, and we can’t just spend our way out of it.
What I really don’t understand is why people are so fixated on getting version 1 out the door. Like it’s the Mount Everest, and afterward it’s all easy sailing, or everyone lives happily ever after.
Anyone can ship a version one. It’s shipping a version 2 that’s hard. And it sounds like your coworkers, like quite a few I’ve encountered before, couldn’t ship a version 2. That takes pacing and stamina and reaping the rewards of having said “no” enough during version 1 to normalize it.
> For a scaled org with 10s or even 100s of teams building UI having an internal design system aligned perfectly with brand/marketing/content/accessibility makes a ton of sense.
How many companies do you think have 10s or 100s of UI teams?
I bet more companies have 1 UI team, or 1 UI person, than have 10 UI teams.
Maybe not 100s of UI teams but I worked at a large bank and there was dozens of full stack teams that each had to write front end code. We used an internal UI library. Otherwise it would be chaos.
Yes and I've worked at such companies, and all of them had internal ui libraries that were way worse (along every metric: features, performance, consistency, documentation, a11y etc) than most popular options like MUI out there.
So have I, and they weren't. So we're no better off where we started. I at least made concessions on my side of the argument, but you are free to dig your heels in.
There's zero value in reinventing how buttons and inputs should look like.
That's not the reason why anyone builds a design system. Companies need a design system so their own developers can build consistent UIs easily. If you've ever seen the output of a company that has lots of teams and no consistent way of building UIs you'd be horrified. Their products are a mess, and the UX is terrible because each app (or part of an app) works differently depending on which team built it. A design system is an attempt to solve that problem.
Most companies have no reason to release their design system to the public. When a company does that it's usually dev rel, or just plain marketing.
They could do that just fine if they picked an existing UI library on a company level. There's no need to invent their own.
Never in the history of software has one lost a sale due to how the buttons of their product look like.
And I guarantee you that their internal library will be worse than popular options out there. The amount of time I've been in meetings where 10 smart, well-paid people from 10 different products in a company are endlessly discussing paddings on an input field... It's just a complete waste of time.
Every company I know that has a design system the developers actually use based their first version on an open source library. Companies do exactly what you're suggesting. Their design system is usually little more than a config file for the library they've based it on, with some custom components for the bits that don't come by default.
I agree with the sentiment, but don't appreciate the way you put it (lacks nuance). I think it is obvious that developing custom design systems can sometimes give companies a competitive advantage, hence there might be a non-zero value here. Heavily depends on the product and the target audience.
In any case, the market has your answers. So many people are doing their own design systems. Can all this effort be caused by merely arrogance? There ought to be something else reinforcing this behavior.
I'll do you one better, the market doesn't care about competitive advantage.
If it did, then we'd not see every company adopting this year's technobabble to get a stock price bump. How many companies this year are chasing LLMs and AI even when it has absolutely nothing to do with their core product? How about a few years ago when everyone was after ML? A few years before that when it was setting up blockchains?
Heck, how many of these layoffs going around are due to the fact that every time a company does it they get a stock price bump?
Completely depends on the industry. A consumer app for entertainment will have a completely different aesthetic requirement than a b2b healthcare solution.
I think too much time and money is wasted on frontend web development but I'm also happy the Web doesn't all look the same. More design, less JS I say :)
Not ego, it’s all about control. When libraries map to business requirements, great! But what happens when they don’t? Now there’s an external team you have to beg to consider your use case or go rogue … or just start from day 1 with control.
Nothing says your internal design system has to include all custom designed inputs. The actual goal is standardization, not customization.
You want to have a single `TextInput` component, for example, that's used everywhere in you company and can be changed easily. Nothing is stopping you from wrapping an off the shelf component library or even the base text input from the OS or HTML.
They can use a headless component library and style it to their liking. I generally agree with you though. I've seen some really really badly made home grown component libraries that could have just been MUI (or others like it) with custom styles for a fraction of the cost and with much better results.
Good thesign has no value when a middle click doesn't paste my selection, ctrl+arrow doesn't go to the next word, and shift+tab doesn't move focus to the previous item.
I agree, however I would extend it too be even more pragmatic and say, just use html5. You can do everything you want with html5 for simple crud work. There's not need to be extra, and the main benefit of html5 is everything's really easy to use and accessible.
I worked for Okta for a bit and this was a huge pain. It was mostly a wrapper around MUI, which meant it always lacked behind MUI and every time you need a slightly different functionality they didn’t support yet you had to go through the design team and wait.
Autodesk's CAD stuff started life in the early 80s and needed to do plenty of trailblazing on fundamental concept of CAD user interface. They have a well-established client base that rely on intricate details of the interface. By its very nature their product is aimed at experts well educated in their domain.
Meanwhile, companies that burn most effort into "design systems" seem to be heavily B2C, and mostly concerned about getting their colors to pop, fonts to be fancy, and buttons to be rounded. (Or old ancients like IBM that are just so big that they probably are among the few exceptions to the rule and actually need a design system![1])
Not a great comparison.
[1]: Love me some slashed or dotted-0 fonts. Thank you IBM for popularizing that.
I'm not sure, is Autodesk a good answer? Wouldn't they be in the business of design and perhaps not a standard company that shouldn't do custom? Maybe I misunderstood the point though!
There's zero value in reinventing how buttons and inputs should look like.
I've worked for many companies, big and small, and they all had the arrogance to believe they need their own component libraries, reinventing the wheel out of ego.
My advice: you're not that special, just pick a component library and spend your precious time building actual value.