Addressing equity barriers with inclusive service design

• Problem Discovery - understanding the RAPs service
• Key Decisions - the choices that shaped the work
• Insights & Outcomes - what the research revealed

Reasonable Adjustment Plans help students access equitable support during their study. The existing service depended on manual steps, paper-based medical processes, repeated information capture and disconnected systems.

Students could be required to provide the same information multiple times, staff needed to coordinate across several systems, and teaching staff needed clearer access to relevant adjustment information. These issues created delay, administrative load and avoidable friction for people already navigating complex circumstances.

The service needed a clearer end-to-end model: one that supported early self-identification, reduced unnecessary repetition, improved information sharing and created a practical roadmap for accessibility and systems integration.

My role

I led service discovery and design activities across the RAPs experience. This included stakeholder engagement, journey mapping, user-story ideation, prioritisation workshops and future-state service flow design. I worked with accessibility and student service stakeholders, technical teams and business SMEs to identify opportunities, estimate complexity and prioritise user stories by value and feasibility.

Map the service before redesigning the interface

The visible student experience was only one part of the problem. The service also involved staff actions, system dependencies, documentation, notifications and access-control decisions. I started by mapping front-stage and back-stage actors, service episodes and high-level user stories so that the team could see the service as an ecosystem rather than a sequence of screens. The future-state design addressed operational dependencies, not only student-facing interface improvements.

Prioritise user stories by complexity and value

Workshop participants generated 109 user stories for the future-state RAP system. Technical SMEs rated build complexity and business SMEs rated user value using T-shirt sizing. This created a shared prioritisation model that separated quick wins, high-value opportunities, feasibility questions and lower-priority work. The team moved from a large set of needs to a practical roadmap for deciding what should be investigated, prioritised or deferred.

Focus on integration, automation and flexibility

User-story voting highlighted recurring needs around system integration, automated workflows and flexibility for business process change. Instead of treating these as separate feature requests, I reframed them as service principles: reduce manual coordination, connect the right systems, and design enough flexibility for the service to evolve without repeated technical dependency. The proposed future state gave equal attention to student access and operational sustainability.

Treat accessibility compliance as a service requirement, not a final check

One of the explicit needs identified was that the system comply with Web Content Accessibility Guidelines so students could access content. I positioned accessibility as part of the roadmap and service model, rather than an implementation task to be handled after design. Accessibility compliance became part of defining the right service, not only validating the final interface.

What the research and workshops revealed

• Paper-based medical processes created avoidable barriers and should be digitised where possible
• Students with ongoing conditions needed renewal and rollover pathways that avoided unnecessary practitioner reports where permitted
• Early disability registration should initiate RAP workflows instead of relying on students to know the process
• RAP information needed to be visible in the right systems for students, accessibility staff and teaching staff
• Staff needed stronger interoperability across systems such as student records, learning platforms, document management and booking tools
• Future-state workflows needed clear next steps when full re-platforming was not yet possible

What changed

• Created a prioritised future-state backlog from 109 user stories
• Identified six service improvement themes across manual barriers, automation, interoperability, accessibility and relationship continuity
• Mapped end-to-end actors, episodes and high-level user stories
• Designed future-state flows for request submission, review, communication and support pathways
• Created a clearer evidence base for investing in integrated and automated workflows

Reflection

The most important lesson from this project was that accessibility services need to be designed as relationships, not transactions. Students should not need to understand internal systems or repeat sensitive information to receive support.

If I approached this work again, I would push for earlier prototype testing with students and staff across the most critical service moments: registration, access and execution. The workshop prioritisation showed these were the areas most worth investigating next.