Ship faster by building design systems slower (2023)
bigmedium.com
bigmedium.com
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.
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.
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.
No, it's not arrogance driving people to do their own design system. But corporations engage in all sorts of dysfunctional (to the whole) rituals.
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?
"In the short run, the market is a voting machine but in the long run, it is a weighing machine." - Benjamin Graham
The market does care, eventually. How many of those types of companies that you mentioned are now bankrupt or out of business?
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
He just doesn't. Quote the passage were he does!
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.
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.
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.
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.
Addendum: Added note about layer velocities.
Addendum 2: Fixed a few typos
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.
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.
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.
Excel and its piss poor interface has caused quite a bit of loss: https://www.computerworld.com/article/2533631/excel-error-le... (for your amusement, you should not feel bad for any one involved in this).
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 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.
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.
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.
Much more important aspects of products that have been widely neglected over the past decade:
- data portability
- privacy
- reliability
- extensibilityYou must see the irony in advocating for 4 things that the market has proven it doesn’t particularly value as being some kind of advantage?
Checking https://en.m.wiktionary.org/wiki/design, these two sound like what you're talking about:
> 1. A specification of an object or process, referring to requirements to be satisfied and thus conditions to be met for them to solve a problem.
> 2. A plan (with more or less detail) for the structure and functions of an artifact, building or system.
But these sound like what a web designer or graphic designer do. And they are more about being artistic than about thinking things through:
> 3. A pattern, as an element of a work of art or architecture.
> 4. The composition of a work of art.
> 6. The shape or appearance given to an object, especially one that is intended to make it more attractive.
> 7. The art of designing > Danish furniture design is world-famous.
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.
Your vision of design is too wide.
The deliverable of design is a prototype with more or less refinement that the engineering team can get inspiration from.
It's hardly THAT important.
Engineers are the ones who really are solving the problems.
Whether it's the right problems is a matter of opinion.