IBM Knowledge Catalog
Catching problems before they become problems
A concept exploration for IBM Knowledge Catalog—reimagining how data stewards work with an agent that catches risk before it hits data quality.
- Product, UX, and UI Design
- with Ashley Bock, Emily Dowell
- June 2026
- 3-week concept sprint
01Summary
IBM Knowledge Catalog is where enterprise data lives—thousands of assets, dozens of compliance policies, and a workflow built around searching for problems instead of being told about them. Working with two teammates, I helped take this concept from a blank page to a working prototype in three weeks, reimagining the experience around a data steward: someone accountable for keeping an organization’s data compliant and trustworthy. Each of us drafted the full experience independently before converging on one flow together; my focus in final execution was the data quality visualization and the post-remediation activity tracking.
The result doesn’t wait for a steward to go looking for trouble. It surfaces risk before it becomes a violation, proposes a fix in plain language, and asks before it acts—turning a job that’s normally reactive into one where you’re already ahead of the problem.
02Context
A data catalog is where an organization’s data assets live—tables, dashboards, models, anything worth finding and trusting. A data steward is the person accountable for that data: making sure it’s classified correctly, compliant with policy, and safe for other people to use. In a large organization, that can mean thousands of assets and dozens of active policies, most of which a steward finds out about only after something’s already gone wrong.
03The problem
Before we designed anything new, the three of us ran a full heuristic evaluation of the existing catalog experience and clustered what we found. Three problems kept surfacing.
01Nowhere for agentic work to show up.
“If agent performs task/autonomous task, we don’t have way to show that in activity panel yet.”
Stewards had no way to see what the system had done on their behalf, or trust it.
02No way to see a change before it happens.
“Not informed of unsupported assets until after completing action.”
Bulk edits ran immediately; if something was wrong, a steward found out from an error message after the fact, not before.
03No sense of what needs attention.
The catalog was a place you searched, not a place that told you anything. Nothing was prioritized; everything had equal visual weight.
The heuristic evaluation: the existing catalog, screen by screen, annotated with what we found. The “Lack of information” cluster, where the first two problems and both quotes came from. The rest of the board. The third problem came out of “Clutter reduction.”
04Point of view
The catalog shouldn’t be a place a steward goes looking for problems—it should be the thing that finds them first.
05The flow
One path, designed to the last state: a new regulation arrives, the steward reviews and approves a bulk classification change, and the affected assets come back into compliance.
AThe catch
Instead of a search bar, the steward opens straight into what needs their attention. The top issue is already surfaced: a new policy takes effect tomorrow, and it will make 304 assets non-compliant, caught by the agent before it happened. There’s still time to act.
BThe plan
Clicking Remediate doesn’t run anything—it opens the agent’s proposal: a Biometric classification applied to a set of assets matched against criteria pulled straight from the policy, the sources, owners, and data classes involved. Nothing executes until the steward approves it.
WhyAn agent that acts without showing its reasoning isn’t trustworthy, no matter how correct it is. Preview before commit is the whole point.
CThe fix
Once approved, the change runs and the domain updates in place—data quality returns to stable, the projected drop gone, cause and effect visible in the same view.
DThe paper trail
Every stakeholder on an affected asset was notified automatically as the change happened. The Activity Center holds a record of what was changed, by whom, and why—so the work is auditable, not just completed.
WhyThis is where trust actually gets built. An agent-assisted action only feels safe if someone can go back and check it later.
EThe payoff
Downstream, the 304 assets are ready to use again. A data consumer browsing the catalog can tell at a glance that this asset is fresh, compliant, and protected—work a steward did that’s otherwise invisible, made visible here.
06Craft notes
A few decisions worth calling out on their own, since they’re easy to miss watching the flow once.
The headline is serif, everything else isn’t.
The critical issue statement—the thing the steward reads first—breaks from the sans-serif UI around it. A small typographic signal that this sentence is different in kind from the rest of the interface: not a label, a message.
The plan is a sentence, not a dashboard.
“Assign Biometric to 304 assets” is editable inline, in natural language, rather than a form full of fields. The steward doesn’t need to configure this action—they need to understand it.
Motion carries the causality.
The chart doesn’t just update after the fix runs—it visibly recovers, in the same view, in the same session. That animated recovery is doing real work: it’s the difference between “the system logged a change” and “I watched this get fixed.”
07Trust and agency
The hardest design problem in this flow wasn’t the UI—it was calibrating how much the agent should be trusted to do on its own. A few principles we held to throughout.
Approval is a real gate, not a formality.
The agent never acts unilaterally. Before anything runs, the steward can explore the plan, revise it with the agent, or simply approve it—but nothing executes without that step.
Reasoning is available, not imposed.
Which sources, owners, and data classes matched the policy is something the steward can drill into—not something thrown at them all at once. Progressive disclosure keeps the plan readable while keeping the full reasoning one click away for anyone who wants to check it.
Nothing happens quietly.
Every stakeholder on an affected asset gets notified the moment a change lands, and the Activity Center keeps a permanent record.
The agent explains its confidence, not just its output.
On the asset details page, the insight line—“well suited to prescription pattern analysis due to biometric classification, recent steward oversight and high data quality”—states its reasoning in plain language, not a score with no context.
08Process
Designing the data quality chart
The chart is the first thing a steward sees, so what it emphasized mattered more than what it contained.
The first direction tinted the entire projected region and carried a confidence interval around the forecast. Both were doing the wrong job: the tint made the whole future feel uniformly alarming, and the interval added visual noise around a number that isn’t the point. A steward doesn’t need the margin of error—they need to know they’re about to breach.
The iterations in between dropped the tint, then added the threshold the projection is measured against. Stretching the range to a month made the interval’s problem obvious: it only grew wider.
The direction that shipped dropped the confidence interval and the full-region tint, and highlighted only the gap between the threshold and the projected value. That gap is the story: the distance between where data quality is heading and where it’s allowed to be. Hover states surface the exact delta at any point along the line.
Why it matters: same data, same chart type, completely different argument. One shows a trend; the other shows a violation.
Sketch to lo-fi
My early sketches worked through the notification side of the flow: what happens after a steward acts, and how the people affected find out. The structure was an Inbox and an Outbox—tasks coming in, changes going out—which carried through to lo-fi almost unchanged.
Both halves survived into the final design. What changed was that they stopped being two separate destinations and became one: the Activity Center, with Inbox and Outbox as tabs inside it. Same two-sided model, consolidated into a single place a steward can check rather than two they have to remember.
Loading state explorations
Applying a classification to 304 assets isn’t instant, so the waiting state needed to be a real screen rather than a spinner. We explored several: a completion ring, a task checklist against a live asset list, a minimal centered progress bar, and versions that kept “Explain recommendation” and “Stop” available mid-run.
The version that carried forward kept the steward oriented without demanding attention: what the system is doing, roughly how long it will take, and permission to walk away.
From as-is journey to one flow
We started by mapping the existing experience across every persona who touches the catalog—data providers, data consumers, admins—through setup, maintenance, and consumption. The data steward came out of that as the persona whose work touched the most of it.
From there we pulled the steward’s path out into its own storyboard, then expanded that into a full flowchart of every route through the catalog available to them. That map is deliberately sprawling; the point of it was to see the whole surface before choosing.
We picked one path to design against: a new regulation arrives, the steward reviews and approves a bulk classification change, and the affected assets come back into compliance. Everything in the prototype is that single path, designed to the last state.
As-is journeys across every persona. The full flow exploration: every route available to the steward, as evidence of scope more than something to read.
09What I’d do next
This was a three-week concept sprint, which means a lot of it is unproven on purpose. Three things I’d want to resolve before any of it became real.
01Validate the pattern with actual stewards.
What we built is one specific example—a policy change triggering a bulk classification. The open question is which of a steward’s recurring processes are worth surfacing in natural language at all, and how much granularity they actually want the agent to have. I’d also want to know which statistics earn their place in each context: on the domain overview, during an update, and on an individual asset.
02Design the failure states.
We designed the path where the remediation works. We didn’t design what happens when it partially fails—when 280 of 304 assets update and the rest don’t, or when the agent’s criteria turn out to be wrong after the fact. That’s where trust in an agentic flow is actually won or lost, and it’s the most obvious gap in the current prototype.
03Scope what’s buildable, and in what order.
The brief explicitly asked us to set feasibility aside and design the target experience first. That was the right call for a vision exercise, but it means none of this has been costed. The real next step is working with engineering to identify which pieces are near-term versus which depend on capabilities that don’t exist yet—and whether there’s a smaller version that delivers most of the value.
10Credits
Ashley Bock, Emily Dowell, Perry Ting
IBM Knowledge Catalog, 3-week concept sprint
All organizations, assets, and data shown are fictional