[UX] Wireframe exploration — 5-10 concepts across every surface #362

Open
opened 2026-08-25 20:39:24 +00:00 by claude-bot · 5 comments
Contributor

Found in the August 2026 session lifecycle review (#319).

What

Produce 5-10 distinct wireframe concepts covering every potential UX surface, for side-by-side comparison. These are deliberately low-fidelity and deliberately divergent — the point is to explore genuinely different structural answers, not to polish one.

Each concept should take a clear position on the questions the review exposed:

  • Where does attention live? A dashboard inbox, a per-campaign activity feed, ambient badges, or something else. The product currently has no answer at all.
  • What is the navigational spine? A persistent nav with a campaign switcher, a command palette, a session-centric hub, a sidebar. Today navigation is strictly a tree walk through page-specific breadcrumbs.
  • Is the session or the campaign the primary object? Much of the current awkwardness comes from prep, shelf, recording and review living in different places despite all being about one session.
  • How do GM and player views relate? Mirrored, separate, or one view with role-conditional density.
  • What is the at-the-table surface? Currently three partial screens with incomplete links between them.

Cover every surface, not just the obvious ones: dashboard, campaign, session, prep, live/at-the-table, recording, review and approval, wiki and lore review, quotes, analytics, profile, and admin.

Acceptance criteria

  • 5-10 concepts, each taking a coherent and distinct position
  • Every surface from the inventory appears in every concept, or its absence is a deliberate stated choice
  • Each concept is walked through against the six core journeys
  • Concepts are presented together for comparison, with the trade-offs of each stated plainly
  • Mobile and at-the-table treatment is shown, not deferred
Found in the August 2026 session lifecycle review (#319). ## What Produce **5-10 distinct wireframe concepts** covering every potential UX surface, for side-by-side comparison. These are deliberately low-fidelity and deliberately divergent — the point is to explore genuinely different structural answers, not to polish one. Each concept should take a clear position on the questions the review exposed: - **Where does attention live?** A dashboard inbox, a per-campaign activity feed, ambient badges, or something else. The product currently has no answer at all. - **What is the navigational spine?** A persistent nav with a campaign switcher, a command palette, a session-centric hub, a sidebar. Today navigation is strictly a tree walk through page-specific breadcrumbs. - **Is the session or the campaign the primary object?** Much of the current awkwardness comes from prep, shelf, recording and review living in different places despite all being about one session. - **How do GM and player views relate?** Mirrored, separate, or one view with role-conditional density. - **What is the at-the-table surface?** Currently three partial screens with incomplete links between them. Cover every surface, not just the obvious ones: dashboard, campaign, session, prep, live/at-the-table, recording, review and approval, wiki and lore review, quotes, analytics, profile, and admin. ## Acceptance criteria - [ ] 5-10 concepts, each taking a coherent and distinct position - [ ] Every surface from the inventory appears in every concept, or its absence is a deliberate stated choice - [ ] Each concept is walked through against the six core journeys - [ ] Concepts are presented together for comparison, with the trade-offs of each stated plainly - [ ] Mobile and at-the-table treatment is shown, not deferred
Author
Contributor

Picking this up alongside #361. Seven concepts plus the as-built baseline, each taking a distinct position on the five questions in the body (attention, spine, primary object, GM/player relation, at-the-table surface):

  • C1 Campaign Desk — keep the campaign container, add a real second level (sidebar / bottom tabs), one layout grammar.
  • C2 Session First — open on this week; every session is Plan · Play · Review; a Now bar everywhere.
  • C3 Console & Companion — a phone-first player app and a desktop GM console.
  • C4 The Feed — the bot's event stream as the in-app spine, every item actionable.
  • C5 Command Deck — panels that open beside each other, a command palette.
  • C6 Book & Table — a reading mode between sessions, a full-screen dark table mode during them.
  • C7 Timeline — the campaign as a scrollable story, sessions expanding in place.

Each draws six structural surfaces (home, campaign, session, prep, at the table, review and wiki) at desktop and phone width in one shared low-fidelity kit, with a dashed line where the first phone screen ends so scroll order is judged, role tags on GM-only regions, and callouts. Secondary surfaces are placed per concept in words. Each is walked through the six journeys and rated; a comparison matrix and a recommendation close the page. Delivered as an artifact for checkpoint A.

Picking this up alongside #361. Seven concepts plus the as-built baseline, each taking a distinct position on the five questions in the body (attention, spine, primary object, GM/player relation, at-the-table surface): - **C1 Campaign Desk** — keep the campaign container, add a real second level (sidebar / bottom tabs), one layout grammar. - **C2 Session First** — open on this week; every session is Plan · Play · Review; a Now bar everywhere. - **C3 Console & Companion** — a phone-first player app and a desktop GM console. - **C4 The Feed** — the bot's event stream as the in-app spine, every item actionable. - **C5 Command Deck** — panels that open beside each other, a command palette. - **C6 Book & Table** — a reading mode between sessions, a full-screen dark table mode during them. - **C7 Timeline** — the campaign as a scrollable story, sessions expanding in place. Each draws six structural surfaces (home, campaign, session, prep, at the table, review and wiki) at desktop and phone width in one shared low-fidelity kit, with a dashed line where the first phone screen ends so scroll order is judged, role tags on GM-only regions, and callouts. Secondary surfaces are placed per concept in words. Each is walked through the six journeys and rated; a comparison matrix and a recommendation close the page. Delivered as an artifact for checkpoint A.
Author
Contributor

Checkpoint A is ready for review: https://claude.ai/code/artifact/6e06cfa2-41fb-4f9b-8ed2-1d4d2f891bfe (private artifact; the brief from #361 is the first section).

Eight concept blocks (the as-built baseline plus C1–C7), 96 frames in one shared low-fidelity kit, a "group by surface" switch to compare the same screen across all concepts, the six-journey fit matrix, build-cost and backend-change columns, a "worth borrowing" list per concept, and a recommendation: carry C2 Session First and C6 Book & Table to mockups with C1 Campaign Desk as the control, and borrow C3's Queue, C4's Live card, C5's open-beside and C7's index regardless.

Limits of the medium, recorded by the renderers and worth knowing when reading: stickiness, drawers, bottom sheets, popovers, expand-in-place motion and reading measure can only be labelled, not drawn; two frames per surface means player-instead views sit under the GM content or in a callout; full-screen table modes cannot scroll. Mockups (#363) do not have these limits.

The concept specs, kit and assembly script are kept alongside the inventory so the chosen concepts can be carried into mockups without redrawing.

**Checkpoint A is ready for review:** https://claude.ai/code/artifact/6e06cfa2-41fb-4f9b-8ed2-1d4d2f891bfe (private artifact; the brief from #361 is the first section). Eight concept blocks (the as-built baseline plus C1–C7), 96 frames in one shared low-fidelity kit, a "group by surface" switch to compare the same screen across all concepts, the six-journey fit matrix, build-cost and backend-change columns, a "worth borrowing" list per concept, and a recommendation: carry **C2 Session First** and **C6 Book & Table** to mockups with **C1 Campaign Desk** as the control, and borrow C3's Queue, C4's Live card, C5's open-beside and C7's index regardless. Limits of the medium, recorded by the renderers and worth knowing when reading: stickiness, drawers, bottom sheets, popovers, expand-in-place motion and reading measure can only be labelled, not drawn; two frames per surface means player-instead views sit under the GM content or in a callout; full-screen table modes cannot scroll. Mockups (#363) do not have these limits. The concept specs, kit and assembly script are kept alongside the inventory so the chosen concepts can be carried into mockups without redrawing.
Author
Contributor

Checkpoint A amended at the owner's request: two audience pages, and the in-person table as a sixth question every concept answers.

Answers save to each page's own store (feedback/<audience>-<id>, keyed by the name the person gives, editable on return from the same device); a readout comes back as a table on request. Where saving is unavailable the page offers "Copy my answers" instead.

The in-person model and each concept's shared-screen answer are recorded in #542 and in the brief (#361).

**Checkpoint A amended** at the owner's request: two audience pages, and the in-person table as a sixth question every concept answers. - **For players** (the beta testers): https://claude.ai/code/artifact/f30840a2-f03b-4fc7-be11-81c7df827548 — the seven concepts plus today's app, four screens each, phone first (home, a session, game night, afterwards). On game night the desktop frame is repurposed as **the shared screen at an in-person table**, so the in-person face of every concept is drawn. Plain-language narrative per concept, callouts written for a player, a five-point scale and a comment box under each, two picks and four questions at the end (how they learn when we play, what they look at during a game, what they would want on a room screen versus their phone, what they would fix first). - **For GMs**: https://claude.ai/code/artifact/fd850062-665a-4951-bef8-af77dfb6734c — the six GM screens per concept, an in-person note per concept, the same form with GM questions. - **The design lead's page** (brief, all concepts, matrix, recommendation, links to both): https://claude.ai/code/artifact/6e06cfa2-41fb-4f9b-8ed2-1d4d2f891bfe Answers save to each page's own store (`feedback/<audience>-<id>`, keyed by the name the person gives, editable on return from the same device); a readout comes back as a table on request. Where saving is unavailable the page offers "Copy my answers" instead. The in-person model and each concept's shared-screen answer are recorded in #542 and in the brief (#361).
Author
Contributor

The beta testers cannot open the artifacts (no claude.ai accounts), so the two audience pages now also exist as a self-hosted site: tools/feedback-site/ (PR to follow), a separate container with the same players' and GMs' pages, a share-key-gated form, a JSON-file store, and an admin readout with CSV. Running on the dev box at port 18090; public exposure needs a hostname (a DNS record plus one Caddy entry) and is the owner's call. The artifact pages stay as the owner's and the design lead's copies; the site is where the players answer.

**The beta testers cannot open the artifacts** (no claude.ai accounts), so the two audience pages now also exist as a **self-hosted site**: `tools/feedback-site/` (PR to follow), a separate container with the same players' and GMs' pages, a share-key-gated form, a JSON-file store, and an admin readout with CSV. Running on the dev box at port 18090; public exposure needs a hostname (a DNS record plus one Caddy entry) and is the owner's call. The artifact pages stay as the owner's and the design lead's copies; the site is where the players answer.
Author
Contributor

The feedback site is public at https://questboard-dev.rhoving.com/feedback/ (Caddy handle_path on the dev hostname → the container on docker-test:18090; iac-repo PR #405 applied with the Caddy playbook, dry-run first; the dev Quest Board itself is unaffected). Verified end to end from outside: pages 200, /feedback redirects to /feedback/, a write without the share key is refused, a write with it is stored, and the admin readout and CSV need the admin key.

Two owner decisions applied at the same time (PR #550):

  • The players' page no longer carries the in-person material: game night is the phone drawing only, the in-person note and question are gone, and a question about opening the app between games takes the slot.
  • The GMs' page gains a seventh section per concept, "The shared screen, if the table is in one room", so GMs give that feedback; the in-person note stays there.

The artifact copies of both pages were republished to match. Links for the testers carry the share key (/feedback/players?k=…, /feedback/gms?k=…); the readout is /feedback/admin with the admin key, or the JSON files in the container's volume.

**The feedback site is public at https://questboard-dev.rhoving.com/feedback/** (Caddy `handle_path` on the dev hostname → the container on docker-test:18090; iac-repo PR #405 applied with the Caddy playbook, dry-run first; the dev Quest Board itself is unaffected). Verified end to end from outside: pages 200, `/feedback` redirects to `/feedback/`, a write without the share key is refused, a write with it is stored, and the admin readout and CSV need the admin key. Two owner decisions applied at the same time (PR #550): - The **players'** page no longer carries the in-person material: game night is the phone drawing only, the in-person note and question are gone, and a question about opening the app between games takes the slot. - The **GMs'** page gains a seventh section per concept, "The shared screen, if the table is in one room", so GMs give that feedback; the in-person note stays there. The artifact copies of both pages were republished to match. Links for the testers carry the share key (`/feedback/players?k=…`, `/feedback/gms?k=…`); the readout is `/feedback/admin` with the admin key, or the JSON files in the container's volume.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#362
No description provided.