A product develops a language through its words, visual system, behavior, and code. When that language stays consistent, people can understand a new part of the product without learning everything again.
The same word should travel
In Building interfaces that scale, I wrote about making product language travel through the whole system. If customers know something as an experiment, that word should remain recognizable in the interface, code, contracts, documentation, and team conversations.
My work on LinkedIn lift test reporting made that especially clear. I designed a shared TypeScript reporting architecture that normalized Lift entities into a typed model. The model handled the heavy work, including formatting values and translating differences in the underlying data, so reusable UI components could consume one predictable shape.
That foundation brought two reporting flows together and enabled a third revenue-based experiment type. It was built for multiple lift products rather than one screen. Shared components could frame the results for their product while the entity model kept the meaning and data transformation in one place.
Framing matters because advertisers use these results to make decisions. Experiment, control, treatment, lift, and measurement should not quietly change meaning between products or between the UI and the system underneath it.
Small actions carry language too. Save, Cancel, and Launch imply different outcomes. An error should say what happened and what someone can do next. The wording is part of the behavior, not decoration added at the end.
The visual system should travel too
Visual language needs the same consistency as product terminology. Across products and teams, shared components give repeated interactions a common starting point. Buttons, fields, and status messages should not invent new loading, error, disabled, focus, and success behavior every time they appear.
This becomes more useful as an organization grows. A shared component lets an accessibility fix, focus improvement, or interaction update reach every product using it. LinkedIn has written about how a shared design language helps different products and teams still feel connected.
I prefer components that ask for a role or intent instead of a hard-coded appearance. A danger state should ask for danger, not a particular shade of red. The theme can change while the meaning stays put.
:root {
--app-color-background: #f3f3f1;
--app-color-text: #1a1a1a;
--app-color-text-muted: #6f6f6f;
--app-color-danger: #b42318;
}
@mixin app-dark-theme {
--app-color-background: #1a1a1a;
--app-color-text: #e5e5e5;
--app-color-text-muted: #9a9a9a;
--app-color-danger: #ff8a80;
}Muted and danger retain their meaning across themes even though their values change. The same idea applies to spacing, typography, motion, and interaction states. Components can preserve the rule while leaving enough room for each product to have its own voice.
There is a limit to sharing. I reuse a primitive when the interaction or meaning is actually the same. Two products looking similar today is not enough reason to force them into one abstraction.
Consistency creates room to play
When designing my own personal portfolio, the idea was to keep things simple. The writing carries most of the personality, while typography, thin borders, visible focus states, generous spacing, and theme keep the interface familiar.
The games loosen the tone without feeling disconnected from the rest of the site. Chill, Casual, and Cracked fit them better than the usual difficulty labels. They share visual rules and a few interaction primitives, but Stack, Snake, and Space Cowboy keep their own engines.
When I first added a game to the homepage, its panel competed too strongly with the bio and Notes. Making it smaller and muting it until someone interacts restored the hierarchy without losing the playful idea.
Most people will never notice the individual design-system decisions behind any of this. Hopefully, they just leave feeling like the product made sense. And TBH that's a better compliment anyway.