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!
This text was authored by an individual who travels globally, educating people on interface design. Previously, he was a weightlifter and worked as a producer for PBS.
I mention this because I find myself in complete disagreement with the article in question. It left me questioning the author's expertise in software, as it overlooks what I consider to be the cornerstone of software development: the iterative process. Contrary to the author's views, I advocate for minimal design upfront and urge rapid engagement with users. This is because requirements frequently evolve, often resulting in a project that differs significantly from its initial conception.
Design systems PM for Figma here. What the author is saying here is correct for enterprise-scale companies. To your point where you urge for rapid iteration, if Microsoft launched a new product and needed all buttons to have a dropdown for said new product, would you update MS Word’s buttons to also have that dropdown?
Of course not, and that’s the authors point. Product teams should move and iterate faster than the core design platform. They should be free to break from it for their exploratory needs, and these platform teams shouldn’t bend over backwards to support them.
Another way I like to frame this is the following - a design systems team should support 90% of the use case needs of its products, not 100%. Adding support for that additional 10% often bloats the components and reduces usability and consumption. It’s often not worth that effort. New products are often rapidly evolving, and dwell in that 10% land quite a bit. Let them cook and experiment. If other teams end up adopting the same patterns, that’s when you bring it into the system.
This mentality, of covering over software at the edge, is how we got the first crop of 737 max crashes. Bad software, shitty UI and a go fast culture. Its how were so capable of evolving dark patterns quickly... product creep mentality has trained the user base to go go go and not think.
And the costs happen at the other end: it's the mental workload that happens when check boxes are toggles now.
You can frame this however you want. In most cases it's unqualified people making expedient decisions that are just confusing to users outside the bubble of tech and PM that they live in. The people who are developing these projects keep jamming AI into everything... it doest matter that ML isnt ripe, that end users dont care, that it's not fit for purpose.
I can point to massive piles of product innovation, design and feature creep that exists solely to pad the resumes of bad UX, product and engineering teams.
Slow the fuck down and do some basic usability on your stupid idea. You might learn it sucks before it's in production further numbing your user base to your bullshit.
MS Word is dramatically different from a 737. If MS Word doesn't work quite right, people spend 5 minutes looking up a work-around, or live with not-quite-as-prettily-formatted documents. If a 737 doesn't work quite right, hundreds of people die.
Basic table-stakes for having any sort of decision-making authority at a company is understanding the context of your decisions. A word processor that tries to get everything right hasn't launched yet. A airliner that moves fast and breaks things...well, breaks things.
And you're going to say "well they should have known that..." except that you, me, the average HN reader has a different relationship with tech than Joe and Jane average public.
I think you're actually more in agreement with the author than you think you are. He's not arguing against iterative development at all. Rather he's arguing that product should evolve quickly and iteratively, and the design system underlying that product should move slowly and carefully, only systematizing aspects of the design once they have a large number of motivating examples.
I think some of the confusion is a misunderstanding of what design systems (and each of the layers in the authors' diagram) is. It's different from design. "Design" is "This button should be 56px wide, have 8px of padding and be colored #4590ff". "Product" is "We are are building an app to let users listen to podcasts, and we should show a list of recommended next podcasts with a button beside each to play, but default to autoplaying the next one if no user interaction happens." "Product research" is "Our users frequently listen to podcasts in the car, so they may need hands-free interaction and will want to listen to the next track without user intervention." "Visual brand" is "Across all of our products, we like to use a simple white background, with dashed-line dividers between list items and #4590ff primary call to action buttons, each of which has 8px of padding and 4px rounded corners." "Design systems" is "Across all our products, use a list whenever you have a collection of homogenous items. If the list represents an audio multimedia track, use this music icon that we have uploaded to the general library. The currently playing audio track should have a moving audio signal display to indicate its selected status."
Notice the increasing level of abstraction across each of these categories. Design is rules for users. Design systems is rules for designers. And that's exactly why it should move slowly - you cannot build good rules until you have seen many instances of problems in the real world and have a chance to gather data across many instances of the pattern.
In my experience, design should iterate ~daily. Product ~monthly. UXR ~quarterly. Visual brand ~annually. And design systems every 2-3 years. The differing cadence is a rough indication of how many examples of each lower level you need to build a general pattern, eg. you may have 20 or so individual design decisions to make to ship a feature, you might ship 3 features from each UX insight, you might refresh the whole product's UI roughly each year as the market changes, and you need experience from 2-3 full visual refreshes to understand what sort of patterns need to form guidance for the next generation of designers.
I think there are multiple phases of a product. At one end, you have a startup still searching for product market fit. You shouldn't have a design systems team in such an organization. Consistency doesn't matter because you might only have one instance of many design elements.
However, would you feel the same if you were using Kayak and each page had a separate set of components? How would it feel if Slack had different dropdowns on their direct messages page than their channels? At some point, your users expect standardization and consistency, and you don't need every team deciding their buttons will be slightly different sizes and colors because of the team designer's tastes.
It really is a spectrum; as your product matures and your brand identity finds success, the advice of the article becomes more and more important.
Can't the author's view be fitted into an interative process though?
Like, the design version of avoiding premature abstraction.
He mentions "product teams" moving faster than the design system, which creates pressure to extend the design system.
This can lead to flawed implementation of the design system.
So maybe the product team should go with some band-aid during development if needed, and explicitly pass the requirements to the design system team, who can then refine and extract reusable components.
Add of course, steady communication between people implementing features and people implementing design components should accompany this process.
I am not sure if that's what TFA means, because I haven't read the whole thing.
But I think design systems should be polished, simple, and provide a rock-solid API, and I think that the way to achieve this really might require patience.
It's not even needed to have these tasks be distributed among strictly separate teams to follow this line of thought, right?
Could be the guiding principle even of one single developer.
The concept of “pace layers,” to me, is a way to describe the iterative process:
1. Determine the base requirements.
2. Build the first draft.
3. Determine what parts of the first draft are useful. Capture those in a design guide.
4. Iterate on the parts that were useful but not fully fleshed out.
5. Add refinements to the design guide.
6. Define adjusted and new requirements. Pull in elements from the design guide as applicable, design and build new elements when they don’t exist.
7. Repeat.
(Note: I’m sure I truncated some steps you can fit in the flow)
Design systems are living documentation and a lagged record of solutions that work in context. They are incomplete and will always be missing things but with each subsequent iteration they should continue to evolve and adapt.
The design system moves at a slower velocity than the product development which informs it. This is why the phase layer model works well for me to help describe this iterative process.
This compliments your desire for minimal design upfront and rapid development with engagement and validation with the people who are putting it to use.
> I mention this because I find myself in complete disagreement with the article in question.
You are absolutely right. The article reminds me strongly of what Harry Frankfurt refers to in "On Bulshit".[1] If someone is not even remotely able to explain what moving fast actually means in his context, then everything and nothing follows from this.
How do you draw the conclusion that the author can't explain what he means by moving fast? Just because it wasn't adequately explained for someone with your worldview and experience doesn't mean that it's bullshit. Other possibilities are that if you had a face-to-face conversation he could explain it to you, or that you lack the domain experience and context to understand it.
Personally as someone with 25 years web product engineering experience and working very closely with design at large companies, I can quibble with a lot of the details and phrasing, but the overall message makes a lot of sense, and I have personally witnessed the dysfunction of trying to evolve DLS elemtns at the same speed as day-to-day product design on more than one occasion.
Not doing something is not the same as not being able to do something. That should be pretty obvious to most people. Reach out and contact the author and find out rather than assuming that he's unable to explain what he means. His contact info is linked from the article page, click on his name.
> Not doing something is not the same as not being able to do something
This is a vacuous statement. We can only look at what they write, not what they're thinking inside their head when they write it, so too for understanding whether they can actually explain something or not. Telling someone to contact the author when the author themself can just...write it down in the initial article is uncharitable.
> Telling someone to contact the author when the author themself can just...write it down in the initial article is uncharitable.
This part of your comment really amuses me. It's uncharitable of me to suggest reaching out for clarification instead of assuming the author is incapable of clarifying. That's what's uncharitable in this thread. Not the assumption that the author can't clarify their statements, but suggesting reaching out instead of assuming that. I'd ask you to clarify, but you could have just...written it down in your initial comment.
I think your interpretation of the meaning of "can't" is excessively sophistical. Of course, if someone does not do something which is to be expected, we can never completely rule out that he might be able to. But this is besides the point here. There is a severe flaw in the author's line of thought, something central he does not clarify. The reader is under no obligation whatsoever to reach out to the author for clarification. The author should have explained it in the first place. The conclusion that he was unable to do so is sound.
That is too simple. There is a whole academic discipline that makes such serious arguments -- or rather couple of them like the different kinds of literary studies, philologies and philosophical hermeneutics. Not to speak of all sorts of publications, tv talks and other places where people make serious arguments about based on their different perspectives. Tens of thousands of people make a living from that and a lot more study or follow it.
In my experience, following the advice given in the second paragraph is a good way to end up with both unmaintainable software and unhappy users. Having a design system upfront encourages consistency in visual and interaction design, and tends to nudge towards a consistent implementation. Consistent implementation is usually easier to iterate on, and tends to remain consistent with lower effort in the face of changing requirements.
I've used products and worked on projects that were built using the "pure" iterative approach they're espousing. You can always tell, and it's never been positive.
This is personal branding designed to awe and audience with little actionable advice.
Like everything in the like, there are some truths: mindset based around path with incremental improvement fares better that holistic-first approaches. The abstract concepts with false depth doesn't help on the key subject.
I would paraphrase the entire article by saying that the only way to ship fast and good is to in depth on designed simple reusables, build your product around an integration of those simple reusables, take measure of the complexity of the result, and then go on understanding how to improve while keeping and eye on overall complexity.
This article is stating the obvious about any software abstraction:
Don't over generalize up front but look at commonly used patterns and create abstractions from there that fit many use cases.
At the same time, there are common patterns that people expect to be there (a button component), and I'm always shocked when design system teams spend tons of money writing their own vs reusing other existing component libraries.
On top of this all: component libraries need to take tons of non functional requirements into account nowadays (SSR compatibility, lazy loading data for paginated tables and how components interact with hybrid sever/client data loaders, offline caching of rendered components in service workers, etc), so not having some really good actual software engineers on the "design system team" can end in total disasters.
I see this more and more, overly generic team and function names: design system. System engineer. Words like system and design are meaningless, could mean anything. We're all working in a context, so we're all part of a system, everything is a system. None of us are stacking bricks in a predetermined shape, we are all designing.
Design is really NOT a big deal. It has been overhyped over the last decade.
It is NOT a competitive advantage and if anything it hinders innovation. Please STOP putting such a high importance on design.
Much more important aspects of products that have been widely neglected over the past decade:
- data portability
- privacy
- reliability
- extensibility
I've yet to see a web designer or graphic designer think things through. My experience is that they're entry level freelancers that perform the exact task requested, nothing else, and e.g. consistency has to be handled above their pay grade. I don't think I can agree to your definition of the word design.
I think you missed my point entirely.
The value of design is in a bubble (hype) and the data portability, privacy, reliability, extensibility are undervalued.
There is a huge market distortion caused by incumbent big companies who benefit from the bubble and the undervaluation of data portability, privacy, reliability, extensibility.
Design has many facets. Are you purely referring to visual design?
Because I wouldn’t call focusing on usability, accessibility and solving the right problems for users is a waste of time or being overhyped. These will increase your competitive advantage.
I think you might be using "design" to refer to visual design or UX design. But this article is about system design, which encompasses the factors you've described above.
It’s not about system design. It’s about design systems, which are custom UI component libraries used across a product or set of products to enforce UI consistency and code re-usability.
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.