Comment by vogt | Hacker News Reader

Comment by vogt | Hacker News Reader

Parent Full thread

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.

I’m currently building the “framework” for my company.

We picked a common component library, and we themed it with our colors/typography.

Took us a week to package it all up and now all our developers can install and use it easily and everything is compliant on ui/ux

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.

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.

> 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.

Reply on news.ycombinator.com