Working With Design
Tell the designer which part is expensive and why, in their terms, and offer the version that keeps the intent — before the mockup is signed off, not in week two of the build.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
When a design is expensive to build, how do you keep what it was for without building all of it?
The designer shares a checkout redesign: the order summary animates as items change, the address field autocompletes, and the delivery date updates live as the customer types their postcode. "The PM has signed it off — can you start on Monday?"
Build it as designed. Design owns the experience, and engineers who push back on every mockup are why products end up looking like admin panels. If something is hard, estimate it honestly and get on with it.
The live delivery date means calling the carrier's API on every keystroke. That API is slow and rate-limited, so built as drawn it either lags or fails at peak. The designer drew what they wanted the customer to know, not an API call — they had no way of seeing the cost.
- The live delivery date means calling the carrier's API on every keystroke. That API is slow and rate-limited, so built as drawn it either lags or fails at peak. The designer drew what they wanted the customer to know, not an API call — they had no way of seeing the cost.
- Discovered in week two, the problem becomes a negotiation under deadline, and the fallback is whatever is quickest to build. That version usually loses the point of the element.
- "This is hard" is not information a designer can use. They cannot trade "hard" against the rest of their design; they can trade "this one field is half the build".
- The next design is made with no more knowledge of the cost curve than this one, so the same conversation happens again next quarter.
What is really going on
- A design encodes an intent — what the customer should understand, feel or be able to do — in one particular form. The form is usually one of several that would serve the intent; the designer picked the best one they could see without knowing the costs.
- Frontend cost is rarely spread evenly. One element — live data from a third party, a custom control, an animation over content that changes, a layout that behaves differently at an awkward width — often carries most of the cost and most of the risk.
- Designers respond to why and to alternatives that keep the intent. "Can we drop it?" asks them to lose something. "The point is to reassure people it arrives by Friday — could we show the date once the postcode is complete?" keeps what they cared about.
- The happy path is what gets drawn. Loading, empty, error and long-content states are where most of the unplanned build time goes, and they are far cheaper to agree before the build than to invent during it.
- The cheapest time to talk is before sign-off. After the PM approves a mockup, every change is a renegotiation with two people instead of one.
A design is one form of an intent
Every element in a mockup is an answer to a question the designer asked about the customer. The live delivery date answers "will it arrive in time?". The animated summary answers "did my change register?". The answer they drew is one of several possible answers; they drew the best one they could see without knowing what each would cost.
Your job is not to accept or reject the drawing. It is to recover the question, price the drawn answer, and offer another answer to the same question when the price is steep.
Saying what is expensive, and why
The most common mistake is not saying it at all. The second most common is saying it in engineering terms: "rate limits", "debouncing", "re-renders". The designer cannot weigh those. They can weigh what the customer would see and how much of the build it eats.
The redesign is on screen. The PM has already said they like it. You have a minute before the review moves on.
"The live delivery date is going to be really hard, we would have to debounce the carrier calls and handle rate limiting. Can we cut it?"
"I love the delivery date — it answers the question people ask support most. One thing: to update it on every keystroke we have to ask the carrier each time, and they are slow, so the date would flicker and sometimes vanish at busy times. If it appears once the postcode is complete, people get the same answer at the same moment and it is a day's work instead of a week. Would that lose anything?"
Offer the version that keeps the intent
The alternative has to answer the same customer question, or it is a cut dressed as a compromise. Check it against the intent out loud before you propose it: if the customer still knows whether it arrives by Friday, before paying, it keeps the intent.
Drop the live delivery date and show "Delivery in 2–5 working days" under the button.
Show the exact date as soon as a complete postcode is entered, with a quiet "checking…" state while the carrier answers, and the 2–5 day range only if they do not answer.
The cut removes the thing the customer needed to decide whether to order. The alternative still answers "will it arrive by Friday?" at the moment they need it, and covers the carrier failing, which the original drawing did not.
Agree the states nobody drew
Mockups show the happy path with tidy data. The build spends most of its surprises elsewhere: the summary while prices are still loading, the date when the carrier times out, the cart with forty items and one out of stock. Agreeing these before the build is a fifteen-minute conversation; inventing them during the build is a week of small decisions the designer never sees.
| State | What to ask the designer | Why it matters here |
|---|---|---|
| Loading | What does the summary show before prices arrive? | Otherwise it jumps, and a jumping total at checkout reads as a price change. |
| Error | What does the date say if the carrier does not answer? | Otherwise the field is blank and people ask support. |
| Empty | What does checkout show if the cart emptied in another tab? | Otherwise the customer sees a total of zero and a pay button. |
| Long content | What happens with forty items or a very long product name? | Otherwise the animated summary pushes the pay button off screen on phones. |
How to do it
Most important first.
- Get into the review early. Look at wireframes, not only the final mocks, and ask of each expensive element: "What should the customer understand here?"
- Name the expensive part specifically and say why in terms of what the customer would experience: "Updating on every keystroke means asking the carrier each time; it is slow, so the date would flicker or lag."
- Offer the version that keeps the intent — ideally two, each with a rough cost — and ask what it loses.
- Separate three things out loud: "expensive", "not possible with what we have", and "I would have designed it differently". Only the first two are yours to raise as the engineer.
- Build the risky element first and show it to the designer with real data. Real addresses and real delivery times often change the design for the better (The First Version That Teaches You Something).
- Agree the other states before building: what the summary shows while prices load, what the date says when the carrier does not answer, what happens with forty items in the cart.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Start by playing the intent back: "The live date is there so people know before paying whether it arrives by Friday — have I got that right?"
- Then the cost, specifically and in the customer's terms: "To update it on every keystroke we would ask the carrier each time. They are slow and they limit us, so at busy times the date would lag or disappear."
- Then the alternative that keeps the intent: "If we show the date as soon as the postcode is complete, the customer gets the same answer at the same moment, and it is about a day of work instead of a week."
- Ask rather than decree: "Does that lose anything you were going for?" — and mean it; sometimes it does, and then the week is worth spending.
- Then tell the PM in one line: "Design and I agreed to show the delivery date once the postcode is complete. Same information for the customer, about a week less work, no carrier limit risk."
- "Every product that looks great had engineers who just built the design." Some did, and many had designers who knew which effects were cheap. I want this to look great too, so I am telling you where the budget goes.
- "Can you not just make it work?" I can make the live version work in about a week with a risk at peak, or the postcode-complete version in a day. It is your call which; I want you to have both.
- "We will simplify it later if it is slow." Later is after customers have seen it lag at checkout, which is the one page where lag costs orders.
What can go wrong
- Engineering veto dressed up as cost: "too expensive" for things that are merely unfamiliar or dull to build.
- Silent simplification: building the cheaper version without telling the designer, who finds out in QA and stops trusting the build.
- Winning the argument and losing the intent: the cheaper version ships and no longer does the job the element existed for.
- Treating the designer as the person who makes it look nice, kept out of product conversations, so their designs keep missing constraints nobody told them about.
- "Pushing back on design is being difficult." Pricing a design is information. Silence is the difficult choice; it is just discovered later.
- "The designer should already know what is expensive." The cost curve lives in your codebase and your vendors' limits. They learn it from you or not at all.
- "Keeping the intent means building it exactly as drawn." The intent is what the customer should get; the form is the part that is negotiable.
Knowing whether it worked
- The designer starts sharing wireframes with you before the final mocks, and asks "is anything here expensive?" unprompted.
- Designs arrive with loading, empty and error states already drawn.
- "That is not what I designed" disappears from QA.
- The element you shipped still does its job: support contacts asking "when will my order arrive?" go down after the delivery date appears in checkout.
- With a design system, most cost conversations become "is this already a component?", and the conversation narrows to the genuine exceptions.
- With several designers, a short shared list of what tends to be expensive here — live third-party data, custom inputs, animated lists — saves having the same talk with each of them.
- At high traffic, a design choice becomes a performance and cost choice too: a third-party call on every checkout page view is a bill and a failure mode, and the conversation moves towards budgets.
- Early involvement costs engineering hours in reviews of designs that may never be built.
- The cheaper version is sometimes genuinely worse. You are trading polish for time, and should say so rather than pretend it is equivalent.
- Designers can feel second-guessed, especially early in the relationship. The trust comes after a few rounds where your alternative kept what they cared about.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- TEAM-SPECIFICWith a dedicated product designer this is a regular partnership. With a mature design system most elements are pre-priced and the conversation is about exceptions. With no designer, the engineer is making these trade-offs alone and should write the intent down anyway.
- PRODUCT-SPECIFICIn a consumer store the polish of checkout is part of trust and conversion, so the expensive version is sometimes worth it. In an internal tool the cheap, clear version almost always wins, and arguing for polish is harder to justify.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.