Design engineering in practice
Use code to explore an idea, test the experience, and improve the product.
Why this matters
You follow a product decision into the running product. That includes what a screen says, how it behaves, where its data comes from, and what happens when an operation fails.
You do not have to be the specialist for every layer. You do need to notice when the interface depends on something you have not designed or checked yet.
What to understand
Judge the whole interaction, not the screen. A green toast after a request is accepted cannot prove the downstream result arrived — the product may need "Invitation created" followed by delivery status. Understanding the system changes the copy.
When you are unsure, pick the material that exposes the current uncertainty: a sketch, a component, a browser inspection, a data sketch. You can discover hierarchy while coding and discover a server requirement while writing an error message.
Watch for
- Reviewing only the happy path and calling the toast the proof.
- Vague briefs like "Make it beautiful" that force the agent to invent the quality bar.
- Documenting every minor tweak instead of decisions that affect future work.
- Treating one team's setup as the required background or toolkit.
Strong default
Give your agent intent, relevant files, constraints, and a way to verify. Let it handle routine implementation. Ask for failure and recovery states, not just the main path. Keep a short record of why a pattern exists, where its source lives, and what would justify changing it.
When this doesn't apply
Vercel's account of design engineering describes code as a medium for exploration, and the Design Engineer Principles connect usefulness, constraints, inclusive interaction, and ownership. Its team works in several arrangements, including independent ownership — none of that is a prescribed workflow. Growth here is responsibility growing — from building a specified state, to noticing missing states, to improving the system that prevents omissions — not a title ladder.
In practice
Take an "Invite teammate" button in the crew scheduler. You design the hierarchy and copy. The form handles entry, validation, and feedback. The server checks who you are and what you are allowed to do (authentication and authorization) and saves the invitation — saved data that survives reload (persistence). Work that finishes after the reply (a background job) sends the email. The interface must reveal a delivery failure.
Ask your agent: "Show me the failure and recovery states for this action, not just the happy path."
Ask your agent: "Keep the project model and routes. Improve scanning with realistic long names. Check the empty list, denied access, and failed refresh. Show the result at narrow and wide widths."
| Lens | Question | Evidence |
|---|---|---|
| Usefulness | Does this help the intended person finish the task? | Replay with realistic content and constraints. |
| Experience | Can they understand and use it across inputs and sizes? | Rendered review, keyboard checks, and user feedback. |
| Reliability | Does the promised result survive real data and failure? | Exchange tests, saved-data checks, recovery, and monitoring. |
Verify
Replay with realistic content and constraints. Rendered review plus keyboard checks. Saved-data checks, recovery paths, and monitoring — not just the acceptance toast.
Related skills
Start with full-stack understanding for hidden dependencies and interface craft for visible quality. Use agent collaboration to make both part of the working loop.
Last updated on