Contractor Qualification Platform

Prequaligy

"Three groups. One broken system. The issue wasn't missing functionality."

RoleUI/UX Designer
Product TypeContractor Qualification Platform
Stakeholders3 distinct user groups
SolutionShortFlow
The situation

Three groups,
one system, all
struggling.

Contractor prequalification sounds procedural. In practice, it's a coordination problem across three distinct groups, Requestors who initiate qualifications, Contractors who complete them, and Administrators who oversee and approve.

Each group had a different view of the same process. Each had a different set of blockers. And the platform that was supposed to connect them had become the source of their shared frustration.

The impulse was to add features, more status updates, better notifications, more fields. But the features were already there. The problem was structural.

The problem wasn't missing functionality.
It was exposed complexity.
Who was struggling, and how

Click each group
to hear their story.

Stakeholder A
Requestor
Initiates the prequalification process.
  • No visibility into where a contractor's qualification stands without manually checking
  • Sending reminders manually, no automated nudge in the system
  • Can't prioritize which contractors need attention most
  • Too much information at once; hard to see what needs action
Stakeholder B
Contractor
Responds to and completes qualifications.
  • Doesn't know what's expected before starting, requirements buried inside the form
  • No save-and-return, completing a qualification requires a single unbroken session
  • Error messages appear after submission, not during entry
  • Multiple active qualifications with no unified status view
Stakeholder C
Administrator
Oversees, audits, and approves qualifications.
  • Review queue has no prioritization, everything looks equally urgent
  • Can't identify bottlenecks without exporting data to a spreadsheet
  • Approval requires navigating through multiple screens per contractor
  • No audit trail visible in the primary interface
Evidence board, diagnosing the root cause
Observation
All three groups frustrated by same platform, but for entirely different reasons
Evidence
Each group has most of the information they need, but must work to extract it from the interface
Insight
The system is technically complete but cognitively expensive, the structure of the interface works against the structure of the work
Decision
Redesign the information sequence per role, not the features themselves
The diagnosis

Not a features problem.
A workflow problem.

After mapping each stakeholder's journey, a pattern emerged. Every group had most of the information they needed. But the information was presented in a way that required them to work to extract it.

Requestors had to dig for status. Contractors had to commit before understanding requirements. Administrators had to export data to prioritize their queue.

If the system already has the right information, the design problem is: in what order should each stakeholder see it, and in what form?

To understand where friction appeared, I mapped the existing qualification journey across requestors, contractors, and administrators. The flow revealed repeated context switching, hidden requirements, and unnecessary decision points that slowed progress for every stakeholder.

Current Qualification Flow

Current Flow Map 1 Current Flow Map 3
ShortFlow
Progressive disclosure meets guided workflow
Design goals

What ShortFlow
was built to do.

01
Progressive disclosure by stakeholder role.
Each user sees only what's relevant at their stage. Requestors see action items first. Contractors see requirements before they start. Admins see prioritized queues.
02
Guided workflows that reduce cognitive load.
Replace open-ended forms with guided step sequences. Each step has exactly one decision. Progress is always visible.
03
Centralized status visibility across all roles.
Every stakeholder can see the current state of every relevant qualification, without hunting. Status surfaces to the top of every view.
04
Action-oriented dashboards that remove interpretation.
Instead of showing data, show what needs to happen. Make that action one click away.
05
AI-powered prioritization for administrators.
Surface contractors who most need attention based on deadline, completeness, and risk signals, so admins direct effort where it matters.
Design explorations

Designing a guided qualification experience.

ShortFlow restructures qualification into a guided workflow. Instead of exposing every field and requirement upfront, information is progressively revealed based on role, task, and completion status.

Solution concept

From open-ended forms to a guided workflow.

ShortFlow restructures qualification into a guided workflow. Instead of exposing every field and requirement upfront, information is progressively revealed based on role, task, and completion status.

ShortFlow Guided Workflow
Final experience

A single place to manage qualification progress.

The final experience gives stakeholders visibility into qualification status, pending actions, and progress without requiring them to dig through multiple screens.

Qualification Dashboard
Reflections

Designing for multiple mental models.

  • 01Multi-stakeholder systems need multiple entry points. One interface trying to serve three different mental models will serve none of them well.
  • 02Progressive disclosure is not about hiding information, it's about sequencing it. The right information at the right moment reduces cognitive load more than any visual simplification.
  • 03"The features are all there" is not a sign that the design is done. A technically complete system can still be functionally unusable if the structure works against the user's workflow.
  • 04Action-orientation changes a dashboard entirely. Users don't need to see data, they need to know what to do with it.
Next investigation
FlowDesk →
↗