HR as DJ

A 14% specialist and a 54% specialist stop reading as the same headcount. That is the product in one line: Staffing Radar draws availability as a proportion, so a bench of 5 people stops reading as 5 interchangeable people.

Principal Product Designer. Founder-built independent product: I built the allocation model, the product, and the interface.

Shipped, founder-built
Workforce analytics
Product design
Data visualization
Decision support

Capacity is not a headcount

01 · The framing

Resource managers staff the next engagement from a single utilization score that hides seniority, practice area, and confidence. A bench of 5 people marked available 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.

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.

So the model came first. Treat staffing as a distribution problem: practice area, seniority, skill fit, availability, and confidence are modeled together and revealed through progressive disclosure, so a manager can see why a staffing recommendation is strong or fragile.

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.

Staffing Radar capacity model showing availability as a probability surface over a partitioned base plane. — Availability is represented as a distribution rather than a count. The working prototype makes this interactive.

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 approach to workforce allocation: when capacity is misread, the staffing decision becomes expensive to reverse.

What the treemap changed

02 · The payoff

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. Partial availability is rendered as a visible proportion rather than as exclusion from the bench, which traded a cleaner treemap for a more honest one.

Staffing Radar dashboard with the Available panel drilled into the Security AppSec team, listing 4 specialists each with a proportional availability bar and percentage. — Drilled into a practice, each specialist carries a proportional availability bar and a percentage instead of a single headcount.

One staffing decision, replayed

Following one decision from the bench view to a match score shows how the model turns into action.

Scan the bench A manager opens the dashboard and scans the bench by practice. Tile size reflects specialist count and capacity, not just headcount. Available treemap · practice level
Availability, not headcount Drilling into a practice shows each specialist’s availability as a proportional bar and percentage: 14% and 54% available read as different candidates even though a raw headcount would treat them the same. Availability bar · percentage · confidence band
Radar score Dropping a candidate onto a position fills in the match radar. Skills, seniority, location, availability, and experience each score independently, and the chosen candidate carries that rationale into the staffing pipeline. Skills · seniority · location · availability · experience

Staffing Radar prototype after dragging a candidate onto a position: the Match Radar panel shows a filled pentagon scoring the candidate against an AppSec position, with a skills, seniority, location, availability, and experience breakdown. — The radar scores 5 factors independently, so the rationale stays inspectable instead of collapsing into one number.

The encodings, and what it took to build them

03 · Model and craft

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.

Model the match Define fit through skills, seniority, geography, compensation, and availability before drawing the interface.
Preserve confidence Keep uncertainty visible with ranges, opacity, and confidence bands instead of collapsing it into a single score.
Shortlist with rationale Let managers tune factors, inspect candidates, and understand why a match is strong enough to defend.
Move to action Carry the decision into Available, Proposed, and Booked states so the product behaves like an operating tool.

Staffing Radar domain model showing weighted skills and seniority, geolocation, and compensation factors around an ideal candidate. — The matching factors were defined before any screen, so the interface rests on an explicit decision model rather than on visual styling.

Staffing Radar system sketch showing taxonomy, folksonomy, weighted factors, confidence threshold, and candidate connections. — Taxonomy, folksonomy, weighted factors, and a confidence threshold resolve into staffing connections.

The prototype extends the model into an interface: drill from practice areas into teams and specialists, then read 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.

Staffing Radar prototype interface: an Available capacity treemap of practice areas sized by capacity, an Open Positions treemap, and a Capacity Atlas with Bench and Demand sunburst charts, beside a match radar panel that scores a candidate against an open position. — Capacity treemaps sized by availability, Bench and Demand sunburst charts, and a match radar that scores a candidate against an open position. . It is a desktop-width board: scroll horizontally to see all of it.

Built by hand

Custom squarify algorithm for the treemap layout, with capacity-weighted, confidence-aware visual encoding
Custom SVG sunburst with a bench-bucket to practice hierarchy
Custom radar chart with interactive hover tooltips
Single-file HTML, CSS, and JavaScript prototype with no backend dependency
Artifact set: matching model, system sketch, MVP wireframe, high-fidelity board, and capacity-distribution model

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. It does not claim adoption it never had.

Where the model breaks

04 · Failure modes

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 a weak match behind a hidden control. Exposing the weights instead of hiding 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, which makes the system auditable and the cultural barrier discussable.

What we learned

Factor-weight visibility surfaced cultural resistance to shared reasoning. The hardest constraint on this design is organizational, not technical.

The method carried forward

05 · What transfers

Staffing software often fails by pretending capacity is cleaner than it is. This case takes the opposite 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.

The artifacts carry the model, the prototype carries the behavior, and the case makes the reasoning legible. The argument is that confidence-aware matching reduces over-allocation risk, and it stays honest about the organizational resistance to transparency that any such tool has to overcome.

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, and through 15 years of designing decision interfaces for people who have to act on a model they did not build. Staffing Radar is where that approach started.