Mockup Use Cases Brief

Mockup use cases — Assistance platform

Short product brief: where non-production or partial experiences are intentional, who they serve, and when they graduate to real product behavior.

Persona priority (ranked)#

Order reflects breadth of audience and dependency order for the platform (marketing surfaces before gated admin demos).

Rank	Persona	Why first
1	Visitor / prospect	Largest reach; mockups on `www` shape first impressions and conversion before backend auth or CRM is complete.
2	Reader (docs / learn)	Public content IA and stubs unblock SEO and navigation while articles ship incrementally.
3	Internal design / engineering	Design-system and ui-library mockups reduce rework once visitor-facing flows stabilize.
4	Sales / leadership	Manager demos need credible marketing story and stable UI patterns first; often use seeded or dedicated demo environments last.

Surface map#

Priority	Use case	Primary surface	Key locations / routes
1	Pre-launch marketing and trust (auth preview)	`apps/www`	`app/dashboard/sign-in/` (`SignInForm.tsx`, `page.tsx`)
1	Conversion and lead experiments	`apps/www`	e.g. `components/Forms/RequestADemoForm.tsx` and related marketing CTAs
2	Content rollout stubs	`apps/docs`, `apps/learn`	Case studies and guides using “Coming Soon” or outline sections until MDX is complete
3	Design QA and handoff	`apps/design-system`, `apps/ui-library`	Component and layout examples; align with `.design/pen/` (`assistance.pen`)
4	Sales / stakeholder demos	`apps/manager`	Admin routes: users, subscriptions, invoices, etc. — via demo tenant, seeds, or env-specific deploy (pattern TBD)

User stories (summary)#

Visitor: I see a credible sign-in / sign-up experience so I understand the product before real auth exists.
Visitor: I can complete or attempt lead flows so UX, validation, and messaging can be tested before full CRM integration.
Reader: I can navigate to real URLs and shells while long-form content is still written.
Design / engineering: I can review components in context (states, breakpoints, themes) against design sources.
Sales / leadership: I can walk through admin scenarios without touching production data.

Success metrics (indicative)#

Use case	Signals to track
Marketing auth mockup	Visits to `/dashboard/sign-in`, time on page, CTA clicks from landing, bounce vs scroll
Lead / demo forms	Form starts, completions, validation errors, Plausible events (see `packages/common/telemetry`)
Docs / learn stubs	Page views on stub pages, outbound clicks to related content, time to replace stub with full article
Design-system / ui-library	Internal review cycles, design–dev issue count tied to specific examples
Manager demos	Demo session completion, stories covered per session, no production incidents

Exit criteria (when the mockup ends)#

Use case	Done when
www dashboard auth	Real authentication is wired (e.g. GoTrue / auth-api or chosen provider); mock error strings and fake delays removed; OAuth providers enabled or hidden intentionally.
Lead / demo forms	Submissions persist or enqueue (CRM, email, API); user-visible success/failure states reflect real backend; experiments documented.
Docs / learn stubs	Stub sections replaced by full MDX content; “Coming Soon” removed or narrowed to truly future work.
Design-system / ui-library	N/A as full retirement — these remain reference surfaces; “exit” means a specific component variant is signed off and consumed in apps without drift.
Manager demos	Either production Manager with role-scoped access, or a documented demo environment (seed data, read-only, or dedicated URL) so demos are not ad-hoc mocks on prod.

apps/www/app/dashboard/sign-in/SignInForm.tsx — UI-only auth messaging today.
apps/manager/src/routes/_admin/admin/* — Admin feature routes for demo targeting.
apps/design-system, apps/ui-library — Visual and component mockups.

Follow-up#

Pick dates or owners for each exit row (auth, forms, stubs, Manager demo) so mockups do not linger without a decision.
www auth: Choose provider and integration path; either remove mock messaging or replace with honest “beta / invite-only” copy until launch.
Lead forms: Confirm destination (API, CRM, email); add or verify Plausible events for starts, success, and validation failures.
Docs / learn: Inventory “Coming Soon” pages; prioritize by traffic or roadmap and assign content owners.
Manager demos: Decide pattern (seeded staging, read-only role, or separate demo deploy) and document URL, credentials policy, and reset procedure.
Design-system / ui-library: Run a periodic pass against assistance.pen for drift; log gaps as issues with links to both sources.
Revisit this brief after the first real auth and first live lead submission — update exit criteria if scope changed.

Out of scope (this brief)#

Implementing demo mode, feature flags, or replacing the www sign-in mockup with production auth — track as separate engineering tasks once exit criteria above are scheduled.