Open almost any component library, template, or design system built in the last decade and you’ll find drop shadows doing most of the heavy lifting for depth: a card lifts off the page with a soft shadow beneath it, a button gets a shadow on hover, a dropdown casts a shadow to signal it’s floating above the content behind it. It’s such a standard convention that most teams stop treating it as a decision at all — it’s just what a card looks like.
Models Oddavell’s landing page runs to 7,838 pixels across twelve sections, and there is not one drop shadow anywhere on it. Not on cards, not on buttons, not on inputs, not on dropdowns, not on the footer. That absence is deliberate, and it’s a specific case of the fourth principle in the one-feature framework: subtract the category’s defaults, because every convention you remove is a differentiator you didn’t have to invent.
Why the removal reads as restraint rather than a gap
The reasoning behind the decision, from the designer directly, was framed less as an aesthetic preference and more as a category judgment:
“It was a conscious decision. Doing so made the website less generic and more classy.”
The word doing the most work there is “generic.” Drop shadows aren’t inherently unattractive — they’re extremely common, which is a different problem. A viewer who has spent any time online has seen thousands of shadowed cards, in dashboards, in SaaS products, in ecommerce listings, in exactly the kind of templated real estate site the three escapes post covers. The shadow itself has become a visual cliché of “this was built with a component library,” which is precisely the impression a project positioned as ultra-luxury and highly considered can least afford to give.
Removing the shadow doesn’t make a page look unfinished if the depth it was providing gets replaced with something else. On Oddavell, that replacement comes from three sources instead: the ground colour changing between sections (cream to taupe to ivory to black), black gradient scrims layered over photography, and images that physically overlap one another rather than sitting in separate, shadow-bounded containers. Depth still exists on the page — it’s just built from colour and composition instead of borrowed from a UI kit’s default elevation system.
Why subtraction is harder than it looks
Removing a default sounds like the easy half of a design decision — you’re doing less, not more. In practice it’s the harder half, because a shadow is doing real work in most interfaces: it separates a card from its background, it signals interactivity, it gives a flat surface a sense of hierarchy without anyone having to think too hard about it. Take it away and every one of those jobs has to be solved some other way, deliberately, section by section. That’s more design work, not less — it just doesn’t show up as a new element on the page, which is why it’s easy to undervalue in a review.
This is the same trade-off that shows up in the companion decision to leave blue out of a sea-facing palette, covered in why a sea-facing brand left blue out of the palette. In both cases, the “obvious” choice — blue for water, a shadow for a card — is exactly the choice every other project in the category is also making without examining it. Removing it costs more effort up front and produces a page that’s harder to mistake for a template.
Where this connects to the rest of the system
None of this works in isolation. A page with no shadows and a restrained palette still needs some consistent visual language carrying it, or the removal reads as absence instead of intent — which is exactly what the identity’s repeating curve motif is doing elsewhere in the system. The same shape that produces the wordmark and the signature pattern also defines the geometry of the components that would otherwise have relied on a shadow to read as distinct: a 1000px arch radius on the amenity tiles gives them a clear silhouette against their ground colour without needing elevation to separate them from the page. See one idea, three scales for how that repetition is doing the structural work a shadow would normally be assigned.
The practical takeaway for a project outside real estate: before adding a convention because “that’s what this kind of interface looks like,” ask what job it’s actually doing — separation, hierarchy, interactivity — and whether your specific system already has another, more considered way to do that job. If it does, the convention is optional. If removing it is also removing something every competitor in your category still has, it’s a differentiator you get for free.
