Why Icons Alone Aren’t Enough I’m a firm believer in text labels. Interfaces are over-stuffed with icons. The more icons we have to scan over, the more brain power we put toward making sense of them rather than using the tools they represent. This slows us down, not just once, but over and over again. While it may feel duplicative to add a text label, the reality is that few icons are self-sufficient in communicating meaning. The Problems that Icons Create 1. Few icons communicate a clear, singular meaning immediately It’s easy to say that a good icon will communicate meaning — or that if an icon needs a text label, it’s not doing its job. But that doesn’t take into consideration the burden that icons — good or bad — put on people trying to navigate interfaces. Even the simplest icons can create ambiguity. While a trash can icon reliably communicates “delete,” what about the common pencil icon. Does it mean create? Edit? Write? Draw? Context can help with disambiguation, but not always, and that contextual interpretation requires additional cognitive effort. When an icon’s meaning isn’t immediately clear, it slows down our orientation within an interface and the use of its features. Each encounter requires a split-second of processing that might seem negligible but accumulates across interactions. 2. The more icons within an interface, the more difficult it can be to navigate. As feature sets grow, we often resort to increasingly abstract or subtle visual distinctions between icons. What might have worked with 5-7 core functions becomes unmanageable at 15-20 features. Users must differentiate between various forms of creation, sharing, saving, and organizing - all through pictorial representation alone. The burden of communication increases for each individual icon as an interface’s feature set expands. It becomes increasingly difficult to communicate specific functions with icons alone, especially when distinguishing between similar actions like creating and editing, saving and archiving, or uploading and downloading. 3. Icons function as an interface-specific language within a broader ecosystem. Interfaces operate within other interfaces. Your application may run within a browser that also runs within an operating system. Users must navigate multiple levels of interface complexity, most of which you cannot control. When creating bespoke icons, you force users to learn a new visual language while still maintaining awareness of established conventions. This creates particular challenges with standardized icon sets. When we use established systems like Google’s Material Design, an icon that represents one function in our interface might represent something entirely different in another application. This cross-context confusion adds to the cognitive load of icon interpretation. Why Text Labeling Helps Your Interface 1. Text alone is usually more efficient. Our brains process familiar words holistically rather than letter-by-letter, making them incredibly efficient information carriers. We’ve spent our lives learning to recognize words instantly, while most app icons require new visual vocabulary. Scanning text is fundamentally easier than scanning icons. A stacked list of text requires only a one-directional scan (top-to-bottom), while icon grids demand bi-directional scanning (top-to-bottom and left-to-right). This efficiency becomes particularly apparent in mobile interfaces, where similar-looking app icons can create a visually confusing grid. 2. Text can make icons more efficient. The example above comes from Magnolia, an application I designed. On the left is the side navigation panel without labels. On the right is the same panel with text labels. Magnolia is an extremely niche tool with highly specific features that align with the needs of research and planning teams who develop account briefs. Without the labels, the people who we created Magnolia for would likely find the navigation system confusing. Adding text labels to icons serves two purposes: it clarifies meaning and provides greater creative freedom. When an icon’s meaning is reinforced by text, users can scan more quickly and confidently. Additionally, designers can focus more on the unity of their interface’s visual language when they’re not relying on icons alone to communicate function. 3. Icons are effective anchors in text-heavy applications. Above is another example from Magnolia. Notice how the list of options on the right (Export, Regenerate, and History) stands out because of the icons, but the text labels make it immediately clear what these things do. See, this isn’t an argument for eliminating icons entirely. Icons serve an important role as visual landmarks, helping to differentiate functional areas from content areas. Especially in text-heavy applications, icons help pull the eye toward interactive elements. The combination of icon and text label creates clearer affordances than either element alone. Finding the Balance Every time we choose between an icon and a text label, we’re making a choice about cognitive load. We’re deciding how much mental energy people will spend interpreting our interfaces rather than using them. While a purely iconic interface might seem simple and more attractive, it often creates an invisible tax on attention and understanding. The solution, of course, isn’t found in a “perfect” icon, nor in abandoning icons entirely. Icons remain powerful tools for creating visual hierarchy and differentiation. Instead, we need to be more thoughtful about when and how we deploy them. The best interfaces recognize that icons and text aren’t competing approaches but complementary tools that work best in harmony. This means considering not just the immediate context of our own interfaces, but the broader ecosystem in which they exist. Our applications don’t exist in isolation — they’re part of a complex digital environment where users are constantly switching between different contexts, each with its own visual language. The next time you’re tempted to create yet another icon, or to remove text labels, remember: the most elegant solution isn’t always the one that looks simple — it’s the one that makes communication and understanding feel simple.

