What this prompt does
This prompt converts a low-fidelity wireframe into a high-fidelity UI mockup specification. You describe the [page_type], name [product_name], give the [wireframe_description], and choose the [design_system] and [brand_colors]. ChatGPT then maps each wireframe box to a real component, applies typography and color roles, adds visual richness, designs interactive states, defines responsive behavior, and describes micro-interactions.
The variables drive fidelity. [grid_system] and [spacing_scale] establish layout structure, [font_stack] and [contrast_ratio] govern typography and accessibility, and [image_style] replaces placeholder boxes with described imagery. [border_radius] and [shadow_system] set the depth treatment, [breakpoints] define the responsive adaptations, and [transition_style] shapes the motion. Because the prompt asks for default, hover, active, focus, disabled, and loading states on every interactive element, the resulting spec translates closely into the components an engineer would build — which is the point of doing this step before writing code.
When to use it
- You have a low-fi wireframe and want to push it to high fidelity before building.
- You want each wireframe box mapped to a specific UI component with spacing and typography.
- You need color roles, contrast checks, and interactive states defined for every element.
- You want responsive adaptations described at named breakpoints.
- You are about to build a UI and want a spec that translates almost directly into components.
- You need micro-interaction and transition direction alongside the static design.
Example output
The output is a high-fidelity design specification. It maps each box in your [wireframe_description] to a component on a [grid_system] grid with the [spacing_scale], applies a type scale from [font_stack], assigns color roles from [brand_colors] and checks them against [contrast_ratio], describes [image_style] imagery with [border_radius] and [shadow_system] depth, defines six interactive states per clickable element, lays out responsive reflow at your [breakpoints], and adds [transition_style] micro-interactions. It reads as a build-ready brief rather than a rendered screen.
Pro tips
- Describe
[wireframe_description]in component terms (nav bar, stat cards, data table) so the mapping is precise. - Match
[design_system]to what you'll actually build in (shadcn/ui, Material) so the spec aligns with your component library. - Provide
[brand_colors]as hex values so the color-role mapping and contrast checks are concrete. - Keep
[spacing_scale]consistent with your codebase's spacing tokens so the mockup translates without conversion. - The contrast checks describe WCAG compliance, but verify the final rendered colors with a real contrast tool before shipping.
- This produces a spec, not a rendered mockup, so feed it to a design tool or use it directly as a component build guide.
- Set
[transition_style]and the micro-interaction direction to match your front-end capabilities, since a 200ms ease-out is trivial to build while elaborate scroll-triggered reveals add real engineering cost. - Align
[border_radius]and[shadow_system]with your existing design tokens so the high-fidelity mockup doesn't drift from components you have already shipped.
