Avoid z-index Escalation in the System
Stacking conflicts tempt teams into an arms race of ever-larger z-index values, 'my thing is more important than your thing', until the numbers are meaningless and overlays fight each other unpredictably.

My unglamorous research leads to provocative positions that push people to reconsider their own practice.
A transparent log of the design systems and technical decisions behind my work, from semantic tokens and theming to layout, components, and interaction patterns. Each entry documents the context, the alternatives considered, and the reasoning behind the choice.
9 decisions documented
Stacking conflicts tempt teams into an arms race of ever-larger z-index values, 'my thing is more important than your thing', until the numbers are meaningless and overlays fight each other unpredictably.
Utility-class frameworks promise speed: every style has a ready-made classname, and you compose an interface by stringing them together. But that bargain pushes concrete values into the markup (`border-teal-darkest`), so the same classnames that feel convenient also pin an element to a fixed look and fight a themable token system. Left without a convention, projects also drift into a soup of ad-hoc, colliding classnames (`btn`, `main-navbar` defined many times over) that no longer say what an element actually is.
Designers from traditional backgrounds reach for fixed grids on the web. But overlaying a curated grid onto the browser's own alignment algorithms fights the medium and produces brittle, less accessible layouts. A grid also assumes the designer controls the final rendering, when in practice the user does, through their font size, their zoom level, and the language they read in.
Tags, type labels, and status markers are non-interactive metadata, yet the common chip/pill treatment (background, border, rounded box) makes them look like buttons. When labels and real controls share the same shape, users cannot tell what is clickable, so they hesitate or avoid the controls entirely.
A modal is the default reach for almost any interruption, but it is often a way to avoid organizing the page: when content has no obvious home, it gets dropped into a dialog that appears on demand. It is also one of the hardest patterns to get right. Focus management, screen reader announcements, and stacked dialogs are all genuinely difficult, and even the native `<dialog>` does not hand you full accessibility for free.
Design systems struggle with expressive fragments, like highlighting a premium product on an otherwise uniform page. The instinct is to mint new tokens for each moment, but that bloats the token set and erodes consistency. Figma's 2023 introduction of Variables with Modes sharpened the question, and it's the idea I went on to promote as Mise en Mode at mode.place.
Runtime theming opened a large value space, but the real gap was upstream: variables carried almost no classification. A variable held a value yet said little about what it was for, so teams reasoned about them inconsistently and a variable's meaning lived only in the head of whoever defined it.
The traditional design system move is to spot that an organization has, say, 20 different buttons and have experts synthesize them down to a few. The trouble is that the wider org stops trusting decisions that don't account for its needs, so adoption suffers. What has been missing from this work is transparency.
A visually appealing interface earns goodwill: the Aesthetic-Usability Effect means users forgive real usability problems when something looks nice, so color can quietly mask a design that does not actually work. At the same time the industry reaches for ever-larger color palettes and treats color as the thing that makes an interface good, when it is closer to the finish than the foundation.