Know Who Knows Entity and Network Analytics UX

The other showcases in this portfolio (Uncertainty as Signal, Volatility Surface, North Bridge, HR as DJ, What Gets Measured) share the same underlying design problem: when a decision-maker misreads dense information, the consequence lands in capital, operating risk, or an irreversible call. The interface is the layer between the complexity and the decision.

The system treats expertise as topology, not a list. A manager needs to see who connects the right experts, which departments are covered, and where collaboration risk appears before committing a shortlist.

The same person looks completely different depending on which view you use to examine them. In a table, they are a row of attributes. In a treemap, they are a block of proportional weight inside a cluster. In a network graph, they are a node with a specific position in a topology: central, peripheral, or bridging. Each view answers a different question, and the right view depends on the decision you are trying to make.

A manager assembling a team for a critical AI initiative is trying to find the person who can pull the team together: who has the relationships across departments, who is trusted by the domain experts they need to recruit, who has worked with enough of the relevant people that the team will actually function once formed. That is a topology question, and it cannot be answered by sorting a table.

The 3 views were designed as a progressive narrowing sequence. You start in the Roster because you do not yet know what you are looking for: you have a project brief and a rough sense of the skills it requires. The Roster shows the full candidate space, sortable and filterable, but deliberately neutral about relative importance. Nothing is ranked because ranking at this stage would be premature.

You move to the Org Grid when you notice a pattern that prompts a structural question: why are there so many relevant candidates in a department that has nothing to do with the initiative? The Grid is a treemap that shows where those candidates sit in the organizational structure. Blocks are sized by match confidence. Drilling down reveals clusters of co-located expertise: teams that have already built the skill set you need, teams you may not have known existed.

You move to the Talent Network when the Org Grid has narrowed the candidate space to a cluster worth examining closely. The network shows the relationships between people: past projects, shared managers, co-authorship, collaboration history. Nodes are sized by connectivity. The hub node is the person you are actually looking for: the person who knows the most people in the cluster.

The hub discovery is the core interaction. In a force-directed graph, hub nodes naturally migrate toward the center as the physics simulation settles. The visual affordance is immediate and physical: the most connected person is at the center of the group. You do not need to run a centrality algorithm in your head. The topology makes it visible.

The shortlist mechanism closes the loop. Dragging a person from the network to the shortlist, or clicking the add button on their profile sheet, adds them to a persistent shortlist visible as a badge on the floating action button. The shortlist panel shows not just who is on it, but the coverage map: which skill clusters have been addressed, which remain open, and what the team’s network centrality looks like as a whole. A team of individually excellent people who have never worked together is a different risk profile than a team of slightly less skilled people with dense shared history.

The Roster is the neutral starting point. It shows the full candidate pool as a sortable table, with filters for department, seniority, key skills, and location. Nothing is ranked yet, because ranking before scoping would be premature. The manager sees the full space, notices patterns, and decides which dimension deserves attention next.

When a pattern appears in the Roster, the manager switches to the Org Grid to ask a structural question: where do these candidates sit in the organization? The treemap sizes departments by filtered candidate volume and shows average availability and skill coverage. Drill-down reveals co-located expertise that might otherwise be invisible.

Once the Org Grid narrows the candidate space to a cluster worth inspecting, the Talent Network reveals the relationships between people. Node size and position show connectivity; the hub node is the connector who knows the most relevant experts. Clicking any node opens a profile side sheet without losing network context, so the manager can add the right person to the shortlist with rationale intact.

The prototype below demonstrates one complete staffing review: filter candidates, validate org coverage, inspect collaboration risk, and finalize the shortlist.

Finding the right person in a large organization is a representation problem. When organizational structure is opaque, managers default to the people they already know, not because they are the best fit, but because the topology of expertise is invisible. When the topology becomes visible, the decision improves.

This showcase demonstrates how the same dataset can be encoded across 3 coordinated views (table, treemap, network), each surfacing a different structural dimension, each supporting a different decision moment, and each preserving enough shared context that the analyst never loses the thread. The design principle is not interface variety. The right view at the right moment is itself a form of uncertainty reduction.

What I would measure: time from project brief to defended shortlist against the manager’s current process; the share of shortlists that include a connector the manager had not worked with before, the topology-made-visible signal; and shortlist survival rate through staffing review. No timed study exists yet; the guided tour is the calibration point.

My starting assumption was that better filters would find the connector. The network view broke it: filters find attributes, and a connector is a property of the topology, not of any row. The rule I carry forward: when the question is relational, the encoding must be relational.