Lead Product Designer/2025/HR Tech

Turning cryptic Workday migration errors into a guided resolution workflow

I led the design of a data validation platform for a Workday implementation partner. The work centered on the moment most likely to derail an enterprise migration: a long, cryptic list of validation errors that nobody on the team is equipped to read. My job was to turn that list into a workflow people could actually move through — so HR admins, IT operators, and implementation specialists could diagnose and resolve issues before any data touched production Workday.

Migrations were stalling on errors nobody could read

A Workday migration sits at the intersection of HR operations, IT, and finance — moving thousands of employee, compensation, and org-structure records into a new system on a tight cutover window. The teams running those migrations were hitting lengthy validation outputs with no guidance on what had failed or how to fix it. Most of the errors weren’t catastrophic; they were structural mismatches like a missing field reference, a malformed code, or a date out of range. But every one of them blocked the migration until someone manually decoded it.

The workaround was familiar to anyone who’s shipped enterprise software: export errors to a spreadsheet, ping the source-system owner, patch in bulk, re-run validation, repeat. Migrations that should have taken hours stretched across days. Implementation consultants burned against budget. Internal teams lost confidence in the tool before they had a real chance to use it. The validation step had become the bottleneck the platform was supposed to remove.

The problem wasn’t the data, it was the translation

I started by sitting with implementation specialists and HR admins as they worked through real migration runs, taking notes on where they paused, what they Googled, and what they ended up writing in Slack to ask for help. In parallel I pulled six months of error logs and grouped them by root cause to see whether the volume problem was a long tail of unique issues or a fat head of repeated ones. It was the latter — a small number of error types accounted for most of the noise, and most of them were patterns the system could recognize and even propose fixes for.

The shape of the work changed once that pattern came into focus. The original brief had been “make the errors easier to find,” which led toward filters, sorting, and dashboard-style summaries. But users weren’t struggling to find errors — they could see exactly what had failed. They were struggling to act on them. That reframe flipped the design problem from surfacing more error data to giving each error a shape: a status, a context, a recommended next step a non-technical user could move on.

Errors became a workflow, not a list

The redesign treats every error as a record with its own state, not a string in a log. Validation runs surface in a structured table where each row carries the affected entity, the field that failed, the value submitted, and the severity. Severity isn’t decorative — it controls sort order, drives the prioritization summary at the top of the table, and decides whether a row blocks the migration or only flags it for review.

Resolution happens inline. When a user opens a row, the same record exposes an editable correction input pre-filled with the submitted value plus a proposed solution drawn from a small rules library — date reformats, code normalizations, dictionary lookups for known terminology mismatches. Users accept, edit, or skip. Accepting updates the local dataset and removes the row from the queue without forcing a full re-validation cycle. That last piece was the most contentious decision in the design: engineering preferred deferring all corrections to a batch re-validation step for consistency, but defending the inline pattern was worth the additional state management. It meant users could see momentum, and momentum is what kept them in the flow.

Status feedback runs throughout. A validation that’s still resolving says so. A syncing dataset shows what it’s doing and roughly when it’ll be done. The final report names exactly what was fixed and what’s still open. A user who steps away for ten minutes can come back and pick up where they left off without rereading the whole queue.

What “clear” actually means for enterprise tooling

Enterprise tools tend to get reviewed on coverage — does it surface every error, expose every field, support every edge case? Coverage is necessary but it isn’t the same as usability. The version we shipped exposes fewer raw error types than the original screen did, because some of them were folded into a single “data mismatch” category with a proposed fix. A few specialists pushed back at first; they’d been trained on the old vocabulary and could read it fluently. The point of the redesign wasn’t to make the platform easier for them. It was to make it usable for the next person joining their team, who hadn’t built that fluency yet.

That’s the part of enterprise design I keep coming back to: the strongest version of a workflow is rarely the one that looks most powerful to the people who already know how to use it. Power belongs in the platform’s behavior — what it can validate, what it can correct, what it can safely defer. Clarity belongs in the surface.