Working with designers

Designers are not "pixel people" you implement after the fact. Treat them as partners on edge cases you will otherwise discover in QA. Give feedback early on wireframes, not only on final Figma. "This flow needs four round-trips; we can do it in two if we combine these steps" is high-value eng input. Bring a sequence diagram when the interaction implies a chatty API.

What to ask for

• Empty, loading, error, permission-denied states — ask for them explicitly if they are missing from the mock
• Performance budgets — a gorgeous animation that blocks input for 800 ms on mid phones is a bug; say so with a number
• Accessibility — keyboard paths, contrast, screen-reader labels; cheaper in design than in rewrite
• System constraints — "we only have these three permission states today"; the designer can simplify the UX instead of inventing a fourth state eng cannot back

Walking through a constraint

The mock invents a fourth permission state. You only have admin, editor, and viewer today. Say that on the wireframe: "We can back three states. A fourth is a new model plus audit. Can we express this as editor-plus-a-flag, or is the fourth state the product bet?" Either answer is fine. Silence until QA is not.

The 800 ms animation is the same move with a number. "This blocks input for 800 ms on a mid phone. That is a bug for us. Can we keep the motion under a budget, or drop it on low-end?" Taste yields faster than irreversible risk. Performance is closer to risk.

Common mistakes

• Feedback only after visual design is final. Wireframes are cheaper.
• Silent one-off styles that fight the design system.
• Skipping empty, error, and denied states until QA.
• Inventing a fourth state in the API to match a mock nobody constrained.

Check yourself

1. The mock is missing a permission-denied state. When do you ask? On the wireframe. QA is too late and a rewrite is expensive.

2. When do you match the mock instead of the design system? When the mock is deliberately establishing a new pattern. Otherwise prefer the system.

Key takeaways

• Ask for empty, loading, error, and denied states on the wireframe.
• Say performance and permission constraints with numbers.
• Prefer the design system unless a new pattern is the bet.
• Sequence diagrams beat a chatty API discovered in QA.

Further learning

Next, make it a habit in product-minded habits.