Every product team makes hundreds of small decisions nobody will ever notice. What a button looks like. Where the primary action sits in a dialog. How much space between elements. Which colors.
These decisions matter. They affect usability, accessibility, brand, and the quality of the experience. They are also not the reason the project exists, and they can take days.
Then another project starts, another team faces the same questions, and we make most of those decisions again.
That is where the cost sits. The problem is not having the discussion once. Sometimes it needs to happen. The problem is having it again five projects later, because the answer never became something anyone else could reuse.
This is not a discipline problem. Teams are doing exactly what we ask of them: solving the problem in front of them with the information they have.
The trouble is that most of our decisions live inside the finished product instead of somewhere others can inspect them. A screen shows another team what was decided. The screen rarely tells them why. So the next team starts over.
Multiply that across products, teams, business units, and years of work, and a lot of capable people spend their time rediscovering answers we already had. No single conversation feels expensive. The cost is in having the same one again and again.
A shared pattern ends the argument by making the answer already decided, and open to inspection.
The reasoning sits alongside the decision. A team can use it, question it, improve it, or make the case for something better. What nobody has to do is reconstruct the whole thing from zero.
Most people who work near UX know the usability principles, Nielsen Norman's ten heuristics among them. They are useful because they help us ask whether an experience works: whether the system communicates clearly, whether people can recover from mistakes, whether it behaves the way they expect.
Shared standards answer a different question. Not whether a thing works, but what good looks like here. How our products should behave. How accessibility shows up in the experience. How our brand feels once it becomes software. What someone should be able to expect moving from one tool to the next. Those answers cannot come from a generic checklist, because they are specific to the experience we want to create.
Accessibility is the clearest example, and it is the argument our design system is built on. When contrast, keyboard behavior, focus states, labels, and interaction patterns are built correctly into shared components, accessibility stops being something we discover in an audit six months later and becomes part of the starting point. Brand works the same way. Nobody should have to hunt down the correct colors.
That is the most useful thing a standard does. It turns something we value into something that happens by default.
Consistency gets treated as a visual concern, as though the goal were making every application look identical. That is not the point. The person who benefits most is the one moving between those applications all day. They should not have to relearn basic behavior every time they cross from one tool to the next. A familiar pattern lets someone spend less attention on the interface and more on what they came to do.
That is not sameness. It is fluency.
There is a real difference between spending an afternoon on a hard problem, and an afternoon debating a button another team already debated last year. Both are tiring. Only one feels like progress.
I have spent an afternoon arguing about where a button should go. I was right.
It was still a terrible use of the afternoon.
There is a flip side. Not every decision should become a standard. Teams need room for judgment, experimentation, and context. Turn every preference into a rule and the system becomes another source of friction instead of removing one.
So the test is simple. Does this end a decision teams should not have to make twice?
If the answer takes genuine product judgment, it belongs with the team. If we have solved it repeatedly, learned from it, and there is little left to learn by solving it again, it belongs in the shared system. Getting that line right is the work.
It is also not a line one person should draw and hand to everyone else. The standards that hold up are the ones the people using them have argued with, and every team that pushes back on one leaves it better than they found it.