If the Minimum viable product scope page tells you what DomiDo ships, this page tells you how people actually move through it. There are two complementary pictures here. The first is a structured catalogue of every formal use case visible in the application, written for engineers, product managers, and quality testers as the canonical source of which actor does what in which phase. The second is a set of rich emotional journey maps, written for designers, content strategists, and growth marketers who need to feel the user's experience minute by minute rather than describe it as a sequence of clicks. Both perspectives are organised around the same set of personas (introduced fully on the Personas and the jobs they hire DomiDo to do page) and both honour the phased launch: Phase A is non-binding interest, Phase A.5 is invited pre-orders that verify cards without charging them, and Phase B is the live commerce phase with charges, fulfilment, and shipping.
The diagram traces the canonical pre-order to build lifecycle. A design begins as a private draft, becomes a saved design once complete, and reaches the gallery when the customer chooses to publish. Other customers register non-binding interest in the listing, and when accumulated interest clears the manufacturing threshold an invite to pre-order is issued. Pre-order itself is a verified-card commitment via Stripe SetupIntent with no charge attached. Only when manufacturing is queued does the card get charged through Stripe PaymentIntent, the warehouse picks the kit, and the customer receives, assembles, and confirms the build.
Six kinds of actor appear in DomiDo's use cases. A guest is an unauthenticated visitor browsing the home page, gallery, listings, designer pages, help, and the legal and authentication surfaces. A buyer is a signed-in customer managing interest reservations in Phase A, invited no-capture pre-orders in Phase A.5, and real orders, addresses, payment references, privacy controls, notifications, and support requests in Phase B. A designer is a signed-in user creating drafts, publishing listings, managing them, generating promotional media in the built-in studio, building marketplace readiness in Phase A.5, configuring Stripe Connect payout readiness, running ad boosts, reviewing statements, and handling messages and an action queue. Support and staff are internal users assisting with order, return, dispute, payout, restriction, support, and listing states. Finance and trust is an internal role for payouts, statements, know-your-customer checks, taxes, refunds, return-fee disputes, restrictions, and dispute workflows. An admin has authority to create, update, publish, unpublish, archive, delete, and reorder Workshop and Help content.
The application's official journeys describe each major flow in plain prose; they form the source of truth for what must be possible at any given phase.
In public discovery, a guest lands on the home page and sees an entry point for creating an upload, a rail of gallery listings, designer discovery, a newsletter signup, and the header and footer. From the header the guest searches publicly available scopes or browses gallery listings; each listing card shows media, title, designer, price, save state, tags and badges, and live listing metadata where available. Opening a listing reveals product media, price (or a price-unavailable state), designer attribution, a kit and assembly summary, save and share and report actions, the Phase A interest-reservation call-to-action when active, the right jurisdictional Value-Added Tax and delivery copy for the phase, any disabled-remix messaging, and the Phase A.5 or B commerce entry only when the guest is eligible. From here the guest can open the authentication flow to save, follow, or check out — or keep browsing.
Sign-in is via OAuth only. The authentication modal offers Google, Apple, and Facebook as the only providers. The user picks one and completes the provider's authentication; on return DomiDo creates or resumes the account and brings the user back to whichever surface initiated the sign-in, with profile, drafts, saved listings, interest reservations, any Phase A.5 pre-orders, any Phase B orders, designer context, and authorised admin context all connected. If the OAuth flow fails, the modal shows a retryable error without losing the initiating surface.
Creating and publishing a design runs through a wizard. The designer opens the create wizard from the home page upload entry or the create entry; if a saved draft or generation state exists, the wizard offers to continue from it before starting a blank draft. The designer enters a title, a brief, and reference text, optionally applies a configured style preset that updates the prompt and reference media, uploads a supported source model (GLB, GLTF, OBJ, or STL up to one hundred megabytes), adjusts preview or crop where applicable, chooses a category, and adds tags from a suggestion list. The designer then moves through the wizard's stages: projections (six possible faces — front, back, right, left, top, bottom, with only the front compulsory and the rest optional); 3D-model generation (choosing a configured generation option and seeing cost, progress, completed tryouts, preview, statistics, and output size labels); feedback on the generated model; model selection; block-kit generation; review of bill of materials groups and stock-keeping-unit counts and estimated cost and build time; and finally save-or-publish with visibility (private, unlisted, or public), Phase A remix-disabled messaging, royalty percentage between zero and twenty-five, and a derived price and community-gift copy. If any job or validation step fails, the wizard keeps the prior work and offers retry or correction.
Reserving interest in a kit is the Phase A entry to commerce. A buyer opens a public listing and chooses the interest action; the interest sheet shows the listing media, title, listing-owner attribution, kit summary, indicative price (or a price-unavailable state), a supported-jurisdiction hint where known, and very clear non-binding language. The buyer may save the listing separately from reserving interest — the dashboard later shows saved listings and active or cancelled interest reservations as distinct states. The interest flow never starts a checkout; it collects only the minimum reservation context needed for demand learning, duplicate prevention, support, and later conversion eligibility. The buyer confirms or edits lightweight location intent if requested; if the jurisdiction is not yet supported for physical kits, the buyer sees coming-soon copy and the system may still record the interest where allowed but marks it as not currently convertible. The buyer must acknowledge that Phase A interest is not a pre-order, not legally binding, does not reserve production capacity, does not collect a card, does not create an order, and does not promise shipment. Repeated taps are de-duplicated. Confirmation creates an interest reservation, surfaces a reservation reference and a non-binding status, gives a cancellation path and a dashboard link, and never creates a Stripe object, charged order, pre-order, receipt, invoice, shipment, payout, or shipping promise.
Managing reservations, pre-orders, and orders happens on the dashboard. The buyer opens the dashboard and sees current Phase A interest reservations, any Phase A.5 no-capture pre-orders, and current and past Phase B orders. An order update inbox tracks unread and read items, severity, linked actions, and mark-read behaviour. Each item opens a detail sheet appropriate to its kind: an interest-reservation detail with non-binding acknowledgement, cancellation availability, and conversion-invite state; or a Phase B order detail with payment, delivery, fulfilment readiness, parcel tracking, receipt, invoice, refund, jurisdictional Value-Added Tax, and timeline information. Where Phase B payment retry is available, the buyer retries through Stripe with a saved or freshly verified payment reference. Orders may proceed, wait because required blocks are absent, or wait for production readiness. Buyers can request cancellation, address change, delivery preference change, return, replacement, issue report, dispute, payment retry, order message, or support contact. If a return is assessed with damage, wear, change of mind, or diminished value, the buyer sees a fee or deduction explanation and can dispute it. If a user is restricted for anti-abuse reasons, they can challenge that decision through support or dispute processing.
Building with the companion is a Phase B experience; before that, its controls are disabled, read-only, or preview-only. After delivery the buyer scans a QR code on the kit or opens the companion from the order. The companion loads the assembly steps and any saved progress; each step shows the required blocks, the join pattern, preview media, timers where available, and contextual support. A "stuck-help" path can escalate to support. Progress is saved; pause and resume work where supported; multiple builds can be tracked on the same account where supported. At the end, the companion can collect finished-build photos with sharing permission, designer-feedback permission, and a separate build-experience rating.
Designers managing listings and earnings is the designer-side equivalent of the buyer dashboard, and it changes shape by phase. In Phase A it shows attributed interest reservations, listing metrics, moderation and support state, disabled-remix items, and an action queue. Phase A.5 unlocks attributed no-capture pre-orders, projected royalties, payout readiness, Stripe Connect and know-your-customer tasks, statement previews, and messages — all the readiness work needed before Phase B fulfilment. Phase B adds captured sales, payouts due, balances, reserves and disputes, fees, and the statement archive. Within listing management, designers can edit title, description, category, tags, media, bill of materials and assembly, visibility, status, royalty, price, and publish state. The listing editor shows owner edit state, versioned state, editable versus platform-owned sections, moderation flags, similarity matches, analytics, action items, buyer preview, and any moderation-rerun eligibility before saving, discarding, requesting copy changes, or publishing updates. The royalty percentage is adjustable between zero and twenty-five (treated as Value-Added-Tax-inclusive); remix controls show that remixes are disabled in Phase A; ad-boost settings affect payout and statement context. Payout settings in Phase A.5 surface Stripe Connect, know-your-customer status, payout options and schedule, request fees, below-minimum payout rules, Value-Added Tax, the United Kingdom unique-taxpayer reference, the tax region, and readiness or blocking labels. Payout request controls are blocked or preview-only until Phase B funds exist; in Phase B, payout eligibility remains no earlier than thirty days after delivery. Designers export statements, review the statement archive, see payout transfers and failed-payout remediation, review reserves and disputes, the sale lifecycle and reserve ledger, dispute detail, and tax statement export. They handle action-queue items and messages, reply to reviews, answer questions, create candidates for the help-and-frequently-asked-questions pool, report problematic message threads, and submit typed claim actions such as approve replacement, refund instead, request more photos, or escalate.
Generating promotional media in Promo Studio is the designer-side studio for listing photography and video. A designer opens an owned listing in author mode and launches Promo Studio from the hero section. The studio has four steps: Stage, Photos, Video, and Library. Stage lets the designer pick an environment, optionally upload a custom high-dynamic-range reference, choose a lens, position the model with move-scale-rotate-yaw controls, adjust the camera rig, or reset. Photos accepts a prompt, appends listing tags, chooses a configured style, and starts a generation job; progress is shown and finished assets are tied back to the scene snapshot, prompt, style, job, and configuration version. The designer keeps, stars, downloads, adds to the listing gallery, or animates a photo. Video requires a generated photo first; the designer picks a source photo, writes a motion prompt, chooses duration and aspect, and starts a video job. The Library tab filters all generated media (photos, videos, starred), supports individual download, authorised download-all, archive and remove where enabled, animate-photo actions, and add-to-listing actions.
Workshop, Help, and admin content is editorial rather than user-generated. A reader opens the Docusaurus-published help and workshop site and searches or browses by category. The hub supports topic and navigation structure, article kinds, featured and popular slots, the article reader, related and backlink navigation where configured, and support entry points. Users can start a support conversation from help, an order, a listing, or an account. Article discussion (where enabled) supports comments, replies, likes, sorting, and reporting; these actions affect the DomiDo discussion records, not the published site. Admins use a content-management surface to create or edit article and topic metadata and body content, preview changes in a rendering that mirrors the public site, publish or unpublish, archive or delete where permitted, and see audit-ready status. Non-admins cannot modify article, topic, or kind content, even if they can post discussion comments.
Privacy and support runs through the footer and any account context. Users open the cookie-management panel from the footer, update preferences, and revise them later; the footer also links to privacy, terms, accessibility, the sitemap, and data-request flows. Support can be started from help, an order, a listing, an account, a return-fee challenge, or a trust-restriction challenge. Account lifecycle covers profile and avatar updates, session review, password and two-factor settings where applicable, data export requests, account or shop pause, and account-deletion requests with visible request status.
The journeys above describe what the system does. The journeys below describe what it feels like for each persona — diagnostic maps that show emotional valleys where users are most likely to abandon, moments of truth where a single interaction sets the direction, expectation gaps, service dependencies, and advocacy triggers. Every journey uses eight stages: awareness, exploration, design or selection, decision, purchase or pre-order, delivery or waiting, assembly and use, and post-build advocacy. Every journey identifies a peak moment (Kahneman's peak-end rule says people judge experiences by the emotional peak and the ending), an end moment, and a valley.
Geoff finds DomiDo through an editorial mention — a gardening section in the broadsheets or a feature on a Friday-evening gardening show. He is curious but immediately suspicious of anything "plastic-y". On the home page he wants prices and a plain "how it works" before anything else; jargon like "Mode A / Mode B" puts him off. In Mode B he expects a conversation rather than a form: he types something like "Georgian curved planter wall, warm stone colour, about a metre high", waits a beat too long if there is no progress indicator, and is delighted when the first preview is roughly right. His emotional valley arrives at the decision screen: spending the kit's price on something he cannot touch is a real psychological barrier. Trust signals are load-bearing here — close-up photos of a block with a coin for scale, weather rating, weight, returns policy, a United Kingdom phone number for support. PayPal must be a first-class checkout option. The delivery wait is dangerous; without proactive updates his mind fills with doubt. The assembly viewer must run on three-year-old hardware, must work in bright sunlight (an outdoor mode is non-negotiable), must save progress across days, and must keep step counts manageable for kneeling work. The peak is the moment he stands back and sees the finished structure in his garden; his end moment is neighbour admiration and his Facebook gardening group reacting. Design notes for Geoff: use British English (despatch, colour, free delivery), enforce a sixteen-pixel minimum body text in the assembly viewer, make "start a new design" more discoverable than "undo", and never hide the phone number.
Sophie enters from a styled Instagram reel. She evaluates DomiDo aesthetically before functionally: the gallery cards must be lifestyle photography (not bare renders), and the 3D viewer must run smoothly on iPhone or her perception of the entire brand drops. Her core experience is the design iteration loop. It must be conversational: the previous design stays on screen, an input below it asks "what would you change?", reference image uploads work at any step, and a version history lets her revert. The decision stage hinges on showing a partner — a one-tap "share preview" must produce a beautiful link card on iMessage with a clickable 3D embed, framed not as "Sophie's spending" but as "build it together this weekend". Apple Pay must be the primary checkout button. Packaging is content: matte boxes, paper bags rather than plastic, a printed card with referral code. The assembly viewer must accommodate one-hand iPhone use, a multi-person "build with a friend" pairing mode, screen-always-on for time-lapse filming, and haptic feedback on step completion. The peak is finishing at golden hour; the end is the Instagram post and the direct messages it generates.
Ben evaluates DomiDo through the lens of business: does it make him money and protect his reputation? He needs a dedicated trade landing page, found easily on a search engine, with margin calculators, trade testimonials with full names and business names, technical data sheets referencing relevant British and European Norm standards, and a free sample kit in trade-grade packaging delivered in days. Mode A must accept Computer-Aided Design file formats he already uses. The bill of materials must include ancillary materials and a realistic time range, exportable as a brandable client proposal. The decision moment is supply: he needs a firm delivery date, with a named account manager confirming by phone. Checkout must accept trade invoice terms, separate Value-Added Tax, and detailed delivery instructions. Delivery requires SMS tracking, a tail-lift, a packing list attached to pallet one, two percent overage on standard blocks, and a phone number that answers in under sixty seconds when something is wrong. The assembly viewer must be rigorously tested on Android, support section-based navigation so a crew can parallelise, include a "foreman view" of overall progress, and provide a single-page visual overview for experienced builders who do not want step-by-step handholding. The peak is the client's satisfaction combined with the realisation that he saved a day of labour at a better margin. The end is trade word-of-mouth in the builders' merchant yard — the highest-value advocacy DomiDo can generate.
Clare arrives from a design-community post. Her decision turns on the designer-programme page: concrete royalty terms, plain-language non-exclusive licence, public platform-status numbers, and real case studies. She needs technical documentation that includes example files, a clear "preparing your model" guide, and a real-time validator. The design iteration loop between her 3D modelling tool and the platform is the most critical workflow she has — a local Blender plugin that gives an approximate voxelisation preview would cut iteration time dramatically. The pricing calculator must be fully transparent (material, manufacturing, packaging, delivery estimate, platform margin, royalty visible as a waterfall) and let her experiment with royalty percentages. Her valley is the silent week after publishing — analytics need to show views and saves from day one, not just sales. First-sale notifications must be a celebration. Royalty payments must arrive on the first of the month without exception, with statements detailed enough for an accountant. Versioning of designs matters: a V2 should replace V1 but V1 customers must keep access. The peak is reaching consistent monthly royalty income; the end is being named a featured designer and seeing her collection promoted.
Emma operates under extreme time pressure. She discovers DomiDo at someone else's event and forms her first impression there — so every event installation matters as a lead-generation surface and should carry a discreet branded plaque. She needs an events page with portfolio segmentation, a quick-quote form with event-specific fields, and a response-time commitment. Design concepts must be presentation-quality renders dropable into a client deck. A Pantone-to-block colour matching guide with honest limitations is non-negotiable for brand activations. Technical documentation must include United Kingdom fire-safety certifications (such as BS EN 13501-1), structural load assessments, method statements, risk-assessment templates, and a public liability insurance certificate — packaged as an "event compliance pack". The quote must be turnkey: design, manufacturing, delivery, assembly crew, on-site standby, disassembly, and collection — one price, one invoice, one supplier. Delivery is premium-grade logistics with crew arriving fifteen minutes before stated time, a war-bag including spare blocks and touch-up pens, and crew in branded attire. Blocks must interlock firmly through a six-hour event but disassemble cleanly. Her peak is event night, when attendees queue to photograph the installation and her client sees measurable return on investment. The end is repeat booking. The big strategic insight is the event-block-library model where Emma buys blocks once and pays a design-only fee for reconfigurations.
Alex enters from a TikTok transformation video. He browses on a phone, and the entire experience must be phone-first. He is price-sensitive but willing to invest where he cares. Starter-sized designs at low price points reduce the activation barrier; clear cost-per-use framing helps justify the spend. His assembly is part of his content output: the viewer should support pairing with a partner, work with the screen always on, and let him film a time-lapse. His advocacy plays out on TikTok and Reddit, and a referral programme must be active from day one with trackable codes.
A handful of moments determine whether journeys succeed: the first preview after a prompt (Geoff's curiosity, Sophie's aesthetic judgement, Alex's TikTok-ready expectations all turn on what comes back from Mode B in the first sixty seconds), the decision screen (where trust signals — materials, weather rating, returns, support availability, social proof, payment-method familiarity — are load-bearing), the packaging (Sophie will film it, Geoff will judge it, Ben will show it to a client), the assembly viewer running outdoors (brightness, font size, low-power devices, gloved hands, multi-day pauses), and the completion moment (the peak of every journey — it must be celebrated with photo guides, share assets, designer credit, and referral codes).
Behind every front-stage interaction sits a backstage system: the pipeline, the inventory and reorder logic, the manufacturer integration, the third-party logistics provider, the moderation services, the customer-support workflow. The journeys above can only feel smooth if those backstage systems behave correctly — every "this must work" callout is, ultimately, a contract for one of those services.