# Creator Prototype Gap Closure — Design

Date 2026-08-19 · branch `creator-update`
Companion to [`creator-prototype-coverage-audit.md`](./creator-prototype-coverage-audit.md)

Korean text appears only inside quoted UI strings.

## 1. Purpose

The coverage audit put the creator prototype at ~62% of the existing product's UI/UX surface: 21 screens fully covered, 20 partial, 17 missing, plus 8 missing modals. This document specifies the work that closes that gap and the order it happens in.

**Success criterion.** Every creator journey the existing product supports can be walked end to end in `creator/main.dc.html` without hitting a dead end, and every screen satisfies the checklist items named for it in section 6.

## 2. Scope decisions

These were settled during brainstorming and constrain everything below.

| Decision | Resolution | Consequence |
|---|---|---|
| Artifact | **Prototype screens only**, in `creator/main.dc.html` on branch `creator-update` | Output is design. No API wiring, no tests, no work in `startview-platform`. Production porting is a separate future project. |
| The three absent modules | **NONE are in scope.** `2026-08-11-cross-role-consistency-design.md` settles all three: 수요조사 **retired** (§5.3, "Creator never had it"), 공동구매 + 어필리에이트 **excluded** (§10, "teammate-owned, not on prod"). The original "all three in scope" decision was taken without consulting that spec and is void. | Phase 4 is cancelled. The audit flagged these as gaps only because it compared against the legacy Angular app. |
| Tab-bar IA | **Fold into Discover as modes**; affiliate additionally gets a Home card and a MY menu item | Tab bar stays at five items. Discover's mode switcher grows from 2 to 4. Affiliate loses the top-level prominence it has in the existing app — an accepted trade. |
| Payout model | **Both** — automatic monthly payout by default, request-based early withdrawal as an opt-in | Payout history must interleave two kinds of payout legibly in one timeline. |
| Sequencing | **Shared primitives first**, then journeys, then modules, then polish | Phase 0 ships no user-visible screen. |

### Out of scope

- Any change to `startview-platform` (`apps/client`, `apps/client-web`).
- Backend, API, data-model, or performance concerns.
- Re-designing screens the audit marked fully covered, unless a primitive from Phase 0 supersedes their local treatment.
- Advertiser and admin prototypes.

## 3. Design grounding

Guidance came from the `ux` MCP server rather than from taste. Each phase's acceptance criteria cite the checklist that governs it.

**Checklists applied:** Submitting a form · Uploading media · Showing input error · Resetting password · Deleting account · Contacting support · Filtering items (all Flows category).

**Laws applied:**
- **Doherty Threshold** — feedback within 400ms; tiers the loading treatment in Phase 0.
- **Serial Position Effect** — first and last items in a series are best recalled; drives the success-screen layout and the payout-history row.
- **Paradox of the Active User** — users don't read manuals; constraints must appear before an action, not as post-hoc errors.

## 4. Phase 0 — Shared primitives

No new screen. Output is a vocabulary that the remaining ~36 items consume. Built first because `로딩`, `스켈레톤`, and `재시도` currently appear **zero times** in 606KB of prototype, and five of the six P0 items plus all thirteen module screens need them. Designing them once prevents 36 independent improvisations.

### 0.1 Loading, tiered

| Expected latency | Treatment |
|---|---|
| < 400ms | Nothing. A spinner that flashes is worse than no spinner. |
| 400ms – 1s | Skeleton matching the destination's shape. |
| > 1s | Determinate progress indicator. |

Three skeleton shapes cover every surface in the prototype: **list row**, **detail hero**, **card grid**.

### 0.2 Error and retry

Two scopes. **Inline** — one section failed, the rest of the page still works. **Full-surface** — nothing loaded. Both must state what failed and offer a retry affordance.

### 0.3 Empty state

One pattern: icon, headline, one line of orientation, and a CTA when a useful next action exists. Must distinguish two cases that read differently to a user:

- **Genuinely empty** — nothing exists yet. CTA points at creating the first one.
- **Filtered to nothing** — things exist but the filter excluded them. Per Filtering items §7, copy suggests relaxing or clearing filters, and the clear-filters control is right there.

### 0.4 Upload trio

