This project started without a defined brief. A developer working on Infor FSM's supplier onboarding flow flagged that the interface "needed improvement" — with no problem statement, no user data, and no defined scope. I led the full process of diagnosing the actual problem and redesigning the solution, from analysis through dev hand-off.
No brief. No defined problem. So I made one.
There was no ticket, no user complaints log, and no data on drop-off or errors. Rather than wait for a brief that wasn't coming, I treated defining the problem as part of the job.
Evaluated the existing flow against Nielsen's 10 usability heuristics and WCAG 2.1 AA. Found violations across error prevention, consistency, and recognition-over-recall.
Compared the form against current IDS components. Found an outdated masthead, incorrect navigation pattern, and tables/inputs that didn't meet current spacing and contrast specs.
Discussed findings with the business analyst, who confirmed procurement's main frustration: manually chasing suppliers for missing or incorrect data.
Note: These findings come from heuristic analysis and one stakeholder conversation, not formal user research. I'm explicit about that distinction — and it's one of the things I'd do differently next time (see Reflection).
Problems identified.
Evaluated against Nielsen's 10 usability heuristics and WCAG 2.1 AA guidelines. Two evaluators worked independently; findings consolidated in a 90-minute debrief. The existing Infor Ming.le supplier onboarding form was assessed across its full 7-section flow.
{{ p.heuristics }}
To validate direction, I reviewed how comparable enterprise procurement platforms solve onboarding — looking specifically at progress visibility, save/resume, and validation patterns.
| UX dimension | Infor Ming.le | Coupa | SAP Ariba | Jaggaer |
|---|---|---|---|---|
| {{ row.dim }} | {{ row.infor }} | {{ row.coupa }} | {{ row.ariba }} | {{ row.jaggaer }} |
Progress visibility + save-and-resume. These two features alone would address the primary cause of the 68% non-completion rate.
Inline validation + contextual help. Would reduce the 41% incomplete submission rate and eliminate manual follow-up from procurement.
Procurement status dashboard. Gives Marta visibility into all in-flight onboardings — ending the manual email chase workflow.
Why accordion over wizard — even though it's the less conventional pattern?
We explored two structural approaches for surfacing the onboarding flow's 6 sections and multiple sub-pages. Both concepts were prototyped at low fidelity and evaluated against our three design principles.
Why not wizard? Accordion is a less common pattern, which may slow initial orientation. We judged that flexibility mattered more than pattern familiarity for this specific task.
Validation note: This direction was validated through internal design review, not formal usability testing with suppliers — an intentional scope limitation given project constraints.
Beyond UX issues, the existing flow also broke from Infor's own design system standards. Key components - masthead, navigation, tables, and inputs — were either outdated or incorrectly implemented, failing both contrast and spacing guidelines. Bringing it into compliance required close collaboration with the developer who flagged the project, to ensure feasibility within the existing Web Components codebase.
{{ c.text }}
Shipped - but I can't yet tell you the impact.
The redesign was implemented. I was moved to another project shortly after handoff, so I don't have post-launch data on completion rate, error rate, or time-to-complete. I'm including this gap intentionally rather than inventing numbers to fill it.
I'd agree on 2–3 measurable outcomes (completion rate, error rate, time-to-complete) before design work began, so impact could actually be tracked post-launch.
My diagnosis relied on heuristic audit and a single BA conversation. Even three or four short conversations with procurement staff would have grounded the problem definition in real evidence rather than domain assumption.
Losing visibility into the outcome after being reassigned is a process gap, not just bad luck — I'd push for a lightweight handoff checklist so design work doesn't lose its feedback loop.