DDES9902 Chap.7 Design Pipelines and Iteration
Design Pipelines and Iteration
Immersive projects combine interaction design, art, programming, sound, research, technical direction and production. A useful pipeline defines how decisions cross those roles and how evidence can reopen them. The course contrasts iterative creative work with a one-way waterfall: teams frame an uncertainty, build the minimum testable experience, gather comparable evidence and use the result to revise the problem or solution.
Iteration still needs planning, version control and responsibility. Safety, consent and submission constraints can be fixed early while interaction details remain open to testing. An effective pipeline starts with an assumption ledger rather than a catalogue of desired features. Rank assumptions by consequence and uncertainty, then create a short sprint whose prototype can expose the highest-risk one.
The resulting artefact may be visually rough if sequence, discoverability or comfort is the real question. Hand-offs should carry behaviour states, constraints and failure cases as well as images or assets. A gesture animation, for example, needs trigger conditions, feedback, accessibility alternatives and a performance budget before development can implement it consistently.
Version control must connect the playable build, test notes, report images and demonstration footage. If those surfaces show different versions, the report should identify the difference and decide whether earlier evidence still applies. Review meetings close with a recorded choice to accept, revise or stop, plus the accountable person and affected roles.
This structure keeps iteration open to learning without making responsibility vague. It also prevents late polish from consuming time needed to retest safety, access or interaction changes on the same build that will be submitted.
What this chapter covers
- 01
Specialist roles in immersive production teams
- 02
Decision hand-offs across design, art, development and research
- 03
Iteration as evidence changing the next version
- 04
Anti-waterfall creative cycles with disciplined planning
- 05
Minimum testable artefacts and risk-focused sprints
- 06
Version history, ownership and review decisions
Worked example · free
Plan a locomotion learning sprint
- +1Define the uncertainty as comfortable and oriented route completion by first-time users.
- +1Build only the route, landmarks, teleportation, snap turns and safety boundary within a performance budget.
- +1Record completion, wrong turns, setting changes, comfort stops and requests for help.
- +1Use the review to select the next locomotion mode and record unresolved access requirements.
Key terms
- Design pipeline
- The connected roles, artefacts and decision points through which an immersive project is developed.
- Iteration
- A change to a design or problem frame made in response to evidence, requirements or constraints.
- Waterfall process
- A predominantly sequential process in which stages are completed before work passes forward.
- Sprint
- A short bounded work period organised around a deliverable, question or decision.
- Decision hand-off
- The transfer of design intent, constraints, evidence and authority between project roles.
- Version history
- A record that identifies successive artefacts and the reasoning behind meaningful changes.
Design Pipelines and Iteration FAQ
Why does the course describe the creative cycle as anti-waterfall?
Important information appears during making and user testing, so a fixed one-way sequence can preserve a weak concept. The alternative is not disorder. Teams plan short evidence loops, keep constraints visible and let observations change priorities, interactions or the problem frame.
What should an interaction hand-off include?
Provide trigger conditions, states, timing, feedback, failure behaviour, accessibility alternatives and technical limits. Name the design question and evidence behind the decision. A visual mock-up or animation without those details cannot tell development how the interaction should behave under edge conditions.
How do I prove that a sprint produced learning?
State the uncertainty at the start, identify the tested artefact and method, present the observation and record the decision at review. A sprint that creates assets but cannot say what was learned may still be production work, but it is not a complete iteration cycle.
Assessment move
Map your project as a network of decisions rather than a list of job titles. For every hand-off, note the artefact, required context, person with approval authority and evidence that could reopen the choice. Plan a small sprint around the assumption most likely to invalidate the experience. Exclude tasks that cannot affect that decision, even if they make the prototype look more complete.
At review, choose among accepting, revising or stopping and write the reason. Compare agile language with actual behaviour: frequent meetings and releases do not constitute iteration unless evidence changes the work. Preserve version identifiers in reports, videos and links.
A clear pipeline narrative should show how specialists coordinated, how constraints were handled and how learning moved the design, not merely who completed each asset.
