If the journeys and personas pages describe DomiDo in human terms, this page is where those descriptions are translated into testable behavioural requirements: short statements written from a persona's point of view, each with explicit acceptance criteria. Product managers use them to communicate intent, designers use them to scope screen states, engineers use them to size and build, and quality assurance uses them as the basis for test cases. This is the single source of truth for what behaviour the system must display from the user's perspective. The catalogue is organised into thirteen working areas — authentication and onboarding, Mode A (3D model upload), Mode B (artificial-intelligence text-to-3D), the gallery's published reference designs, the content gallery and social features, cart and checkout, the Phase A pre-order flow, order management and tracking, returns processing, the assembly viewer, account and settings, the admin dashboard, and accessibility — collected under fewer headings so the page reads as a coherent contract rather than a list of micro-epics.
Each story uses the classic "As a [persona], I want [capability] so that [outcome]" form, and a persona key abbreviates the six MVP personas: Geoff (retired homeowner), Sophie (urban professional), Ben (trade landscaper), Clare (3D designer), Emma (event planner), and Alex (first-time homeowner). Stories list the personas they primarily serve, but several stories serve multiple personas. Priorities follow a MoSCoW-style framework adapted for the Phase A launch: Must is required for the Phase A pre-order launch and blocks a core flow if absent; Should is expected at launch where absence degrades experience but does not block core flows; Could is desirable and included only if capacity permits; Won't is deferred to a later phase and recorded only for planning continuity. Acceptance criteria are written as a numbered list of observable behaviours, deliberately specific ("loads within two seconds on a 4G connection" rather than "loads quickly") so the criterion is unambiguously testable.
The six personas do not carry equal weight in MVP product decisions. The weighting (used to break ties and prioritise effort) is roughly Geoff at twenty-five percent and Alex at twenty-five percent at the high end, Ben at twenty percent and Sophie at fifteen percent in the middle, and Emma at ten percent with Clare at five percent at the low end for the consumer-facing flows. Clare's weight rises sharply once the designer marketplace activates in Phase C.
This area covers OAuth sign-in (Google, Apple, and Facebook only — there is no email-and-password account, and no other social provider), profile creation, the first-time guided tour, Progressive Web App installation, session management, and the ongoing account-and-settings surface. The headline behaviours read as a single contract. Tapping "Sign in with Google" opens the consent page in the system browser (not an in-application web view), returns the user to the home screen within three seconds, and surfaces name and profile photo immediately. "Sign in with Apple" triggers the native sheet on iOS or the web flow elsewhere, supports the "Hide My Email" relay, and stores the refresh token securely so subsequent launches do not require re-authentication for thirty days. "Sign in with Facebook" works for personal accounts and respects the user's privacy choices on the provider side. A first-login carousel of three or four screens explains what DomiDo does, the two creation modes, the published gallery, and how assembly works — each with a single sentence, an illustration, and dismissible Next or Skip controls — and is never shown again after dismissal or completion. New users get fifteen free artificial-intelligence credits on account creation, and if a user authenticates via an OAuth provider whose email already exists under a different provider, a clear message tells them which provider to use instead.
Sophie can set a display name (two to fifty characters) and a bio (up to two hundred and eighty characters); profile pictures come from the OAuth provider with no custom upload at this stage. The Progressive Web App prompts the user to "Add to Home Screen" on the second visit within seven days, dismisses for thirty days if declined, and launches in standalone mode with a brand-coloured status bar. Sessions persist across launches via a refresh token valid for thirty days; "Sign out everywhere" invalidates all refresh tokens on the server, terminates other sessions within fifteen minutes as access tokens expire, and keeps the current session active. Account-and-settings stories cover profile editing, address management against a postcode lookup service, payment-method management, notification preferences (email transactional, email marketing, in-application, and push as a post-MVP addition), language and locale, privacy controls, data export fulfilled within thirty days as required by the General Data Protection Regulation, and account deletion with a visible request status and a clear path through any pending obligations such as open orders or pending returns. Profile changes update gallery, comments, and published designs immediately.
This area covers selecting and uploading a 3D model, validating the file, configuring processing options, viewing pipeline progress, and reviewing the completed design. Tapping "Upload 3D Model" opens a device file picker filtered to GLB, GLTF, STL, and OBJ files. The front end validates extension and a one-hundred-megabyte size limit before initiating the upload — a file over the limit shows "File must be under 100MB. Your file is [X]MB" and an unsupported extension shows the supported list. Both binary and ASCII STL files are accepted, and STL files without colour or material data are processed with a default material. Non-manifold geometry is repaired automatically in stage two of the pipeline without user intervention unless repair fails entirely. On screens wider than seven hundred and sixty-eight pixels a drag-and-drop zone of at least three hundred by two hundred pixels appears with a dashed border and clear "Drop your 3D model here" copy; the border colour changes on hover; mobile devices fall back to a "Choose File" button.
Upload progress is visible during file transfer. A presigned URL is requested from the back end and the file uploads directly to object storage. The pipeline streams stage completion events to the front end over Server-Sent Events with a polling fallback every five seconds if the connection disconnects. Each stage label is human-readable ("Preparing your design") rather than internal ("Stage 3: Voxelisation"). If the pipeline fails, the user is redirected to an error screen with stage-specific guidance and a clear next action. Once processing completes, the design opens in a 3D viewer with four view modes (assembly, source model, blocks, fasteners), a bill-of-materials summary, the assembly step count, and an estimated price. The primary call-to-action is Save Design and the secondary is Add to Cart. A Refine path lets users re-run the pipeline with a different solver mode (fast, balanced, best) or adjust dimensions for parametric designs.
This area covers the prompt input, projection generation and iteration, 3D model selection, conversion to blocks, and credit-balance checking. The user enters a prompt and optionally uploads a reference image. The system checks the credit balance; if insufficient, it shows the exact shortfall and the date credits refresh. If sufficient, it creates a design record with status "processing" and queues an artificial-intelligence generation job. The worker calls a primary image-generation provider (with fallbacks through several alternatives), removes the background via a primary background-removal service with its own fallbacks, and returns a frontal preview image at least one thousand and twenty-four pixels square. Progress is streamed via Server-Sent Events. The user iterates through up to eight projections, with each projection regenerable an unlimited number of times for no additional credit cost — credits are charged at initial generation, not iteration. Iteration is conversational: the previous design remains on screen, the input asks "What would you change?", and a version history strip lets the user revert to any earlier iteration. Reference images can be uploaded at any iteration. After projection approval, the user selects a 3D-model provider (Hunyuan as default, with Meshy, Tripo, or a self-hosted alternative available), receives a generated GLB model, and views it in the 3D viewer. The model then enters the Mode A pipeline at stage one. Credits for steps that fail are refunded.
The launch gallery opens with a small set of category demonstrations published by Avvyland Limited itself before the marketplace opens — reference designs that show what the universal block system can build across the breadth of the catalogue (garden borders and raised beds, privacy and screening, utility concealment such as bin shelters and heat-pump or air-conditioning covers, and at least one statement piece). They are gallery designs, not a fixed product line; the company sells universal blocks and fasteners, and each reference design is a configuration of those. This area's stories cover browsing the gallery's reference designs, viewing detail pages with embedded 3D previews, customising size where the design exposes pre-computed scaled variants, and adding to cart. The gallery grid loads in under two seconds, sorts by price ascending by default, and shows lifestyle photography (not engineering renders), name, price range, and block count. Tapping a design opens a detail page with an embedded React Three Fiber viewer showing the pre-computed configuration, a description, technical specifications (dimensions, weight, recommended ground preparation), customer reviews where present, and a size customisation control where applicable. Dimension sliders snap to discrete pre-computed sizes; price and block count update in real time using a pre-computed scaling formula (no pipeline run). Dimensions outside the supported range surface a clear message directing the user to the upload mode for fully custom sizes.
This area covers publishing a design, browsing the gallery, multi-modal search (text, voice, image), filtering and sorting, viewing a design detail, liking and disliking, threaded commenting, following designers, building collections, and sharing. Publishing is open with asynchronous moderation: a design appears in the gallery immediately, and a background moderation pipeline scans preview images, description, and tags. Content that fails moderation is hidden and the publisher notified. Text search runs the query through a text encoder and matches against description and tag vectors using a vector-search aggregation; voice search transcribes first and then runs the text path; image search runs an image encoder against image vectors. Latency targets are under two seconds for text, under five seconds for voice including transcription, and under three seconds for image. Likes and dislikes use one vote per user per design enforced by a compound unique index. Threaded comments use a parent comment identifier for replies; comments are run through asynchronous moderation and shown to the author only while in pending state. Follow relationships drive a follower feed; collections can be public or private with auto-selected cover images. Sharing opens a native share sheet and generates rich Open Graph previews with embedded 3D viewing on the destination page. Every design has a "Buy This Kit" button that initiates the same checkout flow as a launch-gallery purchase. Recommendations in the MVP are global popularity — trending (weighted by views, likes, and purchases over the last seven days), most-purchased, newest, and staff picks — and personalised recommendations are deferred.
This area covers the cart, the Stripe Checkout integration, address collection, confirmation, and the Phase A pre-order flow that uses SetupIntent rather than PaymentIntent. Payment is via Stripe-hosted Checkout — no card details are entered inside the DomiDo application, keeping the regulatory scope for card data minimal. The cart shows each design's preview, price, and quantity, lets users remove items, and totals the order. Tapping "Pay" redirects to Stripe Checkout. Stripe handles card input, strong customer authentication where required, address collection, and tax calculation. On successful authorisation, the user is redirected back to a confirmation page and a webhook fires server-side to create the order record. Apple Pay is the prominent option on iOS, and PayPal must be visible at the top of the payment-method list rather than buried below card entry — this is critical for the older persona Geoff. Card decline, strong-customer-authentication failure, and address validation are all handled inside the Stripe-hosted page so the user sees Stripe's well-tested error states. Guest checkout is offered with optional account creation after payment ("Save your design for easy reordering"), and the confirmation page shows the 3D model render, the delivery-date range, a "What to expect" timeline, and a clear "Questions? Call us" phone number.
In Phase A the call-to-action reads "Pre-order — Ships [estimated month]". Stripe Checkout opens in setup mode and performs a card verification rather than a charge. The user enters card details on Stripe's hosted page; the card is verified but not charged; the SetupIntent identifier is saved against the pre-order. The confirmation email reads "Your pre-order is confirmed! Estimated ship date: [month]. Your card will be charged when your kit ships." The dashboard shows pre-order status (pre-ordered, confirmed, approved, ready to build), an estimated ship month, and a cancellation control. Cancellation invalidates the saved payment method and updates status. When Phase B activates, pre-orders are converted to real orders by charging the saved card through a payment intent and the converted order enters the physical fulfilment pipeline.
This area covers viewing orders in "My Orders", checking order status, viewing shipment tracking, accessing receipts and invoices, contacting support, and the returns workflow. Each order detail shows the design preview, items with quantities, total amount, status, shipping address, shipment tracking with carrier and tracking number (linking to the carrier's tracking page), receipt and Value-Added-Tax invoice, refund status if applicable, and a contact-support entry point. Status updates are pushed via Server-Sent Events when new and polled when revisited. The buyer can request address change, delivery preference change, return, replacement, issue report, dispute, payment retry, order message, or support contact through typed action sheets.
The return window is fifteen days from delivery (exceeding the United Kingdom Consumer Contracts Regulations fourteen-day minimum). The user selects a reason (change of mind, defective, wrong items, damaged in transit); the back end creates a return record and emails a prepaid label generated through the carrier integration. The return is graded A through D on receipt: A returns the full value with full re-entry to inventory; B returns most of the value with re-entry after repackaging; C returns partial value with partial re-entry; D rejects the return with inspection evidence. Refunds are processed via Stripe within two business days of grading. The buyer can dispute a grade within seven days, with photo evidence reviewed by a member of the operations team.
This area covers loading the design's assembly steps, navigating through them, viewing in three dimensions with multiple modes, saving progress across sessions and devices, working offline after initial load, and providing a "stuck-help" path. The viewer is a first-class experience, not a static document. It supports a step counter at the top, new-block highlighting (block-being-placed in colour, prior blocks ghosted), a piece-callout panel showing the blocks needed for the current step with quantity badges and colour swatches, free-orbit camera with pinch-to-zoom and single-finger orbit, snap-to-axis view buttons (front, back, left, right, top), a "fit to screen" reset, a step scrubber for rapid navigation, ghost view (translucent finished structure), and an exploded view for understanding internal connections. Outdoor-use considerations are non-negotiable: a high-contrast mode for bright sunlight; minimum sixteen-pixel body text (Geoff may not have reading glasses in the garden); large touch targets (forty-eight pixels minimum) for gloved hands; screen-always-on while assembly is active; service-worker caching so the viewer works offline after initial load; saved progress that syncs across devices. For trades and crews, a "Site mode" provides section-based navigation so multiple builders can work on different zones simultaneously, a "Foreman view" of overall progress, and a quick single-page visual overview for experienced builders. A "Build Together" pairing mode allows two devices to follow the same build, each assigned different stages with safety call-outs such as "Helper B braces this panel while Helper A secures connectors".
This area covers the seven admin surfaces: order management, pipeline monitoring, revenue, customer support, artificial-intelligence credit usage, system health, and content moderation. Order management shows every order with filters by status, date, and product; admins can update status, initiate refunds via the Stripe Application Programming Interface, mark returned, resend confirmation emails, and view associated design and bill-of-materials data. Pipeline monitoring shows rolling success rates, latency percentiles per stage, failure breakdown by stage and error type, queue depth, and worker health, with controls to retry failed jobs, view job logs, pause or resume queue processing, and manually trigger pipelines. The revenue dashboard shows daily, weekly, and monthly revenue, order count, average order value, revenue by design, revenue by channel attribution, cumulative revenue against target, and gross margin per design. Customer support supports lookup by email, order, or design identifier, with one-click resend, credit grant, and return-initiation actions. Artificial-intelligence credit usage shows consumed credits today, this week, this month, cost to DomiDo per provider, by operation, and per subscription tier. System health shows infrastructure status, error counts, resource usage, certificate expiry, and domain health, with acknowledgement and link-out to monitoring dashboards. Content moderation surfaces flagged content with the moderation queue, the moderation log audit trail, and approve, hide, remove, or warn actions.
This area covers Web Content Accessibility Guidelines 2.2 AA conformance: keyboard navigation for every authentication, checkout, and design-creation flow; alt text for every image; minimum 4.5-to-1 colour contrast for text; a text-based fallback for the 3D viewer (assembly steps as a numbered list); gallery search that works without voice (text always primary); axe-core automated scanning before launch; and a manual keyboard walkthrough of the three core flows.
Each story is mapped against the personas it primarily serves and the use cases and journey stages it implements. This matrix is the contract between product, design, and engineering: it lets quality assurance trace from a defect back to the story it violates, lets product confirm coverage of every persona's journey, and lets engineering size areas confidently.