Design Engineering
Scope
Covers
- Defining a Design Engineering function (hybrid design sensibility + ability to ship production code)
- Choosing an operating model: embedded vs platform/design-system vs tiger team
- Creating a prototype → production pipeline (what is throwaway vs shippable)
- Establishing a design-to-code contract (tokens, components, reviews, quality bar)
- Planning delivery for UI/UX-heavy work (components/flows, milestones, QA gates)
When to use
- “We want to create a design engineering function—write the charter and operating model.”
- “Our prototypes never make it to production—define a prototype→production workflow.”
- “We need faster UI iteration with high craft—set a design-to-code contract + quality bar.”
- “We’re building a new UI/component library—create a component delivery plan and reviews.”
When NOT to use
- You need UX research, discovery, or product strategy (use interviews/surveys/PRD skills)
- You’re doing mostly backend/platform architecture with minimal UI surface area
- You only need to ship a single small UI fix (just implement it)
- You need a brand/visual identity system (separate design/brand process)
Inputs
Minimum required
- Product/context: what you’re building and who it’s for
- Current state: design artifacts (Figma, mockups) + codebase/stack (web/native) + existing design system (if any)
- Goal: what “better” means (speed, consistency, craft, accessibility, quality, fewer handoff bugs)
- Constraints: team composition, timeline, quality bar, accessibility/compliance requirements
Missing-info strategy
- Ask up to 5 questions from references/INTAKE.md, then proceed with explicit assumptions.
- If the team/stack is unknown, assume a modern web stack (component library + CI) and call out assumptions.
- Do not request secrets/credentials; use redacted identifiers.
Outputs (deliverables)
Produce a Design Engineering Execution Pack in Markdown (in-chat by default; write to files if requested):
- Context snapshot (goals, constraints, success signals)
- Design Engineering charter (mission, scope, ownership boundaries, engagement model)
- Prototype → production workflow (prototype ladder + decision rules + review gates)
- Design-to-code contract (tokens/components/spec handoff, PR review expectations, QA)
- Component/flow delivery plan (prioritized backlog + milestones + owners)
- Quality bar (checklists + rubric score)
- Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
Workflow (7 steps)
1) Intake + success definition
- Inputs: User context; references/INTAKE.md.
- Actions: Confirm scope (product area), stakeholders, and what “design engineering” means here (role vs function vs project). Define success signals (e.g., faster UI iteration, fewer handoff bugs, higher consistency, improved accessibility).
- Outputs: Context snapshot (draft).
- Checks: The team can answer in one sentence: “What will change if we do this well?”
2) Choose the operating model (and boundaries)
- Inputs: Team org, roadmap pressures, existing design/engineering capabilities.
- Actions: Select an engagement model (embedded, platform/design system, tiger team). Define responsibilities and boundaries vs Design and Engineering (who owns interaction design, component implementation, accessibility, visual QA, performance).
- Outputs: Design Engineering charter (draft) with explicit boundaries.
- Checks: No “two owners” ambiguity for components, tokens, and UI quality sign-off.
3) Map the UI surface area + constraints
- Inputs: Key flows/screens; existing components; constraints (devices, browsers, perf, a11y, localization).
- Actions: Inventory the highest-leverage UI areas (top flows, shared components). Identify reuse opportunities and risk hotspots (complex interactions, animations, data density, edge cases).
- Outputs: UI surface map + initial component/flow backlog.
- Checks: Backlog is prioritized by user impact and reuse (not just what’s loudest).
4) Define the prototype ladder (prototype → production)
- Inputs: Timeline, iteration speed needs, risk tolerance.
- Actions: Define a “prototype ladder” (lo-fi → hi-fi → coded prototype → production). For each rung, set purpose, expected fidelity, and whether it is disposable. Add decision rules for when to “graduate” a prototype.
- Outputs: Prototype → production workflow (ladder + rules + gates).
- Checks: Every prototype has an explicit label: throwaway vs shippable.
5) Write the design-to-code contract (handoff + reviews)
- Inputs: Design artifacts; code conventions; QA expectations.
- Actions: Define the contract: design tokens, component API expectations, states, a11y requirements, and review gates (design review, engineering review, QA). Specify what must be in a PR (screenshots, storybook links, test plan, a11y notes).
- Outputs: Design-to-code contract (v1).
- Checks: A developer can implement a component without back-and-forth on states, spacing/typography, and acceptance criteria.
6) Plan delivery (milestones + ownership)
- Inputs: Backlog + constraints + team capacity.
- Actions: Convert backlog into milestones (thin slices) with owners, dependencies, and acceptance criteria. Define how work is tracked (board columns) and how design engineering work is staffed.
- Outputs: Component/flow delivery plan (milestones).
- Checks: First milestone is small enough to ship within 1–2 weeks and sets patterns for the rest.
7) Quality gate + alignment + finalization
- Inputs: Draft pack.
- Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add stakeholder cadence and a lightweight decision log (what was chosen, why). Finalize Risks / Open questions / Next steps.
- Outputs: Final Design Engineering Execution Pack.
- Checks: Quality bar is explicit; ownership is unambiguous; risks and open questions are not hidden.
Quality gate (required)
- Use references/CHECKLISTS.md and references/RUBRIC.md.
- Always include: Risks, Open questions, Next steps.
Examples
Example 1 (stand up the function): “Use design-engineering. We’re a 12-person product team. Web app. Designers ship Figma but engineering struggles with UI polish. Create a Design Engineering Execution Pack with an embedded model and a prototype→production workflow.”
Example 2 (design system delivery): “Create a design engineering plan for building a component library (buttons, inputs, tables, modals). Include the design-to-code contract, PR review checklist, and a 6-week milestone plan.”
Boundary example: “What is design engineering?” Response: explain this skill produces an execution pack; ask for context (team, product, goals). If they only want a definition, give a brief definition and point them to the intake questions to proceed.