Design Craft

Design is problem-solving, not decoration. A designer is accountable for whether the user gets the outcome, not whether the screen looks polished. That line, from Product Designer, is the whole practice compressed into one sentence. Everything below is what it looks like day to day.

Design Serves the Definition#

Design does not run ahead of the problem, and it does not run separately from it. In Define, PD writes design considerations, UX decisions, and constraints in the same 45 minutes PM and PE are writing theirs, independently, before anyone anchors on a direction. What comes out goes into the definition doc as design decisions and the reasoning behind them, sitting next to the user flow and the technical approach, not off in a separate file.

This means a design is only as good as the problem statement under it. A sharp, data-backed problem from Discover gives design something real to solve. A fuzzy one produces a fuzzy design no matter how much craft goes into the screens. If a designer finds themselves polishing a flow before the problem is pinned down, that is a sign to go back, not forward.

Real Constraints, Real Data#

Product sense is the attribute that separates a designer from a decorator: accountable for the outcome, not the polish; knowing what is worth designing and what to cut. That judgment only works against real inputs. A design built against an assumed user, an assumed constraint, or an assumed dataset is a guess wearing a mockup.

The same discipline Discover applies to problem statements applies to design: validate against what is actually happening, not what feels true. User insight (getting to the real problem behind the request, separating what users say from what they do) is a craft attribute for exactly this reason. A design that “feels right” but was never checked against a usability test or real usage data is unproven, not finished.

Low-Fidelity Before High-Fidelity#

Prototyping & delivery is measured by getting a working version into hands fast, then into the codebase cleanly, not by how refined the first draft looks. A senior designer prototypes the risky part early and ships in the codebase directly when that is faster than staying in the design tool. The hiring bar makes the failure mode explicit: a portfolio that is Figma work polished in isolation, with no time spent alongside engineering, is a flag, not a strength.

The order matters. Resolve the flow, the states, and the risky interaction first, at low fidelity, where changing your mind costs minutes. Spend polish on a direction only once it has held up. Reversing that order (high-fidelity screens for an unproven flow) means paying twice: once to make it pretty, again to redo it when the flow turns out to be wrong.

Make the Right Thing Obvious, the Wrong Thing Hard#

Interaction & UX is judged on whether the thing works without friction: the happy path, but also the empty states, the error states, the edge cases nobody asked about. A design that only handles the case where everything goes right is not done; it has just not met its edge cases yet.

Visual craft serves the same goal from the other side: hierarchy, type, and spacing that let someone read the right action at a glance, without a caption explaining it. Good design does not need to explain itself. If a screen requires a tooltip to be usable, the design has not finished its job; the layout has.

Consistency and Reuse Over Novelty#

The design system is not a constraint on craft, it is where craft compounds. Visual craft is graded on extending the system thoughtfully, not overriding it for a one-off effect; at Lead Designer and above, owning the visual bar means owning the system’s direction, not each individual screen. A novel pattern invented for a single flow is a cost the whole product pays later, in the same way a novel technology is a cost engineering pays later: unfamiliar, unproven, and one more thing every future designer has to relearn.

Reuse is not the absence of craft. Recognizing that an existing pattern already solves 90% of a new problem, and applying it well, is the craft: the same instinct Define asks of engineering when it asks “is there a simpler version of this?” before committing to something new.

Related: Product Designer, Define, Discover, Build