Logic-driven UI design lessons from 20+ years shipping products

Most inconsistent interfaces are not the result of bad taste, but of decisions made without a shared logic. When your team designs by gut feel, every new screen adds a slightly different interpretation of spacing, hierarchy and color. Over time, this creates friction for users and slows engineers down.

A logic-driven UI process flips this. Instead of asking “what looks good here?”, you ask “what is the rule we're following?” That rule might be based on information architecture, motion, or content priority, but it's always explicit. This post walks through a set of reusable rules I use on real product teams.

1. Start with a content map, not components

Before opening Figma, list the information the user needs to see and the decisions they need to make. Map each piece of content to an importance score. Only after that do you decide layout. This mirrors the content-first approach used by Smashing Magazine and other leading design publications.

In code, this often translates into a small set of layout primitives, like a vertical stack component with fixed spacing tokens, rather than one-off flexbox concoctions. Your React (or Vue/Svelte) code becomes simpler because the layout rules are baked into a few utilities.

2. Use one spacing scale everywhere

Pick a spacing scale (for example, 4 / 8 / 12 / 16 / 24 / 32) and use it religiously. The 8‑pt grid is popular for a reason: it makes alignment trivial for both designers and engineers. In Tailwind this is almost free since you're already thinking in increments of 4.

Once you adopt a single spacing scale, code review becomes easier. You can literally scan a PR for suspicious spacing values and comment when someone introduces an oddball like margin: 13px;.

3. Encode your decisions in tokens

Design tokens are not just for big design systems. Even a solo maker benefits from encoding color, typography and radius as tokens that live in one place. The W3C design tokens spec gives a good mental model, but you can start as simply as a TypeScript object or Tailwind config.

The key idea: every visual decision has a name. Instead of “that slightly darker grey”, it's text-muted. Instead of “the rounded buttons on marketing pages”, it's radius-pill. When you name a decision, you can reuse it and reason about it.

If you adopt even two or three of these logic-driven ideas, your UI will immediately feel more coherent, and your engineering team will spend less time fighting layout bugs and more time shipping features.

4. Applying logic-driven thinking to real features

To make this concrete, take a typical "settings" page. Instead of scattering toggles and inputs based on implementation order, you can map each control to a user question: "How do I manage notifications?", "Where do I change billing?", "How do I export data?" Group controls under headings that mirror those questions, and keep spacing and typography consistent across each group.

On engineering teams I work with, we encode those groups as simple layout components and data structures. A settings module might export an array of sections, each with a title, description and list of controls. The React component simply maps over those arrays. This keeps layout logic honest and makes it much easier to add, remove or reorder options without visual regressions.

Over a full product, this style of logic-driven thinking compounds. You spend less time arguing about subjective taste and more time discussing explicit rules, which is exactly what seasoned designers and engineers need when collaborating at scale.