Idea To UI Design Brief

Idea to UI Design Brief

Overview

Use this skill as an optional Full-mode stage inside the idea workflow. It converts a product/design direction into a practical UI design brief that can guide image-generation concepts, HTML prototypes, or later Superpowers implementation work.

This skill should not run in Lite mode unless the user explicitly asks for UI design. Lite mode should keep the previous simple idea-capture behavior.

The UI brief is a bridge between product thinking and implementation. It should define what the interface should look, feel, and behave like without forcing premature code architecture.

When to Use

Use when the user asks to:

• explore possible UI designs for an idea;
• add a dedicated UI/design stage to the idea workflow;
• generate image prompts for app screenshots, dashboards, landing pages, or product surfaces;
• create a UI brief before giving the idea to a coding agent;
• critique or redesign an already-built app after screenshots exist;
• turn a design doc into screen-by-screen UI requirements.

Do not use when:

• the user only wants a quick Lite idea note;
• the idea is not yet clear enough to identify target users and core behavior;
• the user wants production frontend code immediately — use implementation skills after the UI direction is chosen;
• the user wants a formal token spec only — use design-md if available.

Artifact Placement

For Full mode idea packages, add this artifact after the design doc and before implementation planning:

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

Fallback rule: if the user skips this stage, preserve the old workflow numbering and behavior, or mark UI decisions as assumptions in the implementation spec. Do not block the workflow merely because no UI brief exists.

Required Inputs

Before writing the UI brief, collect or infer:

• product purpose and target user;
• core user flow;
• main screens or surfaces;
• platform target: web, desktop, mobile web, native mobile, or multi-surface;
• desired feel: calm, command-center, playful, professional, dense, minimal, etc.;
• visual constraints: brand, existing repo/design system, accessibility needs, dark/light mode;
• important states: empty, loading, error, success, first-run, repeat-use.

If these are missing and the user has not forced progression, ask one concise question at a time.

UI Brief Structure

Create 02-ui-design-brief.md with:

# <Idea Title> — UI Design Brief

## Purpose

## Product Feel

## Design Principles

## Primary Surfaces / Screens

## Screen-by-Screen Notes

## Layout / Information Architecture

## Component Inventory

## Key User Flows

## States to Design

## Visual Direction

## Accessibility and Responsiveness

## Content / Copy Notes

## Optional Image-Generation Concepts

## Selected Direction

## Open Questions

## Handoff Notes for Implementation

Optional Image-Generation Pass

Image generation is optional and should be treated as concept exploration, not the implementation source of truth.

Use image generation when:

• the user wants possible visual directions;
• taste is ambiguous;
• an app/dashboard/landing page needs visual exploration before code;
• the workflow benefits from comparing 2-3 directions.

Default to three concept prompts:

1. Conservative — familiar, low-risk, easy to implement.
2. Strong-fit — best interpretation of the product brief.
3. Divergent — more distinctive, useful for discovering taste boundaries.

Each prompt should specify:

• product category and target user;
• screen type and platform;
• information hierarchy;
• density and interaction posture;
• visual style and theme;
• what should not appear;
• that the result is a UI concept screenshot, not marketing art.

Image Prompt Template

Create a high-fidelity UI concept screenshot for <product>. Platform: <desktop web/mobile/etc>. Screen: <main dashboard/onboarding/settings/etc>. Target user: <user>. Product feel: <feel>. Layout: <key layout>. Must show: <components/data/actions>. Avoid: generic SaaS filler, fake irrelevant metrics, stock photos, excessive gradients, unreadable tiny text. Style: <visual direction>. The image should be a realistic product UI mockup suitable for turning into a design brief.

After Images Are Generated

If image artifacts are generated:

1. Save or reference each image path/URL in the UI brief.
2. Use vision analysis or manual review to extract what works and what does not.
3. Update Selected Direction with the chosen layout, components, and visual rules.
4. Do not ask the build agent to copy the image blindly. Convert the image into text requirements, components, tokens, and acceptance criteria.