Case Study
A process students
didn't know existed,
redesigned from scratch.
Designing Unity Environmental University's first student-facing ADA Accommodations workflow — replacing a paper-and-email process no one could find with a single-screen digital experience integrated with Salesforce, Adobe Sign, and FERPA compliance.
01 — The Problem
A process hidden
behind paper and people.
Students with disabilities at Unity Environmental University had a legal right to request academic accommodations under the ADA. But the process for doing so was so invisible and so friction-heavy that many students either didn't know it existed or gave up and routed through their advisors instead — which wasn't their job.
There was no student-facing digital workflow. The Student Portal had a vaguely-labeled "Support" page with Salesforce "cases" that loosely captured some of this — but nothing resembling a guided process. In practice, requesting accommodations meant: finding the right form, printing it, signing it, scanning it, emailing it — and then waiting while your healthcare provider went through the same paper ritual on their end. Privacy was nominally protected by keeping everything offline. The cost was access.
"The old process protected student privacy by making the process nearly impossible to complete."
Before
- No student-facing digital process existed
- Students didn't know where to go or that the process existed
- Paper forms — print, sign, scan, email
- Healthcare providers required to do the same
- Students routed through advisors as informal workaround
- No status visibility — students waited with no feedback
- Vague "Support" page with unlabeled Salesforce cases
After
- Single-screen student-facing ADA workflow
- Clearly surfaced on new Student Support page
- Digital request form with guided submission
- Adobe Sign integration — healthcare provider signs digitally
- FERPA-compliant throughout — privacy protected in code
- Real-time toast notifications as status changes
- Appointment scheduling with ADA advisor built in
in the new flow
stages live
in new process
SF · Sign · FERPA
02 — Strategic Context
One feature at a time.
One portal at a time.
This project didn't happen in isolation. It was the first feature rollout of a larger, deliberately staged Student Portal redesign — a strategic approach I developed to manage risk and build organizational trust in the new portal before wholesale replacement of the old one.
The new Student Portal was fully designed but not yet deployed. Rather than waiting for the entire portal to be complete before going live, I designed a deployment strategy: ship features one at a time, pulling related infrastructure with each one. The ADA Accommodations feature was the first, bringing with it the new Student Support page — which consolidated several previously scattered functions and retired a vaguely-defined "Student Success" screen in the process.
Strategic Framing
The Student Support page was intentionally designed as more than a container for ADA. It would also house Mental Health & Crisis Support resources, student Goals, and Assessments — functions that previously existed loosely or not at all. ADA was chosen as the first rollout because it had the clearest compliance driver, the most defined stakeholder (the ADA coordinator), and the highest student impact if left in its current state.
Each feature rollout also brought shared infrastructure with it. The toast notification system — visual cues that surface behind-the-scenes Salesforce actions to the student — was designed as a portal-wide pattern, but first deployed here. Students see a toast when their request is received, when their provider submits documentation, and when a decision is made on their case. None of that was visible before.
03 — Discovery & Process
Best case first.
Then reality-check it.
The design process for this feature followed a deliberate sequence — one that prioritized ambition before constraint. I've found that starting from what's technically possible tends to produce solutions anchored in what already exists. Starting from what's ideal produces solutions anchored in what users actually need. The constraints come in later, and they're more useful that way.
Map the current process
Documented the existing paper-and-email workflow end to end — all parties, all steps, all handoffs. Made the invisible visible before redesigning anything.
Technical feasibility conversation with Salesforce developers
Before designing anything, talked with the development team about what integrations were possible now vs. later. Understood the Adobe Sign integration potential and the FERPA compliance requirements early — so the design could work with those constraints, not against them.
Best-case-scenario first pass
Designed the ideal flow assuming all desired integrations were in place. This isn't naïveté — it's a deliberate technique for surfacing what the experience should feel like before negotiating what's achievable. The first pass became the artifact that drove all subsequent conversations.
1-on-1 workshop with the ADA coordinator
Walked through the wireframes step by step with the person who handles all ADA cases. This wasn't a presentation — it was a working session. Every step generated notes, corrections, and insights that only come from the person who lives inside the process. What students need, what the coordinator needs, what the healthcare provider needs, and where friction hides at each handoff.
Revised flow → development specification
The workshop output became the specification for the Salesforce developers — including the Adobe Sign integration requirements and the FERPA-compliant data handling approach. The wireframes weren't just design artifacts; they were the communication tool that got what was needed out of the technical team.
High-fidelity flow and handoff documentation
Built the complete high-fidelity flow covering all states: submission, provider documentation, appointment scheduling, advisor review, approval, denial, and the signed agreement summary. All conditional paths documented for development.
On the workshop method
The 1-on-1 format with the ADA coordinator was the most valuable part of the entire process. A group presentation would have produced polite feedback. A working session with wireframes in hand produced specific, operational insight — things like which fields the coordinator actually reviews, how they communicate decisions, and what information the healthcare provider needs to know before they sign. That level of detail can't be assumed. It has to be extracted through direct conversation.
04 — The Solution
Four parties.
One screen. Zero paper.
The redesigned ADA Accommodations feature brings together four parties — the student, their healthcare provider, the ADA coordinator, and the Salesforce/Adobe Sign integration layer — into a single coherent workflow that each party can navigate independently without depending on the others to explain the process.
Student
Submits a request, provides context about their condition and requested accommodations, schedules an appointment with the ADA advisor, and monitors status — all from one screen.
Healthcare Provider
Receives an Adobe Sign request via email, reviews the student's submission, and signs documentation digitally — no printing, no scanning, no email attachment chains.
ADA Coordinator
Reviews the completed case — student request, provider documentation, and appointment notes — and makes a decision: approve accommodations or deny with documented reason.
Salesforce + Adobe Sign
Manages case creation, routes the Adobe Sign request to the provider, triggers toast notifications at each status change, and stores the signed agreement with FERPA-compliant access controls.
End-to-end flow — all parties and phases
Lands on Student Support page → Disability & ADA Accommodations → reads policy acknowledgment → submits request with condition context and accommodation needs
Salesforce case created → Adobe Sign request routed to healthcare provider → toast notification: "Your request has been submitted"
Receives Adobe Sign email → reviews student's submitted information → signs provider documentation digitally
Provider signature received → Salesforce case updated → toast notification: "Your provider has submitted their documentation"
Schedules Interactive Process Meeting with ADA advisor — calendar and time slot selection built into the same screen
Reviews complete case — student request, provider documentation, meeting notes → makes decision: approve or deny
Adobe Sign agreement routed → student signs → accommodations go into effect → signed agreement summary visible on screen
Denial notification with documented reason → appeal pathway and advisor contact options presented on screen
Case summary with full history accessible — request details, provider documentation, meeting record, accommodations agreed, signed PDF available for download
The one-screen principle
Every stage of the student's experience — submitting a request, checking whether the provider has signed, scheduling an appointment, seeing a decision, accessing the final agreement — lives on a single screen with an accordion structure. Each section expands to show its current state and required action. Completed sections collapse with a status indicator. The student never has to navigate away, search for status, or wonder what happens next.
This wasn't just a UX preference — it was a deliberate response to the visibility problem of the old process. Students didn't know where to go. The answer was: you only ever need to go one place.
Single-screen accordion — illustrative state example
Toast notifications as transparency
The old process was a black box. A student submitted paperwork and then waited — with no idea whether it had been received, whether their provider had acted, or whether a decision was coming. The new design surfaces every meaningful behind-the-scenes action as a toast notification, appearing in the portal as each Salesforce event fires.
Request submitted
Your ADA accommodation request has been received. Your healthcare provider will be contacted to submit their documentation.
Provider documentation received
Your healthcare provider has completed and signed their documentation. You can now schedule your Interactive Process Meeting.
Accommodations approved
Your accommodation request has been approved. Please review and sign your accommodations agreement below.
05 — The Hard Part
Privacy protected
by design, not by friction.
The hardest challenge in this project wasn't the UX. It was getting the Salesforce developers to implement an Adobe Sign integration that maintained FERPA compliance — federal law governing the privacy of student education records — while enabling a fully digital, multi-party signing workflow.
FERPA compliance in this context meant that the student's medical documentation and accommodation details could not be exposed to unauthorized parties at any point in the process — including during the Adobe Sign routing, during storage in Salesforce, and during any downstream access. The old paper process achieved this by keeping everything offline. The new process had to achieve it in code.
Why this matters
Many organizations solve privacy by adding friction — making digital processes harder so sensitive information stays off systems entirely. The result, as Unity's old ADA process showed, is that the protection mechanism becomes an access barrier. Students who most need accommodations are also often those who face the most barriers to navigating a cumbersome process. The goal of this design was to make the digital process as privacy-protective as the paper process — not less — while removing every unnecessary obstacle.
The wireframes were the technical brief. By designing the full flow first — showing exactly what data needed to move between the student, the provider, the Salesforce case, and the Adobe Sign document — I gave the developers a concrete specification to work from rather than abstract requirements. The design wasn't just for users; it was for the engineering conversation.
The resulting integration routes the Adobe Sign request through Salesforce with access controls that limit document visibility to the student, the healthcare provider, and the ADA coordinator — nobody else, at any stage. The signed agreement is stored in Salesforce with field-level encryption, and the student-facing portal only surfaces the information the student is authorized to see about their own case.
06 — Reflection
What I'd do differently.
Honest retrospective
The ADA coordinator workshop was the right call and I'd do it earlier next time — ideally before the first-pass wireframes, not after. Walking through screens generates better conversation than talking abstractly about a process, but even better would be a brief observational session watching the coordinator handle an actual case before designing anything. There's a difference between knowing the steps and seeing where the friction actually lives.
The toast notification system I designed as a portal-wide pattern — but it's being deployed here first without the rest of the portal. That means students will encounter toasts on this feature before they appear elsewhere, which could create inconsistent expectations if the rollout of subsequent features takes longer than expected. Sequencing of shared infrastructure in a staged rollout is a design problem I'd approach more explicitly if doing this again.
The feature is designed and ready. Implementation is in progress. Once it's live and students are using it, the most important data to collect is: where in the flow do students pause or abandon, and how often does the provider documentation step stall the case. Both of those are places where future iterations could meaningfully reduce time-to-resolution for students waiting on accommodations.