When should you design in the browser vs in a design tool?

Design in the browser when the hard part of the problem is live behavior, real responsive adaptation, interaction, or content that varies, and design in a tool when the hard part is visual exploration, the look, or communicating an idea. The deciding question is whether the medium has to be live to answer what you are actually unsure about. If a static frame would mislead you because the real uncertainty only shows up when things move, resize, or fill with real data, the browser is where the design happens. If the uncertainty is about composition, hierarchy, color, or how a layout reads, a design tool answers faster.

The reason this works as a test is that each medium tells the truth about different things and lies confidently about the rest. A design tool shows a layout at one fixed size with placeholder content arranged exactly as you placed it, which is perfect for judging proportion and feel and useless for judging how that layout behaves when a heading wraps to three lines, a column has to collapse, or a hover state needs to survive a touchscreen. The browser shows the opposite: it tells you exactly how text reflows, how spacing holds up across widths, and how an interaction actually feels, while making it slower and clumsier to try ten visual directions in a morning. You design where the real uncertainty lives because that is the only place the medium will give you an honest answer instead of a comfortable one.

A designer recognizes the split the moment a layout depends on something a static frame cannot hold still. Consider a card grid that has to wrap gracefully from one to four columns, with cards of uneven content height, a filter that animates results in and out, and a sticky header that shrinks on scroll. You can mock the desktop and mobile states in a tool, but every interesting question, where the grid reflows, whether the uneven cards look intentional or broken at the in-between widths, how the shrink feels at real scroll speed, only has an answer in the browser. Contrast that with deciding the visual identity of those cards, the type pairing, the spacing rhythm, the photographic treatment, the overall composition of the page. Those are explored far faster by laying out variations in a design tool, where you can see five directions side by side without writing a line of code. The same project moves between both mediums depending on which question is open.

Worth flagging: this is not a rule about which software to standardize on, and most real work uses both within a single feature. The mistake is the reflexive habit of always designing the whole thing in a tool first and only then building it, which quietly assumes the visual is the hard part even when behavior is. When behavior is the open question, that order means you finalize a beautiful static comp, hand it off, and discover in the build that the design never actually worked in motion, forcing a redesign disguised as development. The reverse mistake also exists: jumping into the browser to fight CSS over a visual decision you could have settled in ten minutes of exploration in a tool. Neither medium is the serious one. The discipline is matching the medium to the kind of uncertainty in front of you, not to a preference or a workflow you always follow.

Before you open either, name what you are actually unsure about on this screen. If the answer is how it behaves, adapts, or feels in use, design that part in the browser where the behavior is real, even if a static comp would look more finished. If the answer is how it looks, reads, or composes, explore it in a design tool where you can move fast and compare directions. Let the open question pick the medium, switch between them as the question changes within the same feature, and never let a tool-first habit hide a behavior problem until it is expensive to fix.