How could a community organisation make a booking service easier to use on an older phone or a slow connection?
The academic starting point
Students bring together programming, information design and human-centred research. They examine keyboard access, plain language, privacy and the limits of their initial assumptions.
The industry or community challenge
A representative brief sets a modest scope: understand one booking journey, identify barriers and test an alternative. Any future external organisation would agree consent, responsibilities and review arrangements before participation.
The departmental enterprise connection
The Software & Intelligent Systems Studio could turn the learning into a supervised accessibility review and prototype service. Academic assessment would examine the reasoning and evidence behind the work.
Inside the work
Listen before building
Map the journey with representative users where participation is approved. Record access needs without collecting unnecessary personal information.
Make a small, testable version
Prototype the essential task, write clear labels and build keyboard and small-screen support into the first version.
Test the assumptions
Observe task completion, inspect errors and review accessibility. Explain the limits of the sample and prioritise improvements.
Make the work transferable
Prepare a handover with design decisions, a test record and a realistic maintenance plan.
What a team could produce
- A service journey and problem brief
- An accessible working prototype
- A usability and accessibility test record
- A reflective account and handover guide
The learning happens when the team can explain why a simpler interaction works better—and identify the people for whom it still needs improvement.
