Lead Product Designer · 2025 · HR Tech
Unblocking Workday migrations by turning cryptic errors into decisions people could finish
Errors stopped being a spreadsheet loop and became an inline queue people could finish.
For a Workday implementation partner, cutover windows were slipping because validation dumped long, unreadable error lists onto HR, IT, and consultants who could see failures but not act on them. As Lead Product Designer I owned the validation-to-resolution experience: diagnose the real bottleneck, reframe the product problem, and ship a workflow that kept migrations moving before data hit production. Constraint: enterprise coverage expectations vs. clarity for non-specialists.
01 · The problem
Validation found the errors. Nobody could act on them.
Workday migrations move thousands of employee, compensation and org records under a tight cutover. Most validation failures weren’t catastrophic (missing references, malformed codes, out-of-range dates), but each one blocked progress until someone decoded it by hand. The workaround was export, message the owner on Slack, patch, re-run. Hours became days, consultants burned budget, and internal teams lost confidence in the tool before they’d learned to trust it.
The brief was still “make errors easier to find.” That was the assumption I had to challenge.
02 · What I found
A handful of repeated error types drove most of the volume
I shadowed implementation specialists and HR admins through live runs (where they paused, what they searched for, what they asked in Slack) and grouped six months of error logs by root cause. The volume wasn’t a long tail of unique failures. It was a small set of repeated types the system could recognize, and often propose a fix for.
People weren’t struggling to find failures; the list already showed them. They were struggling to resolve them.
Process
From spreadsheet loop to error-as-workflow
Shadowing and six months of logs flipped the brief from “find errors” to “act on them.”
- 1
Shadow + logs
Sit with specialists; group six months of errors by root cause
- 2
Fat-head patterns
A few repeated types drove most of the volume
- 3
Error as workflow
Status, context, and a next step per record
- 4
Inline resolve
Accept, edit, or skip without a full re-validation cycle
03 · Key decisions
Three calls that turned errors into a workflow
Decision 1
Treat each error as a decision, not a row
Each error became a record with a status, its context and a next step, instead of another line in a long list.
- Instead of
- More investment in findability: filters, sorting and dashboards.
- Why
- The list already showed people where things failed. Finding errors wasn't the bottleneck; resolving them was.
- Trade-off
- I had to sell the reframe against the original brief, which still asked for better ways to find errors.
Decision 2
Fix errors in place, without re-running validation
Validation became a structured queue (entity, field, value, severity), where severity decides priority and whether a row blocks cutover. Each record offers a proposed fix from a small rules library, and people accept, edit or skip it on the spot.
- Instead of
- Batch re-validation after every change, which engineering preferred for consistency.
- Why
- Momentum was the adoption metric. If people can't see progress, they go back to spreadsheets.
- Trade-off
- Extra state for the product to track, and status messaging throughout (still resolving, syncing, fixed or open) so someone could step away for ten minutes and pick up without rereading the queue.
Decision 3
Fewer error types, in plainer language
We shipped fewer raw error types than the old screen, folding some into a “data mismatch” pattern that comes with a proposed fix.
- Instead of
- Keeping the full error vocabulary specialists already knew.
- Why
- The redesign was for the next person joining the team, who hadn't built that fluency yet.
- Trade-off
- Specialists who spoke the old vocabulary pushed back, and enterprise reviewers expect full coverage.
04 · Outcome
Migrations stopped dying in export loops
Errors stopped being a spreadsheet loop and became one queue people could work through to the end. The validation step started doing the job the product promised.
This outcome is behavioral rather than a before-and-after metric. The signal was the workaround disappearing: the export, Slack and patch loop was replaced by a queue that showed what was fixed, what was still open and what was syncing.
05 · Reflection
Clarity beats fluency theater
Enterprise review loves coverage. Coverage is necessary, but it isn’t the same as usability.
Power belongs in what the platform can validate and safely correct. Clarity belongs on the surface, especially when the alternative is another spreadsheet.