Stakeholder Communication

Present design decisions, give and receive critique, and translate between designers, developers, and clients — the soft skills that make design engineering work.

Design engineers sit at the intersection of design, engineering, and product. The technical output — components, tokens, layouts — is only half the job. The other half is communicating why decisions were made, helping stakeholders understand trade-offs, and keeping the team aligned when design intent and technical reality diverge.

This page covers the communication patterns that prevent rework, misalignment, and the quiet frustration that accumulates when designers and developers talk past each other.

Presenting design decisions

When you present design work to a client, stakeholder, or engineering team, do not ask "what do you think?" That question invites subjective opinion when you need directed feedback on specific decisions.

Frame the conversation around trade-offs

Every design decision is a trade-off between competing priorities. Make those trade-offs explicit:

Decision	Why we chose this	The alternative we considered
Sidebar stays persistent at 256px	Users switch between projects frequently; collapsing the sidebar on every navigation adds friction	Collapsible to 64px auto-hides on navigation
Dashboard uses server-fetched data	Data changes hourly; real-time adds WebSocket complexity with minimal user benefit	Real-time updates via WebSocket
Auth card is 384px max	Matches password manager autofill width; wider cards look sparse with only two fields	448px card for visual consistency with marketing pages

Structure every presentation

State the goal — what problem is this design solving? (one sentence)
Show the decision — present the interface or system change
Explain the trade-offs — what you gained, what you gave up, and why the trade is worth it
Identify what feedback you need — be specific: "I want feedback on the information hierarchy of this dashboard, not the colour palette"
State next steps — what happens after this meeting

Presenting to different audiences

Audience	What they care about	How to frame it
Clients / stakeholders	Business outcomes, timeline, cost	"This layout increases conversion by making the primary CTA impossible to miss. It ships in the next sprint."
Product designers	Visual consistency, interaction model, design intent	"The card component uses the same spacing tokens as the sidebar, and the hover state matches Button."
Engineers	Feasibility, data dependencies, edge cases	"This dashboard needs data from three endpoints. Each panel handles its own loading and error states independently."
AI agents	Constraints, tokens, states, component names	"Use `DashboardLayout` from the design system. Every panel must show loading, empty, and error states. Colours from globals.css only."

Design critique

Critique is not feedback. Feedback says "I like it" or "I don't like it." Critique identifies a specific problem and explores solutions without prescribing one.

Giving critique

Follow this structure: observe → diagnose → explore

Observe: "The primary CTA on the landing page is the same visual weight
as the secondary links in the nav."

Diagnose: "A new user scanning the page does not know where to click first.
The hierarchy is flat — everything competes."

Explore: "Could we increase the CTA contrast, add motion that draws the eye,
or remove one of the competing elements? What trade-offs do we accept?"

Receiving critique

Listen without defending. Every piece of critique is data about how your design is perceived. Your job is to decide whether the perception reveals a real problem.

Do	Don't
Ask clarifying questions: "When you say the hierarchy feels flat, which element did you notice first?"	Explain why the design is actually correct
Separate the problem from the proposed solution	Accept every suggestion as a requirement
Note all feedback, address what matters, document why you deferred the rest	Defer everything or address everything — both are lazy

The best response to critique is: "That is interesting — let me think about whether that reveals a real problem." This buys you time to separate emotional reaction from genuine design insight.

Translating between disciplines

The design engineer's most valuable skill is translating between the languages of design and engineering. A designer says "this feels cramped." An engineer hears a vague complaint. You hear "the content area needs 24px more horizontal padding on the right."

Designer → Engineer translation

Designer says	Engineer needs to know
"This feels off"	Which specific element? At what viewport width? Compared to what reference?
"Can we make this pop more?"	Increase contrast? Add motion? Change scale? Add a border?
"The spacing is inconsistent"	Which two elements are the reference? What is the expected token value?
"This should be more playful"	Rounded corners? Warmer colour? Animation on hover? Custom illustration?
"It needs more breathing room"	Increase padding from 16px to 24px? Increase section margin? Reduce content density?

Engineer → Designer translation

Engineer says	Designer needs to know
"This is not feasible"	Not feasible in the timeline? Not feasible with the current stack? Not feasible at all? What is the nearest viable alternative?
"We need to simplify this"	Which interaction is driving complexity? Can we achieve the same outcome with a simpler pattern?
"This will hurt performance"	By how much? Is the performance cost acceptable for the UX gain? Can we lazy-load or defer?
"The API does not support this"	Can the API be extended? Is there a client-side workaround? Can we restructure the data model?

When design and engineering conflict

Step through this escalation path before escalating to leadership:

Restate the goal — what user outcome are we trying to achieve?
List what is possible — forget the ideal design for a moment. What can we actually build?
Find the 80% solution — what delivers most of the user value with the constraints we have?
Document the gap — what is missing from the 80% solution? This becomes the backlog item for the next iteration.
Agree on next step — ship the 80% now, iterate later. Do not let "perfect" block "shipped."

Written communication

Most design engineering communication happens asynchronously — in PR descriptions, Slack threads, and design specs. Write for skimming.

PR description template

## What this changes

[Screenshot or screen recording of the before/after]

## Design decisions

- [Decision 1]: [one-line rationale]
- [Decision 2]: [one-line rationale]

## States handled

- [x] Loading
- [x] Empty
- [x] Error
- [x] Desktop (1440px)
- [x] Tablet (768px)
- [x] Mobile (375px)

## Design tokens used

[Link to tokens or list the new/changed tokens]

## Reviewers

@designer-name — visual review
@engineer-name — code review

Status update template

When a stakeholder asks "how is the dashboard redesign going," they do not want a list of completed tickets. They want:

What is visibly different since last update (screenshot or link)
What decision is pending that needs their input
What the next visible milestone is and when they will see it

Since last week:
- Dashboard layout is implemented with live data (link to preview)
- Sidebar navigation matches the new IA

Need input on:
- Should the project list default to "grid" or "table" view?
  (See both options here: [link])

Next milestone:
- Charts and data visualisation — ready for review Friday

Product Designer First — Product thinking before interface work
Designing for Handoff — Figma-to-code conventions
Collaborative Repository Workflow — Git workflow for multi-contributor teams
Agent Collaboration — Working with AI agents effectively

On this page