Where house style actually comes from
There is a version of design history in which every visual decision on a screen was made by a person, in a room, with a reason. The typeface was chosen. The corner radius was weighed. The shadow offset was argued about. This is mostly not true. A significant portion of what reads as intentional house style is the residue of a framework default that nobody changed, a component library that shipped with opinions already baked in, and a starter template that went to production before anyone looked closely at it.
This is not laziness in any simple sense. Build cycles are short, teams are small, and framework defaults exist precisely because somebody made defensible choices at scale. The problem is not that defaults exist — it is that they accumulate silently. One choice compounds another. The base font size is left at the framework value. The primary colour is swapped out but the border-radius on the button component is not. The spacing scale stays at the library preset. Six months later, the result looks like a decision, reads as intentional, and is called brand.
Sixteen pixels and a shadow is the canonical example of this drift: two values so deeply embedded in browser and component defaults that they followed millions of interfaces into production without any positive act of choice. Neither sixteen-pixel body text nor the default drop shadow is wrong, but neither was selected by most of the people using them. They were simply there.
The compounding problem
The deeper issue is that defaults don't just persist — they compound. A component library supplies a card with 8px corner radius and a specific shadow. The product team changes the brand colour and calls the system theirs. Two years later that card is everywhere in the product, including contexts where a card was never the right container, because it was the ready-made object and nobody wrote a policy for when not to use it. The card as universal container describes this exact expansion: the rounded rectangle metastasised not because it was always correct but because it was always available.
Type hierarchies follow the same logic. A design system might inherit its scale from a framework that inherited it from a typographic convention that was itself a rough consensus rather than a prescription. Nobody on the current team chose the ratio between the H2 and the body text. It was there in the config file, it seemed reasonable, and the deadline was Tuesday. Over time the hierarchy ossifies; changing it means touching every component that references a token, which means the default becomes permanent not because it is good but because it is load-bearing.
Motion works this way too. Framework-supplied transitions have durations and easing curves that ship with the library, and the most common customisation is to change nothing. An ease-in-out at 200ms is defensible. It is also essentially universal at this point, which means it no longer communicates anything particular about the product using it — it communicates "we did not change the default."
What an audit actually surfaces
None of this is an argument against defaults — it is an argument for knowing which of your decisions are yours. A useful way to approach an existing system is to move through it asking, for each visual property, whether someone on the team can name the moment and the reason it was chosen. Type size: yes or inherited? Colour ramps: specified or accepted? Shadow on the modal: ours or shipped? That question — was this chosen or inherited? — will surface more genuine design work than most visual audits do, because it distinguishes the system you made from the system you received.
Sometimes a framework default is correct for your context; the right move is to keep it consciously, to own it, to document it as a choice rather than an accident.
The inherited pieces are not necessarily wrong. Sometimes a framework default is correct for your context; the right move is to keep it consciously, to own it, to document it as a choice rather than an accident. The problem is when inherited defaults are mistaken for brand, when the absence of a decision is read as an expression of one. What looks like a consistent visual language often turns out, on inspection, to be a layer of genuine decisions sitting on top of a much thicker layer of things nobody chose — and nobody went back to ask about.