Feeding UI/UX Specs and Mockups into Bolt

Bolt Can Build From Visual Specifications

One of Bolt's most powerful capabilities is translating visual design specifications into working code. When used correctly, a designer's wireframe or annotated mockup becomes the input for a fully functional UI component — with the right structure, states, and behavior.

This workflow requires knowing how to translate visual information into Bolt-readable instructions. The design file describes what it looks like; your prompt describes how it behaves.

Uploading Images to Bolt

Bolt accepts image uploads in the chat interface. You can upload:

• Wireframes and low-fidelity mockups
• Annotated design screenshots
• Reference UI from other applications
• Exported Figma frames or component designs

When you upload an image, pair it with a structured prompt:

[Attached: wireframe of the project dashboard]

Build the dashboard layout shown in this wireframe.

Implementation notes:
- The left sidebar is fixed, 240px wide, slate-800 background
- Each project card shows: title, task count, completion percentage, last updated date
- The "New Project" button opens a modal (build the modal too)
- The card grid is 3 columns on desktop, 2 on tablet, 1 on mobile
- Use the project's color (stored in the DB) as a 4px left border accent on each card

Tech stack: React + TypeScript + Tailwind + Supabase (existing project)
Follow the patterns in .kiro/steering/tech.md

Translating Design Specs into Bolt Prompts

A well-structured design spec (like those covered in the Claude for Documentation tutorial) maps directly to Bolt prompt components.

From the design spec:

Screen: Task Detail Panel
States: Loading, Populated, Error, Empty
Components: Task title (editable inline), due date picker, priority selector,
            assignee dropdown, description textarea, complete/delete actions
Responsive: Full-width panel on mobile, right-side drawer on desktop ≥1024px

Into a Bolt prompt:

Build a TaskDetailPanel component.

STATES:
- Loading: show a skeleton loader with 4 rows
- Error: show an error message with a retry button
- Empty: show "Select a task to view details" centered
- Populated: show the full task detail UI

POPULATED STATE UI:
- Task title: h2, editable inline on click (blur saves)
- Due date: date input, save on change
- Priority: 3-button toggle (Low / Medium / High), blue highlight on selected
- Description: textarea, auto-resize, save on blur
- Actions row: "Mark Complete" primary button, "Delete" ghost button with red text

RESPONSIVE:
- Mobile (<1024px): full-width panel, slides up from bottom, backdrop overlay
- Desktop (≥1024px): fixed right sidebar, 380px wide, no overlay

Follow .kiro/steering/tech.md for all patterns.

The Component State Matrix

Before prompting Bolt to build any UI component, build a state matrix — every combination of conditions the component might be in. This prevents Bolt from building only the happy path.

Build the NotificationBell component.

STATE MATRIX:
| Condition | Display |
|-----------|---------|
| 0 unread notifications | Bell icon, no badge |
| 1-9 unread | Bell icon + red badge with count |
| 10+ unread | Bell icon + red badge with "9+" |
| Loading notifications | Bell icon, pulse animation on badge |
| Error loading | Bell icon, no badge, tooltip on hover: "Couldn't load notifications" |
| Dropdown open | Bell icon highlighted, notification list below |
| Dropdown empty | "No notifications" centered in dropdown |

Reference UI Patterns

When you want Bolt to match a specific existing UI pattern, describe it by example rather than by abstract description:

Build a status badge component that works like GitHub's issue status badges:
- "Open" → green background, white text, rounded-full
- "Closed" → purple background, white text, rounded-full
- "Draft" → gray background, white text, rounded-full
- Small variant (text-xs, px-2 py-0.5) for use in tables
- Default variant (text-sm, px-3 py-1) for use in detail views

Referencing a known UI pattern gives Bolt a concrete target and produces more consistent results than describing abstract visual goals.

What to Leave to Your Designer

Even with image uploads and detailed specs, Bolt produces component structure and behavior — not brand-quality visual design. For polished results:

• Let Bolt build structure, states, and interaction logic
• Have your designer provide the design token values (exact colors, spacing, typography) in your tech.md steering file
• Review Bolt output for structural accuracy, then refine spacing and visual details manually or via targeted prompts

The goal is not to replace the designer's work but to eliminate the gap between the design and the first working implementation.

Key Takeaways

• Upload wireframes and mockups as images with a structured behavioral prompt alongside them
• The state matrix ensures Bolt builds all edge cases, not just the happy path
• Design specs translate directly to Bolt prompts with practice — structure, states, responsive rules, and actions map one-to-one
• Bolt builds the structure and behavior; designers own the final visual refinement

---

Try It Yourself: Find a screenshot of any web UI you admire (a dashboard, a settings page, a card component). Upload it to Bolt with this prompt: "Build a React component that matches this UI layout. Use Tailwind CSS. Include loading and empty states. Use semantic HTML." Review the output — how closely does it match? What required correction?