If user stories tell you what the system must let people do, and journeys tell you how it feels to do them, this page tells you what is actually happening at every step. It is a hierarchical task analysis: a systematic decomposition of every important task in DomiDo into its constituent subtasks and operations, with time estimates, error-probability estimates, cognitive-load ratings, failure modes, and recovery paths. This is the working document used by interaction designers to map task structure onto screen states and transitions, by engineers to set latency budgets, and by quality assurance to identify the steps where defensive design and validation matter most. Where a step is rated cognitively high, the system must not stack avoidable wait-time on top; where error probability is high, the design must protect against that error proactively.
Each task is decomposed in the hierarchical-task-analysis notation developed by Annett and Duncan. Time estimates are derived from a Card-Moran-Newell-style breakdown adapted for mobile touch interaction — a tap takes roughly three-tenths of a second, a swipe roughly half a second, text entry roughly a quarter of a second per character on a mobile keyboard, a moderate cognitive evaluation between one and three seconds depending on complexity, and the wait time for a server response depends on the back-end's published targets. Human error probability is drawn from human-reliability methodology (Swain and Guttmann) adapted for mobile contexts. Cognitive load is rated on a five-point scale: automatic motor action (one), simple binary choice (two), moderate evaluation requiring reading and comprehension (three), high spatial or unfamiliar-paradigm reasoning (four), and very-high expert-level multi-stream management (five). Network and device assumptions are roughly fifty megabits per second of broadband or strong 4G in the United Kingdom primary market, a mid-range device like an iPhone 12 or Pixel 6, and a novice user encountering the task for the first or second time, with experienced timings called out separately. System response times use the ninety-fifth-percentile latency targets from the engineering specification.
Ten tasks form the analytical core. Five are essential consumer flows; one is a designer-facing flow; two are operator-facing flows; two cover gallery and pre-order behaviour. Together they cover every significant action a user performs.
The most technically complex user-facing task, performed primarily by Clare (an expert 3D designer with files ready), Ben (a tradesperson receiving files from clients or architects), and Sophie (downloading models from public 3D-model libraries). The task decomposes into seven major subtasks: initiate the upload, validate the file, upload to the server, configure processing options, monitor the pipeline, review the completed design, and save the design.
Initiation involves navigating to the upload entry point, opening a file picker, browsing to and selecting a file, and confirming. Cognitive load is low to moderate; total time is two to fifteen seconds depending on file location. Validation runs in parallel on the front end (extension check, size check, then a single combined result), and errors return the user to file selection with a clear corrective message; the error probability is meaningful for first-time users who guess at supported formats, so the design protects against this by showing supported formats on the file picker itself. Upload to the server happens via a presigned URL — the front end requests the URL from the back end, uploads directly to object storage, and shows a progress bar — and the error probability is dominated by network failures, so the design uses exponential-backoff retry up to three attempts and then prompts a connection check. Processing-option configuration shows a quick preview of the uploaded model, lets the user choose a quality tier (fast under thirty seconds, balanced, or best under ninety seconds), optionally adjust scale, and confirm; this is a moderate cognitive load because users have to evaluate a trade-off they cannot fully grasp without a visual reference, so the design uses plain-language tier descriptions ("Faster" vs "Better quality") rather than internal solver names.
Pipeline monitoring is the longest step. The front end opens a Server-Sent Events connection and walks through twelve stages — import, repair, voxelise, align, custom voxels, blockify, interfaces, features, stock-keeping-unit assignment, validate, assembly, export — with human-readable stage labels and animated progress; each stage has its own latency target, and if any stage fails the user sees a stage-specific message and the failure mode dictates whether retry or input modification is appropriate. Reviewing the completed design opens the 3D viewer, side-by-side comparison with the source model, statistics (block count, weight, dimensions), bill-of-materials summary, and a preview of the first few assembly steps; cognitive load is high here because the user is evaluating an unfamiliar artefact (their model translated into blocks) and deciding whether to accept it, and the design must make the comparison legible and the iteration path obvious. Saving auto-persists the design to the user's library, an optional name can be added, and the user proceeds to checkout or continues browsing. Total time for the task is roughly thirty to ninety seconds of active interaction plus the pipeline wait, and total cognitive load peaks in the review step.
Performed mostly by Sophie (who works from references and prompts) and Alex (who arrives without 3D files). This task is the most novel — most users have never iterated a 3D design through projections. The decomposition is to enter the prompt, generate and review the frontal projection, iterate through the remaining seven projections, generate the 3D model from the eight projections, review and either accept or iterate, and convert to blocks (entering the Mode A pipeline at stage three). Prompt entry is moderate cognitive load because composing a prompt that produces a usable output requires practice; the design supports this with prompt templates ("Try: Georgian curved planter wall, warm stone colour"), a gallery of example prompts and their results, and optional reference-image upload. Iteration is conversational: the previous design remains on screen, the input asks "what would you change?", and version history lets users revert.
Projection generation has its own wait per projection — up to fifteen to ninety seconds depending on the provider — and during the wait the design uses a "thinking shimmer" animation on the current 3D model rather than a blank loading screen. Each projection can be regenerated unlimited times without additional credit cost; credits are charged at initial generation. Three-dimensional model generation sends all eight projections to a model provider (Hunyuan as default, with Meshy, Tripo, and a self-hosted alternative available); the user picks the provider on cost-versus-quality grounds, and the design exposes those trade-offs in plain language. On failure, projections are saved and credits refunded for the failed step. Conversion to blocks re-uses the Mode A pipeline from stage three onwards (the uploaded model is replaced by the AI-generated GLB), and the completion path is the same as Task 1.
Performed in every task that involves viewing a design — Mode A review, Mode B preview, gallery design detail, and assembly. Cognitive load is high for novices and low for experienced users, and this is the task where the gap between Alex and Geoff is most visible. The decomposition: orbit the model with single-finger drag, zoom with pinch, pan with two-finger drag, snap to standard views (front, back, left, right, top), reset to fit screen, toggle view modes (assembly, source model, blocks, fasteners, ghost, exploded), and toggle step-by-step navigation in assembly mode. Critical design notes from the analysis: orbit speed must be consistent (no non-linear acceleration); snap-to-axis buttons must be available alongside free orbit; a "fit to screen" reset must always be one tap away; gesture disambiguation must be tested with small screens and gloved hands. The implementation uses OrbitControls from the React Three Fiber drei library with damping enabled for momentum and tuned rotation speed.
Performed by every paying user. Cognitive load is moderate for the address and shipping selection step and low for the actual payment step (Stripe handles it). The decomposition is to review the cart, tap Pay, be redirected to Stripe's hosted page, complete card or wallet-based payment, and return to the confirmation page. The design's role here is mostly not doing things — by handing card collection to Stripe Checkout, DomiDo avoids the regulatory scope of handling card data and benefits from Stripe's extensively tested error handling for declines, strong-customer-authentication challenges, and address validation. The design's responsibilities are visible payment methods (Apple Pay prominent on iOS, PayPal at the top for older personas), guest checkout with optional post-payment account creation, and a confirmation page that is screenshot-worthy.
Performed in every persona's exploration stage. Cognitive load varies by search modality: text search is low, voice search is moderate (because voice transcription is novel and users have to formulate spoken queries), image search is moderate (because users have to understand what "similar to this" means in this context). The decomposition is to open the gallery, apply filters (category, dimension class, block count range, designer), choose a sort order (trending, most purchased, newest, staff picks), scroll through results, tap into a design, view the detail page, like or save, share, or tap "Buy This Kit". The design must support all three search modalities with explicit latency budgets — under two seconds for text, under five seconds for voice including transcription, under three seconds for image — and must show empty states and zero-results states with constructive suggestions rather than dead ends.
Performed by Clare (the marketplace designer) and occasionally by Sophie and Alex as social acts. Cognitive load is high — the user is making decisions about visibility, royalty, pricing, and presentation simultaneously. The decomposition is to open the publish wizard, choose visibility (private, unlisted, public), set the royalty percentage between zero and twenty-five, choose pricing tier, upload preview images and lifestyle renders, enter title and description, add tags from suggestions, review the gallery preview, and confirm. For Clare specifically, the analysis identifies the moderation pipeline as a critical service: she has invested creative labour and emotional energy in the design, and any moderation false-positive must be handled with care, so the design surfaces the moderation result quickly and provides a clear appeal path.
Performed by buyers in the Phase B flow (and modelled in advance during Phase A). Cognitive load is moderate — the user is often frustrated, must select a reason from a short list, and must wait for label generation. The decomposition is to navigate from "My Orders" to a specific order, tap "Request Return", select a reason, confirm, wait for the prepaid label, print or save the label, ship the parcel, and track the return through inspection and grading to refund. The design's role is a single visible "Request Return" entry point on every eligible order, a four-option reason list (change of mind, defective, wrong items, damaged in transit), a transparent grading table so the buyer understands in advance how the inspection will translate to a refund, and a dispute path with photo evidence if the buyer disagrees with the grade.
Performed by Phase A buyers. Cognitive load is moderate — most users have not encountered a no-charge pre-order before and need to understand what is happening to their card. The decomposition is to navigate from a design to the pre-order call-to-action, read the non-binding language, tap "Pre-order — Ships [estimated month]", be redirected to Stripe Checkout in setup mode, complete card verification, return to the confirmation page, and receive the confirmation email. The design must use unambiguous language at every step: the call-to-action makes the estimated ship month explicit; the confirmation email is explicit that the card will be charged only when the kit ships; the dashboard explicitly distinguishes pre-orders from orders.
Performed by the operations or engineering team. Cognitive load is very high — the admin is managing multiple data streams (per-stage success rates, latency percentiles, queue depth, worker health) and triaging anomalies under time pressure. The decomposition is to open the pipeline-monitor surface, review rolling success rates, review per-stage latency percentiles (fiftieth, ninety-fifth, ninety-ninth), review failure breakdown by stage and error type, drill into specific failed jobs to see logs (last hundred lines from the log aggregator), retry failed jobs, or pause and resume the queue if needed. The design's role is real-time updates via Server-Sent Events for critical alerts, a thirty-second auto-refresh for routine data, and deep-links to richer dashboards.
Performed by the operations team in Phase B. Cognitive load is very high — the admin is grading a physical return against a policy matrix, photographing damage, deciding refund percentage, and capturing an audit trail. The decomposition is to receive the inbound parcel notification from the third-party logistics provider, open the corresponding return record in the admin, inspect the kit against the original bill of materials, photograph any damage, assign a grade (A through D), record inspection notes, trigger the Stripe refund for the corresponding percentage, update inventory (full re-entry, partial re-entry, or write-off), and notify the customer. The design's role is a clear grading rubric visible during inspection, photo-upload directly into the return record, automatic refund calculation from the grade, and an automatic notification to the customer when the grade is set.
Several patterns recur across tasks. The most cognitively expensive step is rarely the one that consumes the most time — pipeline waits are long but cognitively cheap, design review and prompt formulation are short but cognitively expensive — so the design must protect cognitively expensive steps from avoidable distraction. Failure recovery is where the design earns trust: every task above includes failure paths, and the system that recovers gracefully (clear message, single corrective action, retained state) earns trust the next time the user encounters a similar issue. Outdoor and stressed contexts amplify everything — Geoff in his garden in bright sunlight, Ben on a client site with a crew waiting, Emma at a venue load-in are all operating under physical or temporal stress, and designs tested only in office conditions will fail in those contexts. Server-Sent Events plus a polling fallback is the right pattern for long-running processes: every task that involves a wait (Mode A pipeline, Mode B generation, return shipment tracking, admin pipeline monitoring) benefits from real-time push with a polling fallback when the connection drops.
A simple cognitive-load rule applies across every user-facing task: total cognitive load summed across steps should not exceed roughly fifteen on the five-point scale before the user is given a break (a confirmation, a save, a return to navigation). Tasks that exceed this budget — the artificial-intelligence projection iteration loop in particular — must be broken into checkpoints with clear "you can stop here" points.
The headline design recommendations drawn from these analyses: use plain-language stage labels everywhere and never internal codes; keep the assembly viewer step count below eighty steps wherever possible and, for designs that exceed this, split into sub-assemblies and surface that fact; provide pre-formatted share assets (Open Graph cards, story templates) for every persona's natural sharing moment; for older personas surface a phone number on every page, and for younger personas surface in-application chat; for trades expose section-based navigation in the assembly viewer so a crew can parallelise, and expose a foreman view; for designers expose analytics from day one and provide a Blender plugin for approximate local voxelisation preview; for events and trade, package compliance documentation (fire rating, structural load, method statement, public-liability insurance) as a single download — the event compliance pack.