Governed by Uploading media. Consumed by three distinct flows — review submission, revision re-upload, group-buy footage — which is why it is defined once.

1. **Constraints stated before the attempt.** `500MB 이하`, video-only, visible in the upload area. Not a post-hoc error (Paradox of the Active User).
2. **Progress** with filename and percentage.
3. **Outcome status** with a recovery action, not merely a red message. Failure states: over size, wrong format, network failure.
4. **Actions**: retry, cancel in progress, delete.

### 0.5 Destructive-confirm sheet

One component serving cancel-participation, cancel-reservation, channel reset, unfollow, and account deletion. Per Deleting account §3, it states what actually happens and whether it is reversible **before** the confirm. No guilt-tripping or passive-aggressive copy.

### 0.6 Success-screen pattern

For terminal states; first consumer is application-complete. Layout follows Serial Position Effect — **what just happened** at the top, **what happens next** at the bottom, supporting detail in the middle where recall is weakest.

### 0.7 Input-error convention

Per Showing input error: field stays in default state while typing, validates on blur, error clears on refocus. One existing case must be brought in line — the signup password field currently validates inline as the user types (`main.dc.html:6301,6307`).

## 5. Phases 1–5

Ordering principle: every existing journey is whole before any new module begins.

> **Correction (2026-08-20).** Phase 1 originally included a four-screen demand-survey module. That was an error: 수요조사 was retired product-wide and folded into 제안/협업. The screens were built, then removed. Its rows are struck from the table below; the creator's equivalent journey is the proposal flow.

### Phase 1 — Close the P0 breaks (~9 screens)

| Screen | Notes |
|---|---|
| Application complete | First consumer of the success pattern (0.6). Resolves the audit's most severe dead end: submitting the form currently leads nowhere. |
| Proposals inbox | Received / sent tabs. Full status vocabulary: awaiting selection, under review, selected, not selected, confirmed, rejected, expired. Response-deadline treatment. |
| Proposal detail | Accept / reject; "propose again after rejection"; confirm → collaboration transition. |
| Payout history | Implements the "both" payout model. |

**Payout-history design note.** Automatic monthly payouts and early-withdrawal requests share one timeline, so the row must make *kind* legible at a glance — not only amount and date. Per Serial Position Effect the row's first and last elements carry recall, so kind and status take those positions. States: scheduled, processing, carried over (below threshold), and the request-specific states.

Consumes primitives 1, 2, 4, 5, 6.

### Phase 2 — Harden the submission pipeline (~7 items)

Where the upload trio actually lands.

- Review submission with the full upload trio.
- Raw-footage URL registration (Naver Blog cannot auto-link, so a URL field is required).
- Courier tracking link-out from the tracking number.
- Cancel-participation and cancel-reservation confirms (consumes 0.5).
- My-campaigns three-way tab restructure: `제작 필요` / `전체` / `미선정·취소`. The prototype currently organises this surface on a single "my turn" axis; the existing product's three tabs answer a different question and both are needed.
- Campaign-detail enrichment: image expand/collapse, store contact and homepage, recommendations, closed-campaign state.
- Apply form: raw-footage submission toggle, itemized privacy-consent expansion, submit-failure error (Submitting a form §4–5).

### Phase 3 — Auth recovery and channel registration (~7 screens)

Password reset is four screens exactly as Resetting password specifies:

1. **Request** — email prefilled from the login attempt (§2).
2. **Sent confirmation** — explains what arrives and what to do with it (§3–4).
3. **New password** — with stated requirements (§5).
4. **Success** — returns the user to their original intent, logging in (§6).

Plus: find-email; channel-registration detail with Naver Clip URL paste and its "클립 주소 받는 법" guide, theme selection, collecting-in-progress notice, and reset confirm; channel theme/category sheet.

Note the existing dead link at `main.dc.html:174` — "비밀번호를 잊으셨나요?" is styled as a link with no destination. Resetting password §1 wants exactly this link, so the affordance is right and only the destination is missing.

### Phase 4 — CANCELLED

> Group buy and affiliate are excluded product-wide (`2026-08-11-cross-role-consistency-design.md` §10 — teammate-owned, not on prod). Do not build these. The original contents are struck below for the record.


