My proposal gave Weeks 13–18 to prototyping and Weeks 19–24 to testing. At that point I was still working with a broad question about neurodiversity. As I narrowed it to autistic adults travelling independently through airports, the research continued into the summer. I collected ten written questionnaire responses in August and used the themes to decide what part of the journey I could investigate through design.
I chose the gate change because it brought several parts of the research into one situation. The traveller has to understand what changed, move through a terminal they may find difficult, and decide whether they want support. A single scenario gave me a way to compare ideas and see where one screen needed to lead to the next. Sketching began in Week 18, and I began the SwiftUI build in Week 20.
<aside>
Starting the build later meant I had less time to test. I protected the parts that answered my research question most directly: the new gate, the next step and the return to the route after ‘Not now’.
</aside>
I had wanted travellers to look up tomorrow’s flight, but the flight data I could access supported current-flight lookup. I kept that feature and used a fictional gate change to walk through the journey consistently. I developed the alternative route and staff-request screens as studies. The custom band stayed at concept stage while I tried the prompt with a Fitbit I already had. Ben’s advice to focus on the app helped me decide where to spend the time I had left.
I used the journal to record why I was working in a particular direction, the spreadsheet to keep the questionnaire responses beside their codes, and the build brief to turn a sequence of screens into something I could develop. Keeping the versions separate helped me see where the project had changed. It was easier to explain the difference between v0.3 and v0.4 once I could point to the unresolved return after the alert and the drawings I made to work it out.
I also had to decide what would be ready for a trial. With less time to test, I could use the sample scenario to keep the demonstration consistent and keep live flight lookup as its own working feature. I moved the solo gate-change task to the next phase because that question needed a session of its own.
I would make a rough interactive gate change earlier, while I was still exploring the visual design. In v0.3 I could show the alert, but I had yet to work out what someone saw after declining support. Making that transition interactive earlier would give me time to observe someone using it and revise it before refining the visuals.
Studio Practice Draft 4, pp. 40–43 and 61–62 · GDE751: Week 21: What I Kept in the Prototype and What I Set Aside.