The Disability Support Service exists to remove barriers. Their registration form was quietly creating them.This is the story of how a backend migration task became an accessibility-first UX transformation and what I learned about designing for the people who need it most.
I was assigned to a backend migration project at the University of Limerick, updating how student data was referenced across the Student Portal. My module was Disability at the time. The plan was simple: update the address references accross the system, log it as done and move on.
But when I sat down with the Disability Support Service team, I started asking questions. And what I found was a registration process that had been quietly failing the students who depended on it most.
What followed was a ground-up redesign, built on user interviews, accessibility principles, and a genuine belief that the people navigating this form deserved better.
DSS at UL serves one of the most diverse disability cohorts in Irish higher education. When mapped against national HEA benchmarks, the scale of who depended on this registration flow became impossible to ignore.
My original brief was narrow: update how student addresses were referenced in the backend. But before touching any code, I sat down with the DSS team and those conversations changed everything..
"Students would submit the registration form, receive a confirmation email, and go quiet. Days would pass. Then they'd follow up confused, sometimes frustrated having heard nothing. DSS would have to walk them back through the process manually, explaining that submission was only the beginning."
The students weren't being careless. The system was misleading them.
I pulled up the confirmation email they received after submitting.
It read: "This e-mail is to confirm that you have successfully applied for registration with the Disability Support Services."
"Successfully applied." For students already navigating the stress of disclosing a disability and asking for help, often for the first time, those two words landed as: you're done. The email offered no next steps, no timeline, no indication that DSS would need anything further from them. It closed a loop that hadn't actually closed.
This was the moment the project shifted for me. What I was looking at wasn't a backend problem. It was a communication failure: one that was falling hardest on the students who could least afford to fall through the gaps.
I widened my audit. If the confirmation email had gotten this so wrong, what else had been left unexamined?
The research pointed to one root cause: the system had never been designed with its actual users in mind.
Students with disabilities were navigating an outdated, inaccessible form that created confusion, incomplete submissions, and most importantly, a false sense of completion. How might we redesign this experience so that every student, regardless of ability, could register with clarity and confidence?
Collect only what is necessary. Every extra field is a question the student must answer and a reason to abandon.
Never let a student wonder what happens next. The confirmation screen is not the end of the process, it should say so.
If it works for a screen reader user, it works for everyone. Accessibility is not a constraint it is the baseline.
Every word in the form is a UX decision. Plain language is not simplification, it is precision aimed at the reader.
The research had given us a clear brief: reduce friction, set honest expectations, and design for the student who finds this hardest. Not the one who finds it easiest. Every decision below traces back to something we found in the field.
Added a landing screen before the form begins — setting expectations, explaining purpose, and reducing the anxiety of not knowing what's ahead. For students with disabilities, ambiguity is a real barrier.
The old welcome screen opened with three things: a purpose statement, a list of requirements, and a warning. We stripped it back to one sentence. The requirements were moved to the appropriate moment in the journey, not front-loaded onto a student before they'd even begun.
We stripped the form to only what DSS actually uses. One field is mandatory: disability type. Everything else is optional or removed entirely, including the address field that triggered this whole project.
Every instruction, label, and prompt was rewritten in plain English. Short sentences. Active voice. No clinical terminology unless absolutely necessary — and when used, explained immediately.
We replaced the full-page error redirect with inline validation. Each error message names the specific field and gives a clear instruction for fixing it. The entire flow was tested with keyboard-only navigation and a screen reader before launch.
Introduced an automated confirmation email containing a summary of submitted information, clearly outlined next steps, and links to additional DSS resources. Closes the loop the old form left open.
This was the root cause of the expectations gap — not a broken flow, not a missing screen, but two phrases that described the wrong thing. The fix wasn't a redesign. It was honesty.
The redesigned form reduced fields from 22 to 6, a 73% reduction. Average completion time dropped by 30%. Across a student body of 18,000, served through 20+ departments, the cumulative effect of that reduction is significant.
But the metric I keep coming back to isn't on a dashboard.
After launch, the DSS team told me that students were arriving to their first appointment differently. They'd read the email. They knew what to expect. The back-and-forth, the follow-up calls, the manual re-explanations, the students who'd waited weeks not knowing they were supposed to do something had dropped noticeably.
That was the real measure of success. Not that the form was shorter. But that the system was finally telling the truth about what it was asking students to do.
The most impactful change in this project wasn't a redesigned screen. It wasn't the field reduction, the progress indicator, or the error handling. It was changing "successfully applied" to "started an application" and adding the words "next steps" to a single sentence.
That's it. Two phrases, across a change that took less than an hour to implement, that had been quietly failing students for however long that email had existed.
I hadn't thought of UX writing as design before this project. I do now. Every word in a system is a decision and an undecided word doesn't stay neutral, it defaults to whatever the system finds easiest to say. In this case, that was "successfully applied." Technically accurate. Practically misleading. The gap between those two things is where the confusion lived.
Being a developer on this project meant I could move fast. I understood the system constraints before anyone explained them. I earned engineering trust early. I shipped without handoff friction. Those things mattered.
But I came to this project without formal UX training, which meant some things I should have done, I didn't think to do.
I interviewed DSS staff. I didn't interview students. The people who filled out the old form, the ones who waited weeks not knowing they were supposed to do something, I never spoke to them directly. I made design decisions on their behalf based on what staff told me, which is better than nothing, but it isn't the same thing. If I were doing this project again, I would find two or three students willing to walk me through their registration experience before I touched a single field. Their version of the story might have surprised me.
I came into this project as a developer who was curious about UX. I left it understanding something I hadn't expected: that the most valuable thing a designer can do isn't always to add something. Sometimes it's to remove a warning, shorten a sentence, or delete sixteen form fields that nobody needed in the first place.
The students who used the old DSS registration flow weren't failing. The system was asking them to navigate something that hadn't been designed with them in mind. Fixing that didn't require new technology, a bigger budget, or a platform migration.
It required someone to stop and ask: does this actually work for the people using it?