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).
• You want to build or evolve a design system (tokens, components, governance) without standing up a new practice (use design-systems).
• You want to improve engineering team culture, rituals, or hiring practices (use engineering-culture).
• You need to run a one-off design review or design critique session (use running-design-reviews).
• You need a feature spec or detailed UX flow document (use writing-specs-designs).

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):

1. Context snapshot (goals, constraints, success signals)
2. Design Engineering charter (mission, scope, ownership boundaries, engagement model)
3. Prototype → production workflow (prototype ladder + decision rules + review gates)
4. Design-to-code contract (tokens/components/spec handoff, PR review expectations, QA)
5. Component/flow delivery plan (prioritized backlog + milestones + owners)
6. Quality bar (checklists + rubric score)
7. 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 1: “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.

Boundary example 2: “We need to build a component library with tokens, theming, and a governance model for adoption across teams.” Response: this is a design system buildout, not standing up a design engineering practice; redirect to design-systems. Use design-engineering when the goal is defining the hybrid role/function that ships UI, not the system of reusable components itself.

Anti-patterns

Avoid these common failure modes when producing a Design Engineering Execution Pack:

1. Charter without boundaries — Defining a design engineering function that overlaps with existing design and engineering roles without explicitly stating who owns what. If the charter does not answer “who decides on component API shape?” and “who signs off on visual fidelity?”, it will create turf wars.
2. Prototype graveyard — Building prototypes that are never graduated or killed. Every prototype must have an explicit label (throwaway vs shippable) and a time-boxed decision point for graduation or disposal.
3. Design-to-code contract as a checklist dump — Writing a long list of “must haves” without specifying how they are verified. A contract that says “a11y compliant” without naming the WCAG level, test method, and reviewer is unenforceable.
4. Delivery plan without thin slices — Planning milestones around “build all buttons, then all inputs, then all modals” instead of shipping a thin vertical slice (one flow end-to-end) that proves the workflow.
5. Ignoring the operating model decision — Jumping straight to delivery without deciding whether design engineering is embedded, centralized, or a tiger team. The operating model determines staffing, rituals, and escalation paths.