---
name: ui-domain-interview
description: "Use when creating a user interface, UI, UX, screen, flow, dashboard, form, navigation, interaction, wireframe, mockup, or prototype."
version: 1.1.0
author: Markus Rink
license: MIT
---

# UI Domain Interview

When this skill is loaded, start an interview-style discovery for the UI question. Do not jump straight to screens, components, CSS, or visual style. Guide the user from the real domain and user tasks to a small set of intermediate UX artifacts, then hand off to the existing design or implementation workflow.

Do not discuss or re-ask about the technical stack, repository organization, tickets, branches, or team structure. Those belong to the surrounding workflow.

## Workspace

Create work artifacts, use:

```text
.scratch/ui-design/
├── domain-brief.md
├── use-cases.md
├── task-analysis.md
├── flow-specification.md
└── prototype-brief.md
```

Use the project's existing equivalent if it already has one. Do not create this structure merely for its own sake; create only the artifacts needed for the current UI question.

## The journey

```text
UI question
  → interview
  → domain brief
  → use-case inventory and priority
  → task analysis
  → flow and state specification
  → prototype brief
  → existing UI/design/implementation workflow
```

At each stage, summarize what is currently understood and ask the next small set of questions. Usually ask 3–5 focused questions at a time. Prefer concrete recent examples over abstract design preferences. Do not turn this into a large questionnaire.

### 1. Interview

Begin with the smallest useful questions:

- Who is the concrete person or role using this?
- In what situation and after which trigger do they use it?
- What are they trying to accomplish, beyond the requested feature or screen?
- How do they do it today, including tools and workarounds?
- How often does it happen, and what happens if it goes wrong?

Follow up as needed on:

- important versus merely useful tasks
- frequent versus rare tasks
- time pressure and error cost
- information and decisions needed at each step
- different roles or expertise levels
- permissions, dependencies, interruptions, and recovery
- what visibly confirms success

Keep a light distinction between what the user said, what existing material shows, and what remains an assumption. Do not over-formalize this distinction unless it affects a design decision.

### 2. Domain brief

Create a compact `domain-brief.md` containing:

- users and roles
- situation and trigger
- primary goal
- current practice and workarounds
- success signal
- relevant risks and unresolved assumptions

The brief is ready when the primary user, situation, goal, and success signal are concrete enough to discuss.

### 3. Use cases and priority

Create `use-cases.md`. For each candidate use case, capture:

| ID | Goal | Trigger | Frequency | Importance | Error cost | Current workaround |
|---|---|---|---|---|---|---|

Use qualitative values unless meaningful numbers are available. Treat the matrix as a conversation aid, not as an objective formula.

Use the result to identify:

- the primary flow: important and frequent
- important rare flows: make them findable and safe
- frequent low-impact flows: optimize only where friction matters
- low-impact rare flows: defer or keep secondary

A rare action with high error cost may outrank a frequent harmless action. Name the primary use case and what is explicitly out of scope.

### 4. Task analysis

Create `task-analysis.md` in terms of the user's goal, not a list of screens:

- preconditions and trigger
- main steps and user intent
- information needed and decisions made
- alternatives and branches
- confusion points and workarounds
- failure and recovery paths
- completion signal
- differences by role or expertise

The task analysis is ready when the important happy path, branches, and recovery behavior are understandable without referring to a UI layout.

### 5. Flow and state specification

Create `flow-specification.md` from the task analysis:

- entry points
- primary path
- decision points
- exit points
- information-architecture implications
- reachable states relevant to the task
- interruption and accessibility considerations

Consider the states that actually apply, such as default, loading/processing, empty/first use, validation error, unavailable/permission denied, partial completion, success, cancellation, undo, and recovery. Do not add states mechanically when they do not belong to the domain.

The flow is ready when each critical task step has a clear interaction or system response and consequential actions have an understandable result.

### 6. Prototype brief

Before a wireframe, HTML prototype, or implementation, create `prototype-brief.md`:

- the question the prototype should answer
- user and scenario
- in scope and out of scope
- screens or surfaces required by the flow
- states to represent
- realistic sample data
- task-based test instructions
- observations that would count as success, confusion, or failure

The prototype should test a decision or task, not merely demonstrate visual polish.

## References

Use the linked references when more structure is needed; do not reproduce their general UX knowledge in the main skill:

- `references/ux-artifacts.md` — compact artifact templates and authoritative starting points for JTBD, task analysis, journey maps, user flows, and usability testing.
- `references/example.md` — a short worked example showing the intended interview-to-specification journey.

## Handoff

Once the relevant artifacts are coherent, summarize the confirmed user, primary goal, prioritized use cases, primary flow, important states, prototype question, and remaining assumptions. Then continue with the existing UI/design/implementation workflow. If a later decision exposes a product-UX gap, return only to the affected artifact rather than restarting everything.

## Common corrections

If the agent jumps to a generic UI, ask about the concrete user, situation, goal, current workaround, and success signal before continuing. If it treats a feature request as a goal, translate it into the underlying job. If it generates screens before the flow is understood, return to task analysis. If it keeps expanding options, choose a bounded primary use case and a prototype question.