I wanted to begin developing the main Studio Practice document and the technology mock-ups, but I was unsure whether to design the app, the wearable biosensors or the headphones first. I collected visual references of polished app presentations alongside rough sketches and wireframes. The finished app imagery appealed to me because it made a digital product feel coherent and tangible; the wireframe examples were useful because they showed the decisions that had been made before the final visual design.
I realised that if I went straight into rendering three attractive devices, I might create the appearance of a complete product without showing how the parts work together. I therefore decided to work in black and white, keeping the drawings exploratory rather than making decisions about branding, colour or final interface styling too early.
Sketch 1 — System ecosystem
The first drawing places the mobile app, wrist-worn biosensor, bone-conduction headphones and traveller in one communication diagram. I wanted to see the relationship between the components as a loop rather than three separate products. The wearable could send physiological and movement measurements to the app; the app could combine these with user preferences and available journey information; and the headphones could provide audio support chosen by the traveller. Manual access and the ability to pause or stop support remain important.
I also refined the physical references. For the wrist sensor, I am interested in a discreet, band-like form rather than a conventional smartwatch. For audio, my reference is an open-ear, Shokz-style bone-conduction form, rather than an immersive headset. I am exploring this because it may leave the ear canal unobstructed, although individual comfort and awareness of airport sounds cannot be assumed.
This sketch helps establish a proposed interaction architecture. It does not establish that sensor interpretation, airport-data integration or communication between all three products has been implemented or validated.
Sketch 2 — Airport gate-change scenario
My second drawing tests the proposed experience through a simple six-frame scenario. A traveller is in the airport when a gate changes from B12 to A04. The environment becomes busy, and they access the app, see an offer of support and choose between practical responses, such as finding the next step, looking for a quieter route or taking time to ground themselves.
I chose this example because it combines unexpected information, navigation and a potentially demanding environment—issues that connect with the research themes of unpredictability, changing support needs and autonomy. It also made the design question more concrete: what is the traveller being asked to do at each moment, and does the proposed system reduce or add to their workload?
The gate change is a conceptual scenario, not evidence that it is the final accessibility problem or that the user would necessarily need support in this situation.
Sketch 3 — Six-screen app wireframes
I translated the storyboard into a sequence of app screens: start journey → gate change → optional support prompt → support options → active support → route guidance. This was my first attempt to show the information hierarchy and the decisions the traveller would actually make, rather than only describing what the app might contain.
I deliberately included a way to reach support manually from the home screen, a “Not now” option, and pause/stop controls during support. These are not secondary details. My research has repeatedly raised the importance of independence as choice and control, so I want that principle to be visible in the interaction rather than only stated in the report.
This sketch also exposed a gap in the logic: a gate-change alert is not the same thing as a biosensing-led prompt. The app would need to distinguish information about a flight from a cautious suggestion based on physiological change. A sensor reading cannot tell the system that someone is experiencing sensory overload.
Sketch 4 — Branching support flow