A table that has to answer questions, not list records.

One person, many identities.

A directory sync platform takes people out of a district's source systems and pushes them into everything downstream: directory groups, workspace tenants, and smaller systems like lunch programs, library catalogs, and bus routing.

A single person is rarely simple. They can arrive from more than one source feed, land in several destinations at once, and carry fields an administrator edited by hand after import. That last part matters more than it sounds, because a manually edited field no longer matches its source and will not be corrected by a resync.

The table was the debugging tool, and it could not debug.

When a teacher cannot log in, when a student is missing from a roster, when someone still holds access they should have lost, the administrator opens this table. It is where every question about a user gets answered.

A conventional user table shows name and status and hides everything that actually explains a problem.

There is no column set that works for everyone.

Districts run different source systems, store different attributes, and care about different things. One administrator is chasing employee IDs, another needs distinguished names for a directory migration, another only ever looks at email.

The instinct is to add every field as a column. That produces a table nobody can read horizontally. The opposite instinct, picking a canonical set, produces a table that fails a different administrator every day.

Four moves, each solving one failure.

Column filters turn each header into a control, including columns the administrator added moments earlier.

Delete filtered users is the riskiest control on the page.

A filtered-set action is exactly as sharp as the filter behind it. An administrator who believes they are deleting the ten rows in front of them, when the filter actually holds four thousand, has made an unrecoverable mistake in one click.

So the confirmation does not just ask whether they are sure. It states the real number, and separates it explicitly from what is visible.

The table, rebuilt and interactive.

I rebuilt this as a standalone prototype with fictional records, embedded below. Add columns until you hit the cap and watch the oldest drop out, turn on column filters, then open the delete confirmation to see how the filtered count is stated.

Why two columns, and not five?

The cap is a real constraint with real costs. An administrator comparing three attributes at once has to swap one out. A larger allowance would have handled that case, at the price of horizontal scrolling that makes the core columns harder to scan.

Two won because the table’s job is answering a question, not holding data. Once a row stops fitting on screen, the administrator is scrolling sideways to reconstruct a single person, which is the exact failure the redesign existed to fix. Two is the most I could add without reintroducing it.

Shipped, and in daily use.

The redesigned view is in production. Administrators can now answer the questions the table exists to answer: where a person came from, where they went, and whether someone changed them by hand along the way.

Density is a reading problem.