Part 6 · 2 chapters · ~15 min

The Triad

Product, Design and Engineering as three disciplines with three questions, the overlaps where the work happens and the documents each needs, the design review before build with checklists and owned outcomes, the failure modes, and pushing back on a design: the four grounds (unsafe, misleading, inaccessible, unnecessarily complex), the form that gets heard, and what is not a ground.

12

The triad

three disciplines, three questions
  1. Product owns why and what: the user problem, the outcome and its metric, scope and priority, the launch and its measurement. A PM's sketch is a prompt for Design, not a spec. The question: does this solve the problem for the user we mean, by when?
  2. Design owns how it feels and behaves: the flow (part 5), the screens, every state (part 4), the words, the motion, consistency with the system (parts 1 to 3). A spec the compositor cannot do or a layout the system lacks is a prompt for Engineering. The question: does this feel like one product and let the user do the thing without thinking?
  3. Engineering owns how it is built and what it costs: feasibility, performance (the FSD course), accessibility in code (part 2), correctness and security (the Trust course), the estimate, and the system's constraints (a new component is a governance proposal, part 3). An engineer redesigning a flow in a PR is a prompt for Design. The question: what will this cost, and what will break?
  4. The overlaps are the work, each with a document: Product and Design on scope versus experience (the brief); Design and Engineering on the screen versus the system (the design); Engineering and Product on the estimate versus the priority (the technical plan). A negotiation without a document is a memory.
  5. The design review: the three over the artefact (the Figma, the prototype, the preview deploy) before build, with the checklists from parts 4 and 5 and the engineering checklist (feasibility, components used and proposed, performance budget, accessibility, data needs, the Trust course part 7's edge cases). The output is decisions and open questions with owners, never approval or rejection.
  6. Failure modes: Product writing screens; mocks with no states; feasibility-only engineering reviews; reviews after build (every finding is rework); reviews without a checklist; a missing discipline (a feature built without a designer looks like it).
THE TRIAD
Product, Design and Engineering: what each owns, where they overlap, and the design review as the overlap made explicit
swipe the figure sideways, or tap expand for full screen
1/6
Product
Product owns why and what: the user problem (from research and data), the outcome and its metric, the scope and the priority, the launch and its measurement. Product does not own the screen; a PM sketching a screen is a prompt for Design, not a spec. Product's question to the others: does this solve the problem for the user we mean, by when?
13

When and how to push back on a design

four grounds, one form
  1. Unsafe: a money or identity flow missing the review step, idempotency, resumability or a designed failure state (the Trust course). The consequence is money or identity lost. "This flow can send a transfer twice on a double-tap; a review step with a single submit keeps the three-tap intent and prevents it."
  2. Misleading: a fee only on the receipt, the ledger balance shown while a withdrawal is pending, the upsell as the primary button, a fake countdown (part 5's dark patterns). The consequence is a false belief, a complaint, and in money products a regulator. "The user will believe they can spend ₦500,000 and the server will refuse at ₦380,000; show available, labelled."
  3. Inaccessible: a contrast failure, a hover-only control, an unnamed icon button, drag without a keyboard path, motion without a preference (the Disciplines course). The consequence is users excluded and, where the law applies, a liability. "This pair fails 4.5:1; text.muted on surface.raised passes and keeps the look."
  4. Unnecessarily complex: a duplicate of a system component, a modal in a modal, a step that collects what the system already has, a hero that eats the LCP budget (the FSD course), a bespoke table. The consequence is cost now and forever. "The system's Select with search covers this; a new component is a proposal (part 3) and three weeks."
  5. The form that gets heard: name the ground; show the consequence with a concrete case, a number or a reproduction; propose an alternative that keeps the design's intent rather than a different design; separate it explicitly from taste ("the colour is yours; the contrast is not"); in the review, before build, in writing with the checklist; and accept the answer when the ground turns out weaker.
  6. Not a ground: preference, unfamiliarity, effort alone ("hard to build" is an estimate for Product to weigh, not a veto), an unchecked feasibility claim (check the Browser course first), relitigating without new information. Standing comes from consequences; spending it on taste wastes it.
the exercise
Take the last design you pushed back on and name its ground. If you cannot name one of the four, it was taste, and the next one with a real ground will be heard less for it.
WHEN AND HOW TO PUSH BACK ON A DESIGN
four grounds that justify it, the form that gets heard, and the ones that do not
swipe the figure sideways, or tap expand for full screen
1/6
unsafe
Unsafe: the transfer confirmation has no review step and the amount is editable on the final screen; the KYC flow loses a half-done journey on reload; the withdrawal button is not idempotent in the design (a second tap is a second request). The consequence is money or identity lost. The form: "this flow can send a transfer twice if the user double-taps; here is how (the Trust course part 3); a review step with a single submit keeps the three-tap intent and prevents it."