# Worked example: backup UI

This example shows the intended level of detail. It is deliberately small; the real interview should adapt to the user's domain.

## Starting request

> “I need a UI for backups.”

## Interview direction

Ask:

- Who operates the backups: a home user, an administrator, or both?
- What is the primary goal: configure, monitor, restore, or investigate a failure?
- When is the UI used: during normal operation or under time pressure after data loss?
- How are backups currently checked and restored?
- Which mistake would be most costly?

## Domain brief

- User: technically capable home operator
- Trigger: a backup alert or a planned restore test
- Primary goal: determine whether important data is safely recoverable
- Current practice: checks logs and manually searches backup locations
- Success signal: a selected file or snapshot is restored and verified
- Open question: whether the normal surface should prioritize monitoring or restoration

## Use cases

| ID | Goal | Frequency | Importance | Error cost |
|---|---|---:|---:|---:|
| UC-01 | Check backup health | high | high | medium |
| UC-02 | Restore a file | low | high | high |
| UC-03 | Investigate a failed job | medium | high | high |
| UC-04 | Change retention settings | low | medium | high |

Primary flow: UC-01. Critical secondary flow: UC-02.

## Task analysis: restore a file

1. User knows the file or folder that is missing.
2. User chooses a backup source and a date/version.
3. System shows what will be restored and where.
4. User previews or confirms the restore.
5. System restores to a safe location or offers an explicit overwrite choice.
6. User verifies the result.

Important branches: source unavailable, file not found, partial restore, conflicting destination, permission denied.

## Prototype question

Can a user who has not used the restore UI before select the correct version and restore one file without accidentally overwriting the current file?

The next step is a small flow prototype, not a complete backup dashboard.