Purpose: Standardise and scale component design decisions during prototyping by aligning with your design system.
Design Thinking Phase: Prototype
Time: 45–60 min session + 1–2 hours spec documentation or iteration follow-up
Difficulty: ⭐⭐
When to use: When you need to validate ideas using realistic, system-aligned componentsWhen prototyping flows with hand-off clarity in mindWhen assessing if net-new UI patterns are necessary vs. reusing
What it is
Design System / Component Use during prototyping is the deliberate application of system-compliant UI elements to build functional, testable flows. It involves choosing components already available in your design system, adapting as needed, and documenting spec-level variations early. This helps your prototypes move closer to implementation fidelity while avoiding design drift.
📺 Video by Figma. Embedded for educational reference.
Why it matters
Prototypes paired with component constraints do double-duty: they avoid undesigned debt and help you test what’s *buildable*. Whether you're validating usability, interaction flows, or system-specific edge cases, using real components forces discussions around responsiveness, accessibility, and dev-ready behaviors. Designers often wait too long to "bring in the system"—leading to duplicated effort or feature inconsistencies.
When to use
- Designing or testing high-impact user flows (checkout, onboarding, dashboards)
- Collaboratively preparing a flow for cross-functional review with engineering
- Refining component variants based on real task usage
Benefits
- Rich Insights: Helps uncover user needs that aren’t visible in metrics.
- Flexibility: Works across various project types and timelines.
- User Empathy: Deepens understanding of behaviours and motivations.
How to use it
- Audit the flow: Start with your prototype or journey map. Break it into interaction chunks (start points, transitions, decision moments).
- Inventory available components: Reference your design system’s component library (via Figma, Zeroheight, Storybook, etc.). Match each interaction with existing component(s) where possible.
- Identify gaps or exceptions: Note moments where existing components don’t suffice. This helps track deviations early.
- Prototype using system components: In Figma or your preferred tool, use tokens and master components. Avoid visual overrides unless spec'd.
- Document context + adaptations: For every non-standard component usage, document behavior, state logic, and intended interaction. Use annotations or a spec table with properties, states, and rules.
- Review collaboratively: Walk through with devs and Product peers. Prioritize building blocks that support reuse, accessibility, and responsive scalability.
- Update system inputs if warranted: If your prototype introduces patterns that will be repeated, feed it upward into your design system backlog.
Example Output
- Flow Name: Team Invitation Modal (Pro-tier workspace admins only)
- Component Used: Form Modal (adaptive, 640px width)
- Variant: Secondary CTA added to allow manual invite code copy
- Updates Required: Add optional “Copy only” CTA slot to modal footer
- Notes: Should follow existing modal spacing rules and placeholder text style (label above field only)
Common Pitfalls
- Designing outside the system first: Avoid prototyping freely and retrofitting later. It creates tech debt and conflicts with system governance.
- Overriding without rationale: Beware excessive overrides in Figma. Always trace changes to user intent—not visual preference.
- Leaving devs out of edge case decisions: Design variants that aren’t feasible slow down dev time. Prototype in tandem with implementation context.
Design-Ready AI Prompts for Design System / Component Use – UX/UI Edition
How These Prompts Work (C.S.I.R. Framework)
Each of the templates below follows the C.S.I.R. method — a proven structure for writing clear, effective prompts that get better results from ChatGPT, Claude, Copilot, or any other LLM.
C.S.I.R. stands for:
- Context: Who you are and the UX situation you're working in
- Specific Info: Key design inputs, tasks, or constraints the AI should consider
- Intent: What you want the AI to help you achieve
- Response Format: The structure or format you want the AI to return (e.g. checklist, table, journey map)
Each prompt is a copyable template. Just click the copy button in the top-left corner of the prompt block, paste it into your AI tool, and replace anything inside [square brackets] with your own project details.
Ai Prompt Template: “Audit a Flow Using My Design System Components:”
Audit a Flow Using My Design System Components:
Context: You are a [Senior Product Designer] preparing a [hi-fi prototype] for an internal tools platform.
Specific Info: The prototype involves [form inputs, top nav, pagination, user table] with existing component options in [Figma component library].
Intent: Map existing system components to each touchpoint in the flow, and flag any net-new patterns or undocumented edge cases.
Response Format: Return a table listing: Flow Step, Proposed Component, Variant (if used), and Spec Notes.
If component naming is unclear from the flow steps, list clarifying questions first.
Suggest a follow-up workshop or documentation step after the audit.
Ai Prompt Template: “Generate Interaction States for a New Component Proposal:”
Generate Interaction States for a New Component Proposal:
Context: You are a [UX Designer] introducing a new [multi-select dropdown with nested labels] pattern.
Specific Info: The intended use case supports [tag filtering in data-heavy dashboards]. It must be [keyboard navigable], [mobile responsive], and follow our existing token system.
Intent: Define all key states (default, focus, selected item, overflow, error, disabled, mobile touch) using system-aligned variables.
Response Format: Table with State, Visual Change, Behavior, and Accessibility Note.
Ask clarifying questions before assuming dropdown architecture.
Offer suggestions for including this in future system documentation.
Ai Prompt Template: “Analyze Prototype Friction Based on Component Mismatch:”
Analyze Prototype Friction Based on Component Mismatch:
Context: You are a [UX lead] evaluating why a [document upload feature] feels inconsistent in prototype testing.
Specific Info: The prototype currently uses [a custom-built drag & drop block], while the system offers a [file upload field with progress state].
Intent: Identify friction related to deviation from design system components, and propose more consistent, reusable alternatives.
Response Format: Return a 3-column critique listing: Current Element, User Problem Observed, Suggested System Component.
If multiple uploads or accessibility behaviors are in question, ask follow-up prompts.
Ai Prompt Template: “Suggest System-Compliant Variants for Edge Case Scenarios:”
Suggest System-Compliant Variants for Edge Case Scenarios:
Context: You are designing [status alerts] in a [multi-user workflow] dashboard for [incident reporting system].
Specific Info: Team leads need visual distinction between [draft, reviewed, and escalated] states across [light and dark mode].
Intent: Propose variants of our existing [status badge component] to clearly communicate these tiers without introducing new UI.
Response Format: List of three modified badge variants with tokens, color contrast ratios, and usage notes.
Consider accessibility and existing palette first. Ask any theming constraints if unclear.
Ai Prompt Template: “Create Spec Documentation for a Reused Component in Flow:”
Create Spec Documentation for a Reused Component in Flow:
Context: You are finalizing specs for a [mobile scheduling interface] that uses our [calendar date-picker component].
Specific Info: The calendar is shown in [read-only mode] except when [admin role is detected], where full editing becomes active.
Intent: Document component behavior rules by user role, state changes, and responsive constraints.
Response Format: Return a table including: Component Name, Role Condition, Behavior Variant, and Notes for Implementation.
If date formatting or time zone logic is ambiguous, list assumptions you may be making.
Ai Prompt Template: “Prioritize Component Enhancements Based on Prototyping Feedback:”
Prioritize Component Enhancements Based on Prototyping Feedback:
Context: You are a [Product Designer and Developer lead] reviewing prototype feedback on [carousel component for marketing site].
Specific Info: Users found [swipe gesture unclear on mobile, no option to pause autoplay].
Intent: Turn qualitative notes into actionable system enhancements for backlog grooming.
Response Format: Ranked list with Suggested Change, Component Impacted, User Problem, Dev Feasibility (Est.), and Notes.
Add prioritization if effort or impact info is available.
Ai Prompt Template: “Map Journey Steps to System Components for Build Readiness:”
Map Journey Steps to System Components for Build Readiness:
Context: You are preparing handoff documentation for a [customer checkout journey] prototype for a desktop web app.
Specific Info: The flow includes [cart summary, address form, payment entry, confirmation modal].
Intent: Break each journey step into implemented components already in the system or call out build dependencies.
Response Format: Journey Step > UI Block > Matching Component > Variant > Implementation Notes (if any)
Highlight areas lacking system parity vs. visual prototype.
Ai Prompt Template: “Identify Token Inconsistencies in a Figma Prototype:”
Identify Token Inconsistencies in a Figma Prototype:
Context: You are reviewing a prototype that uses your [design system’s color and spacing tokens] but may have inconsistencies.
Specific Info: File includes templates for [dashboard, user settings, notifications].
Intent: Scan the Figma canvas for overrides or deviations from the system tokens applied in layers, padding, text, or color.
Response Format: Return a table with Frame Name, Token Issue, Suggested Fix.
Ask which token naming system to reference.
Ai Prompt Template: “Draft Component-Level QA Questions for Testing Consistency:”
Draft Component-Level QA Questions for Testing Consistency:
Context: You are preparing QA for a release that includes [refactored form elements] implemented from the system.
Specific Info: Includes [input field, dropdown, checkbox], intended to match [WCAG AA colors] and follow [tab order logic].
Intent: Create a checklist of questions a QA analyst or designer should ask while validating visual and interactive consistency.
Response Format: A checklist broken down by component type.
Call out mobile and accessibility-specific checks separately.
Recommended Tools
- Figma: For component libraries, tokens, and interactive prototyping
- Storybook: For live, code-backed component documentation
- Zeroheight: Inclusive design and documentation handoffs
- Contrast.app: For quick a11y color checking
- Locofy.ai or Framer: For semi-dev-level rapid prototyping