Challenge: Create a private label for the legendary sixth-floor Food Hall at KaDeWe — also known as the culinary heaven...

I’ve been working on a transition to using light-dark() function in CSS. What this boils down to is, rather than CSS that looks like this: :root { color-scheme: light; --text: #000; } @media (prefers-color-scheme: dark) { :root { color-scheme: dark; --text: #fff; } } I now have this: :root { color-scheme: light; --text: light-dark(#000, #fff); } @media (prefers-color-scheme: dark) { :root { color-scheme: dark; } } That probably doesn’t look that interesting. That’s what I thought when I first learned about light-dark() — “Oh hey, that’s cool, but it’s just different syntax. Six of one, half dozen of another kind of thing.” But it does unlock some interesting ways to handling themeing which I will have to cover in another post. Suffice it to say, I think I’m starting to drink the light-dark() koolaid. Anyhow, using the above pattern, I want to compose CSS variables to make a light/dark theme based on a configurable hue. Something like this: :root { color-scheme: light; /* configurable via JS */ --accent-hue: 56; /* which then cascades to other derivations */ --accent: light-dark( hsl(var(--accent-hue) 50% 100%), hsl(var(--accent-hue) 50% 0%), ); } @media (prefers-color-scheme: dark) { :root { color-scheme: dark; } } The problem is that --accent-hue value doesn’t quite look right in dark mode. It needs more contrast. I need a slightly different hue for dark mode. So my thought is: I’ll put that value in a light-dark() function. :root { --accent-hue: light-dark(56, 47); --my-color: light-dark( hsl(var(--accent-hue) 50% 100%), hsl(var(--accent-hue) 50% 0%), ); } Unfortunately, that doesn’t work. You can’t put arbitrary values in light-dark(). It only accepts color values. I asked what you could do instead and Roma Komarov told me about CSS “space toggles”. I’d never heard about these, so I looked them up. First I found Chris Coyier’s article which made me feel good because even Chris admits he didn’t fully understand them. Then Christopher Kirk-Nielsen linked me to his article which helped me understand this idea of “space toggles” even more. I ended up following the pattern Christopher mentions in his article and it works like a charm in my implementation! The gist of the code works like this: When the user hasn’t specified a theme, default to “system” which is light by default, or dark if they’re on a device that supports prefers-color-scheme. When a user explicitly sets the color theme, set an attribute on the root element to denote that. /* Default preferences when "unset" or "system" */ :root { --LIGHT: initial; --DARK: ; color-scheme: light; } @media (prefers-color-scheme: dark) { :root { --LIGHT: ; --DARK: initial; color-scheme: dark; } } /* Handle explicit user overrides */ :root[data-theme-appearance="light"] { --LIGHT: initial; --DARK: ; color-scheme: light; } :root[data-theme-appearance="dark"] { --LIGHT: ; --DARK: initial; color-scheme: dark; } /* Now set my variables */ :root { /* Set the “space toggles’ */ --accent-hue: var(--LIGHT, 56) var(--DARK, 47); /* Then use them */ --my-color: light-dark( hsl(var(--accent-hue) 50% 90%), hsl(var(--accent-hue) 50% 10%), ); } So what is the value of --accent-hue? That line sort of reads like this: If --LIGHT has a value, return 56 else if --DARK has a value, return 47 And it works like a charm! Now I can set arbitrary values for things like accent color hue, saturation, and lightness, then leverage them elsewhere. And when the color scheme or accent color change, all these values recalculate and cascade through the entire website — cool! A Note on Minification A quick tip: if you’re minifying your HTML and you’re using this space toggle trick, beware of minifying your CSS! Stuff like this: selector { --ON: ; --OFF: initial; } Could get minified to: selector{--OFF:initial} And this “space toggles trick” won’t work at all. Trust me, I learned from experience. Email · Mastodon · Bluesky

Last semester at university we were given a really cool task. We had to choose an existing company that distributes...

Check out the light in my office right now 🤩 . AI effectively, but to understand how it fits into the larger patterns of human creativity and purpose. That’s a good thing — designers are good observers. No matter what the tech, we notice patterns we notice the lack of them. So in the midst of what is likely a major, AI-driven transition for us all, it’s worth considering that the future of design won’t be about human versus machine, but about understanding the pattern language that emerges when both intelligences work together in a system. As Christopher Alexander and his cohort might have said, it will be about creating a new kind of wholeness — one that honors both the computational power of AI and the nuanced wisdom of human experience.