Making lead progress visible to requesters and providers
Challenge
Dense tables and inconsistent patterns made it difficult for requesters and providers to see progress and identify the next action.
Strategy
I audited the journeys, reorganized navigation and made request status visible within the existing data model and engineering constraints.
Outcome
Request progress became explicit without changing the data model or APIs. A heatmap review after launch set the next priority: one clear call to action.
- My role
- Lead product designer; end-to-end UX/UI revamp, system setup and delivery support
- Scope
- Requester, provider and admin journeys; navigation, onboarding and request status
- Period
- Post-delivery review: late 2023
Make progress visible. Make action deliberate.
I led the UX/UI revamp across requester, provider and admin journeys while working within the existing data model and APIs.
- Find the friction
Approximately three weeks of walkthroughs, requirement reviews, monitored sessions and heuristic evaluation.
- Prioritize the redesign
Navigation, onboarding guidance and visible request progress.
- Learn after delivery
A late-2023 heatmap review exposed competing calls to action.
Promote status from a label to a journey.
Dense tables obscured progress. I made the lifecycle explicit so a request could be understood as a sequence with a current step.
Making people infer progress from a table of labels.
A shared progress model, with role-specific responsibilities.
Show the status first. Explain it when needed.
The compact state supports scanning; expansion reveals the explanation and expected next step. Reusing the engineering component library kept the redesign deliverable.
A useful status still needs an obvious next action.
The post-delivery review found attention on cards but weak CTA performance. Competing actions became a refinement priority rather than a claim of proven uplift.
Several equally weighted routes split focus.
One primary action; supporting information stays secondary.
The thinking behind the decisions
Status becomes a journey.
Dense tables hid progress, so the lifecycle became a sequence with a current step.
Status first, detail on demand.
The compact state supports scanning. Expanding it explains the next step.
One progress model, three roles.
Requesters, providers and admins share the lifecycle with different responsibilities.
Find the friction first.
About three weeks of walkthroughs, requirement reviews, monitored sessions and heuristic evaluation.
A status still needs a next action.
The heatmap review found attention on cards but weak CTA performance.
What changed
The redesign made request progress and milestones explicit while retaining the existing data model and APIs. A post-delivery heatmap review revealed a further priority: reduce competing calls to action and clarify the next step.
What I carried forward
Action priority should be established before visual polish. A stronger status model still needs an obvious, consistent next action.