When the workaround becomes the warning sign
A redesign of the Supportive Services workflow for a state workforce development program, where caseworker friction was not just an inconvenience. It delayed real people from receiving bus passes, job training funds, and basic support.
My Role:
UX Designer, Consulting
Client:
State Workforce Development Program
Methods:
Survey, User Interviews, Redesign
TEAM:
Design, Development, Client Stakeholders
CONTEXT
The program and the people
This state program provides free job training, employment resources, and support services to participants receiving SNAP or TANF benefits. People working toward financial independence, often navigate significant barriers to employment.
Case Managers and Career Coaches are the frontline. They request Supportive Services on behalf of participants: bus passes, gas cards, clothing vouchers, and test fees. Each request must be approved before it can be issued, and every service requires a signed voucher. The system tracks limits, statuses, dollar caps, and documentation across five service types.
The process is complex by necessity. What was not necessary was how hard the tool made it.
RESEARCH
We sent a survey. What came back surprised us.
We surveyed 35 users across roles including Career Coaches, Regional Managers, and Receptionists. Nearly half had five or more years of experience with the program. These were not new employees guessing their way through. These were seasoned professionals who still found the system confusing.
A note on process: We used Maze to distribute the survey and leveraged its built-in AI sentiment analysis to help synthesize open-ended responses. The tool also enabled adaptive follow-up questions based on participant answers. All AI-generated summaries were manually reviewed and corrected where needed before informing any design decisions.
“It has gotten easier with practice and remembering past mistakes”
CAREER COACH
5+ YEARS EXPERIENCE
The voucher description field was the central pain point. It was a free-text box with no instructions, no guidance, and no examples. When it was not filled out correctly, the request was rejected. Those rejections were not just a system error. They meant a real person waited longer for support they needed. That quote stayed with us throughout the project. Remembering past mistakes should not be how people learn to use a tool that affects whether someone can get to a job interview.
Voucher Description
Users were not sure what information was required in the description field. Different reviewers expected different things, and what counted as sufficient to one person did not to another.
"What is to be excluded from the actual request? A specific list of what is considered case information, because what it is to one person won't be the same for another."
The Shadow Workaround
Users had built their own solution: an Excel file with template descriptions they copied, pasted, and manually edited for each request. The system had failed them so consistently that they stopped relying on it.
"The most common reason for rejection is not including everything required in the voucher description notes."
Rejection Loop
When a request was rejected, caseworkers had to find the rejection reason, navigate back to the request, and remember what to fix, with no in-context guidance on what went wrong.
"There are no instructions for this except in the policy manual and it's not clear."
Fragmented Views
Supportive Services records were scattered across multiple screens and tabs, requiring caseworkers to navigate constantly just to see a complete picture of one participant's history.
"Having to go to a separate section to put in a person note after making a request. It feels redundant."
THE PROBLEM
Before: a system that taught through failure
The original interface was functional in a narrow sense. You could submit a request. But it offered almost no guidance on how to do it well, and the consequences of doing it wrong rippled outward to the participants waiting for help.
Before
Blank voucher description text box with no template, no guidance, and no examples
Rejection returned users to the start with no inline context about what to fix
Single serial number field for multiple pre-paid items
22 pages and tabs across the full workflow
Participant overview showed raw totals with no visual breakdown by service type
Details page used tabs, hiding information behind extra clicks
DESIGN DECISIONS
What we changed and why
We absorbed the Excel file into the system
Users had built their own template workaround outside the tool. Rather than replace it with something unfamiliar, we took what they already trusted and built it directly into the request form, auto-populated where possible, with bracketed placeholders for case-specific details. We proposed a structured line-item input for clothing requests, but users told us they preferred to type freely rather than navigate dropdowns. We listened and kept the template approach.
We made rejection reasons impossible to miss
Previously, a caseworker returning to fix a rejected request had to remember or re-find why it was rejected. In the redesign, the rejection reason appears as a prominent alert at the very top of the edit form, before they have touched a single field. No more memory tax on an already demanding job.
We unified four screens into one
Four separate views for different service statuses were consolidated into a single screen with two tabs: In Process and Issued. This came directly from user interview feedback. Caseworkers wanted to see everything in one place without navigating between pages.
We rethought serial number entry
The original system had a single long text box for all serial numbers, even when issuing multiple bus passes or gas cards. We replaced this with an add-another pattern, giving each card its own field with individual replace and void actions. A pain point surfaced in user interviews became a specific, testable design solution.
OUTCOME
Validated by the people who know this work best
The redesign was validated through user review sessions with Career Coaches and stakeholders. Feedback was consistently positive. Users felt the new flow was significantly faster and required fewer clicks to complete common tasks. The auto-populated voucher template received particularly enthusiastic responses from caseworkers who had been managing their own workaround for months.
One of the clearest signals of success: users who had built and maintained that Excel file were genuinely excited to see it made unnecessary. The project is currently awaiting development and deployment.
REFLECTION
What I learned
Workarounds are a design brief
When users build their own shadow system, an Excel file, a shared doc, a sticky note, that is not a quirk. It is a signal that the real system has failed them in a specific and chronic way. The Excel template told us exactly what the tool should have been doing all along.
Clever is not always better
We proposed a structured clothing input that would have eliminated freeform text entirely. Users said no. They would rather type than navigate a dropdown. The best design solution is the one people will actually use, not the most elegant one on paper.
The stakes were human
Every rejected request meant a delayed bus pass or a missed job interview. Keeping that in mind throughout the process was not just motivating. It clarified every prioritization decision we had to make.
If I could revisit this
I would explore whether the voucher description field could do even more, dynamically assembling content from structured inputs while still allowing freeform override. The template is a meaningful step forward. Removing the blank page entirely is still the right long-term goal.
Related Projects
