The problem

I was designing for content teams and product managers who own a large internal knowledge base — hundreds of IT-support articles covering things like VPN setup, device compliance, email migration, and security keys. Their pain, in their words:

• Content is reactive. Articles quietly go stale until a bad support contact or a missed service-level target forces a fix.
• Nobody connects the signals to content health. The support org produces a firehose of signal — tickets, chat transcripts, AI-assistant conversations, satisfaction verbatims — but none of it points anyone at which article is failing.
• Failures are discovered live. Frontline engineers find the gaps in real time, with a customer waiting, because a feature shipped with no documentation or a fix went out without the article being updated.

The through-line: the information needed to prevent these failures already exists — it’s just never routed to the person who can act on it.

Scoping under pressure

The full vision was a three-loop “flywheel”:

1. Reactive — mine post-contact data to flag broken articles.
2. Proactive — watch upstream engineering signals (change requests, maintenance notices, roadmaps) to flag content risk before a change ships.
3. Coverage scoring — a living health map of content by service area.

With one to two days, I made a deliberate call: build Loops 1 and 3 as a believable, end-to-end experience rather than mock all three shallowly. A prioritized fix-queue grounded in real evidence, plus a coverage map, is the part a stakeholder can actually feel. Loop 2 stays in the narrative as the roadmap.

What I designed

A four-area workspace. Here’s each area and the reasoning behind it.

1. The dashboard — the “fix this next” queue

The landing screen answers one question: what should I fix right now? A single headline alert makes the highest-severity work impossible to miss, above a prioritized list where each item is classified by a gap taxonomy I designed to match how the team actually thinks about failure.

Designing that taxonomy was the core IA work. “Broken content” isn’t one thing — missing, wrong, and inconsistent-across-portals each imply a different fix and a different urgency, so each earned a distinct label, color, and priority weight.

2. The evidence drawer — trust through receipts

The single most important design decision. An AI flag that says “this article is wrong” is easy to ignore; a flag that says “here are the three customer conversations where this article failed” is not.

Every recommendation opens a drawer showing the raw evidence behind it: the support case, the contact transcript, and the AI-assistant chats where the article failed to resolve the issue. I also designed a PII-safe export state — the portable export omits the underlying chats and case notes — because anything touching real customer data has to be handled responsibly, and showing that awareness matters to the people who’d approve this tool.

3. The article editor — close the loop without leaving

Flagging a problem is worthless if fixing it means bouncing to another system. So the editor lives inside the tool: inline editing with an AI-recommendations panel proposing specific changes alongside the live text, a “view live version in KB portal” link to compare against what customers currently see, and a deliberate “Publish this article?” confirmation — because publishing is irreversible and the moment deserves a clearly-worded gate.

4. The coverage heatmap — the zoomed-out view

The strategic view for content and product leads: a health map scored by service area — healthy, at-risk, or critical — so weak spots are legible at a glance, and it surfaces which topics are failing the AI assistant’s answers and which have no coverage at all.

The dashboard answers “what do I fix today?”; the heatmap answers “where is my whole content estate weakest, and where should we invest?” Two audiences, two altitudes — one connected system.

Design decisions worth calling out

• Evidence over assertion. Every AI claim is backed by viewable source conversations — the tool earns trust rather than demanding it.
• Severity drives the layout. The most urgent work is the loudest thing on the screen. Priority isn’t a column you sort by — it’s the visual hierarchy.
• Realistic content. I populated the prototype with authentic support articles and plausible failure transcripts, because in a stakeholder demo, real content is what makes the value land instantly.

Prototype

Outcome

Built in a two-day sprint, the prototype was compelling enough that the concept is now being pursued for further investment. It moved the idea from a pitch into something stakeholders could click through and believe.

The concept targets three outcomes: reduce content-related escalations by catching gaps before a service change lands, shrink the time from a service change to the corresponding content update, and eliminate “no article exists” moments for new feature launches.

What I’d do next

• Validate the priority model with real content authors. The severity weighting is my hypothesis; I’d test it against how authors actually triage.
• Instrument the recommendation-acceptance loop. Track which AI suggestions get accepted versus overridden and feed that back — a real flywheel that gets sharper the more it’s used.
• Design the trust ceiling. Decide where a human must sign off versus where the system can act autonomously, especially around auto-publishing.