Project Performance
Giving Suppliers Answer, Not Dashboards
Turning a data dense dashboard into a clear answer
Context
Beeline is a vendor management system companies use to manage their contingent workforce, including the staffing suppliers who fill open roles. Supplier Network 2.0 is the portal those suppliers work in daily: receiving requisitions, submitting candidates, tracking fills.
Project Performance is the feature in Supplier Network 2.0 that shows suppliers how well they're actually performing against the metrics clients judge them by.
The Problem
An earlier version of the dashboard was built by the data team. It was overwhelming and answered the question an analyst anticipated, not the ones brief wanted answered.
The Goal
Enable suppliers to answer their primary performance questions within 30 seconds of landing on the page.
DISCOVERYWhat the Audit Found
The dashboard was organized around the database schema, not the supplier's head. Getting an answer to something as basic as "how am I doing" would have meant filtering, cross-referencing charts, and doing the analysis themselves, before it ever reached the people who'd have to use it that way.
No supporting text anywhere explaining what a section showed or how trustworthy the numbers were: "Where is the trust?"
A root-cause summary table placed above the top-line KPIs: "Why would I start looking at the root cause before I even know if I have a problem?"
A heavy, ungrouped filter bar: "So many filters! Does the user really need to see all the filters at once?"
Inconsistent filter placement: "Should the date filter be in the same line as the rest?"
Charts with no built-in takeaway: "Can't get a quick answer at a glance."
Key summary numbers (Request Outcomes) pushed below the fold, easy to miss entirely
Four real reasons suppliers opened this dashboard.
Before touching the layout, I mapped why suppliers actually came looking for performance data every scenario turned out to be a request for a decision, not an analysis.
01 — Internal business reviews
Supplier operations teams run their own business reviews and need to understand performance without waiting for a client to provide a report.
How are we performing?
02 — Deciding where to focus
Where are we underperforming?
Performance can vary significantly across clients, industries, or areas of the business.
03 — Contract renewal preparation
Where do we outperform expectations or the market?
Suppliers need evidence when demonstrating their value during contract conversations.
04 — Onboarding new recruiters
What does good look like?
New team members need context for what good performance looks like.
InsightNone of these are exploratory data-analysis tasks—they’re essentially “Tell me something I can act on,” which became the central design principle for Project Performance: instead of asking users to interpret a dashboard, the interface should do more of the interpretation for them.
Defining the Metrics
Working closely with the Data Science team, I anchored the experience around six performance metrics.
Rather than presenting every available data point, the metrics were organized around two concepts suppliers already understood:
Information Architecture
Once the metrics and use cases were established, I structured the experience around three progressively deeper questions. Structuring it this way meant the majority of users that just need a quick answer never have to touch the dense table, while the minority doing real investigation aren't stuck with a shallow summary.
01 - OrientationWhat’s been happening?
The first layer gives suppliers a quick understanding of their business volume. The KPI cards aren’t intended to require any interpretation.
02 - EvalutationHow am I doing?
The second layer answers the question suppliers actually came to the page to answer of how they are performing. Instead of forcing users to find relationships between separate charts, the interface creates those relationships for them.
Why?
03 - InvestigationThe final layer provides a more detailed data table for users conducting an investigation to better understand the above layers and need to go deeper. This is where the experience becomes intentionally more dense.
Key Decisions
Defined every metric on the page itself
(including competitive vs. non-competitive), so trust in the number didn't depend on tribal knowledge.
Cut filters aggressively
Six dimensions (Hiring Manager, Job Class, Cost Center, etc.) were considered and dropped because they didn't map to a real use case.
Designed for legal uncertainty
Client-level data needed legal review; I built the root-cause table to work whether the answer was full detail or anonymized/aggregated only, so the feature wouldn't stall
Takeaway