Evaluate member and admin journeys in four live-switchable designs #12

Open
opened 2026-10-20 21:29:42 +00:00 by phg · 0 comments
Owner

Part of #1

Question

Which interaction model and visual direction make prevouch's member and admin journeys clear, and what changes are needed before the specification is ready for implementation?

Use the prototype and frontend-design skills to build a disposable, navigable prototype with the same stateful journeys in Gumroad-inspired, Minimal, Apple System 7, and Papercut designs. The live switch must retain route, queue data, form input, and simulated event state. Use the requested Tailwind CSS 4.3 once verified; if research finds a mismatch, obtain the human's version decision here before substituting.

Include joining with +n, separate delivery address, allocation progress under each policy, self-purchase voucher and return-address instructions, optional push onboarding, signup/invitation/OAuth states, and admin event/queue/invitation/template/incoming-mail/recovery screens. Simulate external services and provide repeatable scenarios, including eight available vouchers, later quantity additions, and stalled delivery. Cover responsive and keyboard use without sacrificing each design's identity.

Link the runnable prototype and its branch as assets. Resolve only after the human has reacted to the four designs and flows; the agent must not choose on their behalf. Record the selected direction or retained alternatives and any new decision tickets.

Cover all three policies from Define allocation policies and organizer-triggered shuffling: FCFS, Shuffled (grouped), and Shuffled (everyone), including the organizer-triggered initial shuffle, fixed subsequent order, new entries appended at the end, and the agreed grouping behavior. Prototype policy changes before the first voucher is sent or first ticket is bought by the Orga-team, and the policy lock afterwards. Add both purchase modes from Define central-purchase workflow and fulfillment and funding/refund states from Define upfront-payment tracking and refunds for central purchases. In central purchase, prototype member bank-payment instructions/status, organizer-only voucher access and purchase claims/results, participant ticket fulfillment, exhausted supply, and full/partial refunds. Members never see voucher codes in this mode. Include underfunded groups, partial +n fulfillment, and audit/correction journeys as settled by their decisions. Simulate bank activity and seller purchases; keep the same scenarios and state across all four designs.

Settled funding and refund input

Use the agreed resolution in Define upfront-payment tracking and refunds for central purchases. Include its worked balances and purchase/refund holds in the simulated central-purchase journeys. Explicitly cover configurable per-holder tiers and required member numbers, partially funded groups, skipped/restored group priority, full/partial/no service, refund failures/retries, and correction history. Preserve these scenarios and state across all four designs.

Part of #1 ## Question Which interaction model and visual direction make prevouch's member and admin journeys clear, and what changes are needed before the specification is ready for implementation? Use the prototype and frontend-design skills to build a disposable, navigable prototype with the same stateful journeys in Gumroad-inspired, Minimal, Apple System 7, and Papercut designs. The live switch must retain route, queue data, form input, and simulated event state. Use the requested Tailwind CSS 4.3 once verified; if research finds a mismatch, obtain the human's version decision here before substituting. Include joining with +n, separate delivery address, allocation progress under each policy, self-purchase voucher and return-address instructions, optional push onboarding, signup/invitation/OAuth states, and admin event/queue/invitation/template/incoming-mail/recovery screens. Simulate external services and provide repeatable scenarios, including eight available vouchers, later quantity additions, and stalled delivery. Cover responsive and keyboard use without sacrificing each design's identity. Link the runnable prototype and its branch as assets. Resolve only after the human has reacted to the four designs and flows; the agent must not choose on their behalf. Record the selected direction or retained alternatives and any new decision tickets. Cover all three policies from [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14): FCFS, Shuffled (grouped), and Shuffled (everyone), including the organizer-triggered initial shuffle, fixed subsequent order, new entries appended at the end, and the agreed grouping behavior. Prototype policy changes before the first voucher is sent or first ticket is bought by the Orga-team, and the policy lock afterwards. Add both purchase modes from [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15) and funding/refund states from [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). In central purchase, prototype member bank-payment instructions/status, organizer-only voucher access and purchase claims/results, participant ticket fulfillment, exhausted supply, and full/partial refunds. Members never see voucher codes in this mode. Include underfunded groups, partial +n fulfillment, and audit/correction journeys as settled by their decisions. Simulate bank activity and seller purchases; keep the same scenarios and state across all four designs. ## Settled funding and refund input Use the agreed resolution in [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). Include its worked balances and purchase/refund holds in the simulated central-purchase journeys. Explicitly cover configurable per-holder tiers and required member numbers, partially funded groups, skipped/restored group priority, full/partial/no service, refund failures/retries, and correction history. Preserve these scenarios and state across all four designs.
Sign in to join this conversation.
No milestone
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.

Reference
MISChaufen/prevouch#12
No description provided.