AI Design Brief Starter Kit

Start with one real screen.

1. Complete the brief using verified project information. Mark what you do not know.
2. Use Prompt 1 to tighten the brief, then answer the important missing questions.
3. Use the relevant prompts to prepare a screen, explore directions and review the result.
4. Apply your design judgment, test with people, and move editable work into Figma.

Remove sensitive, confidential and identifiable information before sharing context with any AI provider. Use tools approved for your work. The kit supports your process; it does not validate a design or guarantee results.

01 / Your design brief

Keep it focused. If a field is unknown, write the question and who can answer it.

Name the project, decision owner and stage.

What is happening, for whom, and why does it matter?

Describe the person, context and relevant access needs.

What one thing must they be able to accomplish?

What outcome should this support? Avoid an invented metric.

List verified observations, sources and dates. Label assumptions.

Name the screen or flow, required features, and what is out of scope.

Supply actual labels and realistic sample data. Include loading, empty, error and success states where relevant.

Brand, components, platform, responsive sizes, privacy and accessibility requirements.

Define the behavior to observe, who will test it, and the decision needed next.

02 / Six reusable prompts

Replace every bracketed placeholder. Start a fresh context when the project changes. Use approved, non-sensitive material.

Act as a UX partner. Turn the project notes below into a concise design brief.
NOTES: [paste non-sensitive notes]
Include: problem, primary user, user goal, business goal, evidence, assumptions, constraints, scope, exclusions and success measures. Label unknowns as questions. Do not invent research, requirements or metrics. End with the three questions that most affect the design.

PROJECT: [brief]
USER EVIDENCE: [verified observations, or "none yet"]
Describe the primary user, situation, task, obstacle and desired outcome. Separate evidence from hypotheses. Suggest three research questions to test the riskiest assumptions. Do not generate fictional interview quotes or personas presented as facts.

Create a UX Pilot prompt from this approved brief: [brief].
TARGET SCREEN: [screen and platform]
PRIMARY USER TASK: [one task]
REAL CONTENT: [headings, labels and sample data]
REQUIRED ELEMENTS: [elements and states]
CONSTRAINTS: [brand, accessibility, screen size, scope]
Return one self-contained prompt specifying hierarchy, layout, primary action, navigation and relevant loading, empty, error and success states. Flag missing decisions first. Avoid inventing features or claims. Keep the result editable in Figma.

APPROVED BRIEF: [brief]
SCREEN: [screen]
Compare three distinct layout directions serving the same user task. For each, explain hierarchy, primary interaction, tradeoff and what evidence would support choosing it. Keep requirements, content and brand constraints fixed. Recommend what to test; do not claim one option is validated without user evidence.

APPROVED BRIEF: [brief]
AI OUTPUT: [describe the screen or attach an approved screenshot]
Review alignment with the user task, hierarchy, real content, scope, interaction states and accessibility risks. Return a table: Issue | Evidence in output | Impact | Recommended fix | Verify with people or tools. Distinguish observable issues from assumptions. Do not claim WCAG conformance from a screenshot alone. Prioritize three fixes before cosmetic changes.

APPROVED DIRECTION: [direction]
SCREENS AND STATES: [list]
DESIGN SYSTEM: [components and tokens]
Create a Figma cleanup and handoff checklist covering editable layers, auto layout, reusable components, consistent tokens, responsive behavior, real content, interactions, states and accessibility checks. Separate manual edits from further AI exploration. List unresolved decisions and who should verify them. Do not invent implementation details.

03 / Review before you polish

• The primary user and task are explicit.
• Requirements are separated from ideas and assumptions.
• No invented research, quotes, numbers or product claims.
• The primary action and hierarchy support the task.
• Realistic content, long labels and empty states are considered.
• Navigation, loading, errors and success states are accounted for.
• Keyboard access, focus order, labels and contrast have been checked with suitable tools.
• Responsive behavior has been reviewed at relevant screen sizes.
• Editable components and spacing are consistent with the design system.
• Unresolved questions are assigned to a person or test; AI output is not treated as validation.

Make one decision

Keep, revise or discard the output. Record why. If the main task is unclear, return to the brief before spending more time on visual polish.

04 / A worked example

FICTIONAL EXAMPLE — hypotheses for practice, not user research.
Project: Bloom / plant-care reminder screen.
Problem hypothesis: People who own several plants may struggle to see which plants need attention today.
Primary user: A home plant owner checking their phone before work. This needs validation.
Task: See what needs care today and record one completed action.
Business goal: Help people consistently complete relevant care tasks. Baseline and target are not yet established.
Evidence: None supplied. Interview plant owners and observe how they track care before treating the hypothesis as fact.
Scope: One mobile Today screen, a plant list, care task, due status and "Mark watered" action. A lightweight confirmation lets the person undo a mistake.
Out of scope: Plant diagnosis, a shop, payment, social features and guaranteed watering recommendations.
Content: "Today", "Monstera", "Check soil before watering", "Mark watered", "Undo". Use care instructions verified for the real product; these examples are not horticultural advice.
States: No tasks today; task loading; save failed with retry; action saved with undo.
Constraints: Existing brand tokens and components. Do not rely on color alone for status. Support readable text, accessible labels and keyboard operation.
Review: Test whether participants can find and record a care task; observe confusion, errors and recovery. Decide whether to refine the hierarchy before extending the flow.
Next questions: How do people decide that a plant needs water? What information do they trust? What should happen after an accidental tap?

Example direction for a screen prompt

Use the approved Bloom brief above to create one mobile Today screen. Make today's care task the primary focus. Use the supplied labels, show task status in text, and include an undo action. Produce the main screen and describe its empty, loading and error states. Keep the existing brand system; do not add shopping or diagnosis features. Treat the problem as a hypothesis until user research supports it.

Keep building your practice.

Explore courses on prompting, preparing inputs, UX Pilot, Figma and presenting your work.

Created by Outvision, operated by 36seas LLC. You may adapt this kit for your own and client project work. AI tools and their subscriptions are provided separately. Privacy · Outvision