- Discover gains **group buy** as a mode alongside campaign and brand.
- Group-buy list, detail, apply.
- My group-buy participation: pending-approval and cancelled states, raw-footage submission and inspection wait, dedicated sales-link issuance and copy.
- Affiliate list and detail.
- My affiliate: links, expected commission, payout notice, and the **mandatory ad-disclosure text** — a legal requirement, not decoration.
- Link-issued modal.
- The two entry points the IA decision requires: a Home affiliate card and a MY menu item.

**Discover IA note.** The mode switcher goes from two options to four in this phase. That is the point where Filtering items §4–7 begin to bind — active modes must be visible, individually clearable, and the no-results case needs the filtered-to-nothing empty state from 0.3 rather than the genuinely-empty one.

### Phase 5 — Supporting flows and polish (~17 items)

**P2:** map view · sort and filter drawer · inquiry list/detail/edit with type selection (Contacting support §2–3 governs the method choice between AI chat and a typed inquiry) · video collection with detail and preview · AlimTalk consent modal · point-shop purchase confirm plus sort and category · penalty score gauge and permanent-suspension state · account-deletion notice and withdrawal grace overlay (Deleting account §2–4) · advertiser-conversion inquiry · brand-detail section tabs and follow toggle · profile completeness gauge.

**P3:** no-search-results · attendance reward history · separate marketing-purpose consent · home banner modal · product preview.

## 6. Acceptance criteria

A phase is done when every screen in it satisfies the checklist items named here. This is deliberately objective — "looks good" is not an acceptance criterion.

| Phase | Governing checklists | Additional criteria |
|---|---|---|
| 0 | Uploading media (all 7) · Showing input error (all 4) · Filtering items §7 · Deleting account §3 | Three skeleton shapes exist; retry affordance exists at both scopes |
| 1 | Submitting a form (all 5) · Uploading media · Deleting account §3 | No journey in audit §7 terminates in a dead end; payout row makes kind legible without reading the amount |
| 2 | Uploading media (all 7) · Submitting a form §4–5 · Showing input error | Every upload entry point uses the 0.4 trio unmodified |
| 3 | Resetting password (all 6) · Showing input error | The `main.dc.html:174` link resolves |
| 4 | Filtering items (all 7) · Submitting a form · Uploading media | Affiliate reachable in ≤2 taps from Home; ad-disclosure present on every affiliate link surface |
| 5 | Contacting support (all 3) · Deleting account (all 4) · Filtering items | — |

## 7. Dependencies and risk

**Hard dependency:** Phase 1 on Phase 0. Nothing else is hard.

Phases 2, 3, and 4 are mutually independent once Phase 1 lands — they touch disjoint surfaces and can be reordered or parallelised if priorities shift. Phase 5 depends on nothing and can absorb schedule pressure.

**Risks**

| Risk | Mitigation |
|---|---|
| `main.dc.html` is already 606KB in one file; ~36 more views will strain it | Track file size per phase. If editing becomes unreliable, split by feature area — but only at a phase boundary, never mid-phase. |
| Phase 0 shows no visible progress and may feel like stalling | It is the seven patterns in §4, not a design system. If it grows past those seven, that growth is scope creep — cut it back rather than extending the phase. |
| Affiliate loses top-level prominence under the chosen IA | Accepted trade. The Home card plus MY item are the compensation, and the ≤2-tap criterion in §6 is what holds it honest. |
| The payout "both" model has no precedent in the existing product | Payout history is designed to interleave from the start rather than retrofitted, which is the expensive failure mode. |

## 8. Open questions

Three audit ❓ items remain unresolved. None blocks Phase 0 or Phase 1.

1. **Events vs guide tab.** The prototype's events tab is labelled "가이드"; `client-web /(tabs)/events` carries events and articles. Same surface or two? Affects Phase 5 only.
2. **`payment-receipt` modal** — creator-facing or advertiser-facing? If creator-facing it joins Phase 5; if not it leaves scope.
3. **`campaign-inquiry`** — is campaign-context inquiry meant to be fully replaced by the prototype's AI chat, or does it need its own entry? Affects Phase 5's Contacting support work.