Question. How will the research and design studies become a working prototype, and how will I record what actually changed?
This chapter follows the coding research because implementation should be driven by the requirements and evidence already stated. At present the project has hand drawings and system sketches, visual studies in SVG/HTML, a full static app board, original mascot and icon experiments, and a written iOS build brief. It does not yet have a buildable iOS app or a recorded participant evaluation of the current design. I will use this page to document the transition when those things happen, rather than writing it as though they already have.
The Week 18 sketches define the journey and branching support. The design chapters define a provisional voice, palette, type criteria, mascot, alert hierarchy and app appearance. The local Studio Practice App Architecture and Build Brief translates these into screen/state requirements and warns where data is fictional or unverified. The first coded use case is a fictional BA256 gate change from B12 to A04. It is deep enough to test information order, dismissal, route steps and state return before adding every airport stage.
Sketch 2 — Airport gate-change scenario
This early gate-change storyboard is the interaction source for the first coded case. Its airport locations and steps remain illustrative.
The project combines hand-drawn sketching, Procreate, Adobe tools and assistive AI. I use drawings and visual software to explore the form and make assets; AI can help turn a precise, human-reviewed brief into code drafts, explain APIs, suggest alternatives and find implementation mistakes. It is an assistant in the workflow, not evidence that a design decision is right. I keep responsibility for the brief, what is accepted, the visual judgement and the accuracy of the Studio Practice record.
A useful request to the coding assistant would include the screen/state table, the B12→A04 example, the exact sample/live labels, the optional support branches and the conditions under which a claim is allowed. For example: “Implement the sample gate-change flow in SwiftUI. Show A04 as current, B12 as previous, and the data as sample. Place the support invitation after the facts. Make ‘Not now’ retain journey state. Do not add a live API, distress detection or an automatic support trigger.” I would review the resulting code against the brief and change it where it invents data or hides a requirement. Code generation is a starting draft, not a substitute for running and checking the app.
For each build iteration: date/version; question being tested; source sketch or research requirement; screenshot/video of the actual running view; implementation change; technical result; participant feedback if obtained; what changed next; and remaining limitation. Keep a distinction between planned, implemented, technically checked and reviewed with users. Do not convert one into another in the write-up. If there is no live airport feed, the screenshot must say “sample.” If a route is illustrative, its label must say so.
The technical build may change the static design. For instance, a gate ticket may need a simpler shape to survive Dynamic Type; an icon detail may disappear at small size; a motion idea may be removed if it adds no information. Those are design decisions to explain through evidence and comparison, not deviations to conceal.