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.