Data obfuscated for a secure public portfolio
Staffing Radar: Workforce Allocation Product Design
Principal Product Designer · Founder-built independent product
Resource managers staff the next engagement from a single utilization score that hides seniority, practice area, and confidence, so a bench of 5 ‘available’ people can mean 5 bank-ready seniors or 5 juniors who only look equivalent. The staffing call gets made on a number that cannot defend itself in a review.
HR as DJ is a workforce allocation interface that preserves uncertainty at the point of action instead of averaging it away, so a manager sees capacity, availability, skill fit, and confidence all moving at once, and can defend the call.
Submission-ready summary
Siarhei Mardovich designed Staffing Radar, a workforce allocation product for HR tech and enterprise SaaS that makes the real state of a complex staffing system easier to understand. Capacity becomes a readable landscape, demand becomes visible pressure, and AI-assisted matching turns uncertain resource-planning data into reviewable staffing decisions. The case demonstrates 0-to-1 product design, information architecture, and decision-support interface design.
Hiring teams: use this as a concise case summary.
This case shares a design problem with the other showcases in this portfolio. Uncertainty as Signal keeps probabilistic climate risk legible for capital allocation, North Bridge keeps dense enterprise workflow tied to company context, and What Gets Measured keeps clinical performance comparable without flattening it into a single score. Staffing Radar applies the same design approach to workforce allocation: when capacity is misread, the staffing decision becomes expensive to reverse.
The core insight was that capacity is not a headcount. A firm can have 100 billable people and still be unable to staff the next engagement if the available mix is wrong. Seniority, practice area, geography, utilization, compensation, and confidence all shape whether a person is actually usable for a role.
That makes staffing a representation problem before it is a workflow problem. A resource manager looking at a single utilization score has no way to tell whether the bench holds 5 senior consultants ready for a banking engagement or 5 junior associates who only look equivalent after the data has been flattened.
Decision: preserve uncertainty at the point of action. I rejected the single fit-score because a manager could not defend it in a staffing review, and rejected pure headcount because it made fragile capacity look solid. The trade accepted: the screen asks more of the reader up front, in exchange for a call that survives review.
From Matching Model To Staffing Action
As Principal Product Designer, I began with a matching model rather than a screen layout. Skills and seniority, geolocation, compensation, practice area, and availability all became weighted factors a manager could inspect and adjust. The information architecture needed enough structure for a fast staffing review without asking every manager to become a data scientist.
The early system sketch resolved that tension into a product architecture: entities and tags feed weighted factors, weighted factors pass through a confidence threshold, and the interface presents specific candidate-to-opportunity connections as evidence rather than as black-box matches. That is an interaction-design decision as much as a data decision.
1. Model The Match
Define fit through skills, seniority, geography, compensation, and availability before drawing the interface.
2. Preserve Confidence
Keep uncertainty visible with ranges, opacity, and confidence bands instead of collapsing it into a single score.
3. Shortlist With Rationale
Let managers tune factors, inspect candidates, and understand why a match is strong enough to defend.
4. Move To Action
Carry the decision into Available, Proposed, and Booked states so the product behaves like an operating tool.
Making Capacity Legible
The prototype extends the model into an interface: drill from practice areas into teams and specialists, then see availability ranges, bench depth, skill distribution, confidence intervals, and deployment state in one working context. Opacity and confidence bands keep a manager from mistaking low-confidence capacity for guaranteed delivery.
The treemap analysis view is the clearest example. Drilling into a practice shows each specialist’s availability as a proportional bar with the percentage visible, so a 14% specialist and a 54% specialist stop reading as the same headcount. That visual choice changes the conversation: the firm may have enough capacity on paper, but the decision still needs evidence and review. Decision: render partial availability as a visible proportion, not as exclusion from the bench; traded a cleaner treemap for a more honest one.
The prototype is intentionally focused on interface logic rather than full production scope. It shows how a delivery board can inspect capacity with confidence levels, how a resource manager can drill into individual profiles and availability ranges, and how a staffing decision can become traceable enough for review.
The method carried forward. The same commitment to keeping uncertainty legible at the point of decision runs through later work in risk visualization and clinical benchmarking elsewhere in this portfolio. Staffing Radar is where that approach started.
One staffing decision, replayed
Following one decision from the bench view to a match score shows how the model turns into action.
Where the model breaks
Any allocation system fails if its limits are not surfaced. Here are 3 failure modes and the design counter-measure for each.
Stale availability data
Yesterday’s bench state becomes tomorrow’s bad allocation.
Counter-measure: time-stamped confidence decay and explicit last-verified markers so old capacity signals do not drive new decisions.
Factor-weight gaming
Hidden slider settings can make a weak match look strong.
Counter-measure: factor weights are visible and adjustable by role, so no single stakeholder can hide weak matches behind a hidden control. Decision: expose the weights, not hide them; traded a simpler default view for a call the manager can justify factor by factor.
Transparency resistance
Staffing cultures sometimes reward opaque ownership over shared reasoning.
Counter-measure: the interface exposes the reasoning behind every shortlist, making the system auditable and the cultural barrier discussable.
Methods, Skills, and Tools
- Algorithmic matching and AI-assisted allocation: a weighted-factor engine for skills, seniority, geolocation, compensation, and availability with a confidence threshold
- Product design and UX, taken 0-to-1 from concept to working prototype for workforce allocation, capacity planning, and staffing-review workflows
- Information architecture and domain modeling: skills, seniority, geolocation, compensation, availability, and confidence-threshold logic
- Interaction design connecting candidate discovery, opportunity review, factor tuning, shortlist rationale, and Available, Proposed, and Booked staffing states
- Data visualization for decision intelligence: capacity treemap, bench and demand sunbursts, and a match radar, with opacity and confidence bands encoding uncertainty
- Progressive disclosure and confidence-interval encoding tuned for usability when capacity, availability, and skill fit are all uncertain
- Custom squarify algorithm for the treemap layout, with capacity-weighted, confidence-aware visual encoding
- Custom SVG sunburst with a bench-bucket to practice hierarchy, plus a custom radar chart with interactive hover tooltips
- Single-file HTML, CSS, and JavaScript prototype and no backend dependency
- Staffing-review walkthroughs designed around resource-manager decision points
- Artifact set: matching model, system sketch, MVP wireframe, high-fidelity board, and capacity-distribution model
What This Demonstrates
Staffing software often fails by pretending capacity is cleaner than it is. This case demonstrates the opposite design stance: preserve uncertainty, reveal the mechanism, and give a manager enough structure to make a defensible allocation decision under incomplete information. That is a product-design argument about decision intelligence, not a dashboard styling exercise.
It also shows disciplined product storytelling. The artifacts carry the model, the prototype carries the behavior, and the case study makes the reasoning legible. The prototype does not claim adoption it never had; it makes the case that confidence-aware matching reduces over-allocation risk, and it is honest about the organizational resistance to transparency that any such tool has to overcome.
Across the work, the case demonstrates product design, UX strategy, information architecture, interaction design, data visualization, and working front-end prototyping for enterprise decision support: a designer who can model a hard problem, shape the interface, and build the proof.
What we learned: factor-weight visibility surfaced cultural resistance to shared reasoning. The hardest constraint on this design is organizational, not technical.
Let’s Talk
Open to principal/staff product design roles · Greater New York City Area · siarhei.mardovich@gmail.com · LinkedIn · Resume