"UX is how it works, UI is how it looks." You've heard that line, and it's technically true, and it still manages to explain almost nothing useful. It's the kind of definition that sounds complete right up until you try to apply it to an actual decision on an actual product. So let's skip the dictionary version and look at what UX and UI decisions actually look like, side by side, on the same feature.
Take a body-part selector — a real feature from the Piction Health project, where physicians need to indicate where on a patient's body a skin condition appears. A UX decision and a UI decision on this exact feature look completely different, even though they're solving the same screen.
The UX decision was: should this be one screen with a full-body diagram, or a guided flow where the physician narrows down region by region? We chose a guided, tap-only interaction — no zoom, no rotate, no pinch gestures — because the people using this in a clinical setting are moving fast, often one-handed, and can't afford a fiddly interface. That's a decision about interaction logic, flow, and cognitive load. Nothing about how it looks yet.
The UI decision came after: what color indicates a selected body region? How much contrast does the confirmation state need so it's unambiguous at a glance? What's the exact tap target size so a physician wearing gloves doesn't mis-tap? That's typography, color, spacing, and visual feedback — the surface the UX decision gets expressed through.
Both decisions were necessary. Neither one was sufficient on its own. A gorgeous visual treatment on the wrong interaction model would still fail physicians in a rush. A perfect interaction flow with unclear visual feedback would leave them unsure if their selection actually registered.
This is the single most common misunderstanding I run into with founders who haven't worked with a designer before. UI is treated as a coat of paint applied at the end — pick some colors, round some corners, ship it. But UI is a functional layer, not a decorative one. Whether a button reads as clickable, whether an error message actually gets noticed, whether a data table is scannable at a glance — these are UI problems, and they directly affect whether a product is usable, not just whether it's attractive.
A useful test: if you could swap out the entire visual style of a screen — different colors, different type, different iconography — and the feature would still work exactly as well, then what you're looking at really is "just" decoration, and that's fine, that's brand expression. But if changing the visual treatment would make the feature harder to use (lower contrast on a critical action, ambiguous iconography, unclear hierarchy) then you're looking at UI decisions that carry real functional weight.
NeighborSchools needed to walk prospective daycare providers through genuinely complex, state-specific licensing requirements — the kind of content that's dense even for someone motivated to read it. The UX decision was to abandon the long-form application entirely in favor of a micro-chat interface: one question at a time, sequential, conversational. That decision had nothing to do with visual style — it was about reducing how much a provider had to hold in their head at once, and keeping them engaged step by step instead of confronting them with a form that looks like a mortgage application.
The UI decisions that followed were about making that chat format actually feel supportive rather than robotic: warm, high-contrast typography; a tone in the copy that reads like a helpful assistant instead of a legal document; generous spacing so each question feels like a small, manageable step rather than one of fifty. Swap the interaction model back to a traditional long-form and none of those UI choices would have solved the underlying problem — providers would still be abandoning halfway through a wall of fields.
Some companies try to split this into two roles: a UX researcher/architect and a separate UI/visual designer, handing off between them. At scale, with dedicated specialists collaborating closely, that can work. At the size most startups are operating at, splitting UX and UI into disconnected hires usually produces a disconnected product — an interaction model designed in isolation, then a visual layer bolted on by someone who wasn't in the room for the reasoning behind it. The handoff loses exactly the context that made the original decision correct.
What actually works is one person (or one small, tightly synced team) thinking about both simultaneously — because in practice, you can't fully separate them. The interaction model constrains the visual options, and the visual treatment affects whether the interaction model actually reads correctly to a real user under real conditions.
This is also why, when founders ask whether they need to hire "a UX person" or "a UI person," my honest answer is usually neither framing is quite right. What you need is someone who can move fluidly between the two — who can sit with an unclear flow and figure out the right structure, and then carry that same reasoning into how it should look and feel, without losing the thread between the two in a handoff.
If you're trying to figure out whether your product's problems are structural (UX) or surface-level (UI) — or, more likely, some tangle of both — I'm glad to take a look. Get in touch and let's talk through what you're seeing.
Disconnected brand and product design creates a fractured user experience. The case for having both aligned under one design system from the start.
Read post
A step-by-step look at how a rough idea becomes a buildable MVP spec — for founders who have just an idea, or a spec with no design yet.
Read post
A practical, non-hype take on adding AI to your product — matching AI to a real user problem, designing for its imperfection, and avoiding the checkbox-feature trap.
Read post
