DevNav Hub Catalog: Redesigning the IA So Developers Can Find What They Need
DevNav Hub centralizes the tools developers use across Capital One. Its Catalog, where every role goes to find and manage what they own, was hard enough to navigate that people gave up and looked elsewhere. I restructured its information architecture so each role can find what they need.
Highlights
Executive Summary
DevNav Hub centralizes the tools developers use across Capital One. Its Catalog is where teams track pipeline status, security posture, ownership, and production health for what they own, and it showed every role the same dense page. I restructured its IA around one repeatable pattern, prototyped in Claude and Figma Make, tested it with 15 users across 5 roles, and handed it to engineering as the reference spec for the Catalog's pages.
The Problem
Users couldn't find what they needed in the Catalog, so they went elsewhere: other tools, other teams, anywhere but here. Many different roles come to the Catalog, and each one wants different information and different actions. The old IA treated all of them the same. The real challenge was figuring out what those roles, information needs, and actions actually were, then organizing the IA so the right thing surfaced for the right person at the right time.
The Releases tab is a clear symptom. A compliance blocker capable of stopping a deployment sat several screens down, at the same visual weight as static links and raw repository URLs. A designer confirming a launch date and an SRE chasing a live incident landed on the same flat list of 7 tabs, in the same order.
User Insights
Before touching layout, I ran a role audit. What does a Builder need in the first five seconds? An Architect? Leadership? That mapping became the spine of the new IA.
- H1, Workflow Efficiency: personalized entry points should reduce time to action for core tasks versus a single undifferentiated homepage.
- H2, Comprehension & Consistency: the same page structure can serve every role without a meaningful rise in cognitive load, provided each view's purpose is clearly labeled.
Ideation
Testing confirmed the direction. It didn't discover it. Before anything went in front of users, the IA went through a few rapid rounds of concepting, stakeholder reaction, and revision.
Divergent concepts. Used Claude and Figma Make to turn a page skeleton into several structurally different directions in hours, so partners could react to real screens instead of a written brief.
Stakeholder review. Brought the roughs to PM, engineering leads, and architecture for reaction. Directions that didn't hold up against real workflows got cut here, before any pixel-level effort went into them.
Convergence. Folded that feedback into one structure, tightened around a single repeatable pattern instead of a different layout for every page.
IA alignment. Stakeholders signed off on the structure and routing logic before it became a testable prototype. Usability testing started from an aligned foundation, not an open question.
Claude and Figma Make let me prototype and test ideas with partners in hours instead of weeks. That speed was the biggest process shift on this project.
The pattern I converged on: Expose, Report, Direct. Applied identically to every Catalog page, component, Business Application, and team.
Expose
Identify the asset immediately: name, owner, lifecycle state, before anything else loads.
Report
A critical hero zone for anything actively blocking, above scannable health snapshots for everything else.
Direct
Granular configuration and logs live in tabs below the fold. One click away, never competing with the summary.
Usability Testing
With the structure agreed, I ran a moderated usability study: one week, 15 participants across five roles, checking the IA against real workflows before it reached engineering. Each participant started from their own entry point and worked toward the tab their role relies on most. Builders into CI/CD & Releases, SREs into Production Health, Architects into Dependencies & APIs.
The core IA held up across every role tested. The bigger surprise: participants asked for the same thing once inside individual tabs. Less static reporting, more direct action.
The Solution
Applied to a component page, the pattern turns a wall of equal-weight content into three legible zones. The highest-stakes information stops competing with static reference material.
Every zone traces back to a written rule in the IA spec, signed off before any pixels moved. Here's the reasoning behind four of the bigger calls.
Only show the alert when there's a blocker
The spec reserves the top of the page for anything actively blocking a deployment. When nothing is blocking, that space collapses to a minimal status bar instead of sitting there empty. In the old page, a blocked release and an empty table looked identical. Here the zone changes shape: a full alert when something needs action, one green line when it doesn't.
Same structure for everyone, personalized data within it
Every entity page (component, BA, team) uses the same zones, the same tabs, the same order, no matter who's viewing it. That consistency was one of the two hypotheses we tested for. The data inside those zones still reflects the viewer (your components, your alerts, your team), it's the layout that stays fixed. The homepage works differently: it's the one page built entirely around whoever is signed in, structure included.
Roll up metrics at the Business Application level
The spec defines this page as an aggregate view across all of a BA's components, surfacing domain-level rollups that don't make sense to show on a single component. A Product Owner thinks in whole applications, not single components. This page reuses the same three zones as the component page, just rolled up a level.
Give ownership its own page
The spec calls for four things here: Team Identity, Work & Delivery, Operations, Portfolio Health. It's the one page that isn't a rollup or drill-down of a component. It answers who owns this, a question the old flat-tab layout had no place for.
The Results
Usability score across the core IA, consistent across every role tested. The tab structure matched people's existing mental model well enough to leave in place.
Participants across five roles, validating the IA before it moved to engineering as the reference spec.
Raw vulnerability counts don't show what's urgent
Severity, due dates, and whether a fix was already in motion mattered more than the total.
"Assistance Engineers look at vulnerabilities to see who is remediating them and if an active pull request exists."Participant 6, Assistance Engineer
DevNav Hub needs to link out, not just consolidate
Technical roles stitch health together across several external dashboards. They'd consolidate into DevNav Hub only if it linked straight to the source the moment something looked wrong.
"If error rates are high, engineers will immediately leave the platform to investigate. They need deep links straight to the data source."Participant 13, Engineer (IC)
Blocked releases don't explain why
Releases were frequently canceled with no visible reason. Participants wanted the blocking cause surfaced directly in the release view, plus a shareable link for approvals.
Compliance widgets read as noise
Participants assumed active meant compliant and skipped past high-level compliance widgets. Surfacing lifecycle state explained the "why" faster than a metric could.
Next Steps
The IA held up. Testing surfaced three specific places where the content inside it needed to work harder, pinned to the exact screens they came from below. I turned those into concrete recommendations and walked them through with stakeholders. I left Capital One before launch, but handed the work to the designers on my team with everyone aligned on the plan.
1
Show severity and status, not just totals
Next version replaces the raw count with a severity-first list showing due date and remediation status inline, matching how engineers said they actually triage.
2
Add a reason when a release fails
Next version surfaces the specific blocking cause inline, plus a shareable link, so a canceled release doesn't turn into a hunt across three other tools.
3
Link metrics to their data source
Next version links each metric straight to its source dashboard. Participants were explicit: the moment a number looks off, they leave the platform anyway.