IBM Knowledge Hub Redesign

KPH is where IBM Consulting's bid teams go to build proposals. It brings together case studies, past work, competitive insights, and design assets in one place.

In practice, that made it harder to use. Teams spent time searching through outdated content, unsure what was still relevant, and often recreated work that already existed.

The platform was used by thousands across regions, but it wasn't built around how they actually worked. Over time, more was added, but the experience didn't improve.

When IBM decided to migrate KPH to Lighthouse, it became an opportunity to rethink the platform around real user needs.

KPH is where IBM Consulting's bid teams go to build proposals. It brings together case studies, past work, competitive insights, and design assets in one place.

In practice, that made it harder to use. Teams spent time searching through outdated content, unsure what was still relevant, and often recreated work that already existed.

The platform was used by thousands across regions, but it wasn't built around how they actually worked. Over time, more was added, but the experience didn't improve.

When IBM decided to migrate KPH to Lighthouse, it became an opportunity to rethink the platform around real user needs.

Company

Company

IBM Consulting

My Role

My Role

Lead UX Designer

End-to-End

Duration

Duration

July 2025 - Ongoing

Platform

Platform

IBM Lighthouse

Carbon DS

Challenge

Two very different groups were using the same interface, and both struggled with it.

External stakeholders, like bid managers working against deadlines, couldn’t easily raise requests. The entry point wasn’t clear, the page was cluttered, and it was hard to know who to contact.

At the same time, the internal KPH team managing content and requests had their tools buried within the same interface. Even simple updates were slow.

The platform tried to serve both groups through a single structure, and ended up working well for neither.

Results

The redesigned KPH Lighthouse platform went live in November 2025.

It reached 1,970 followers organically, without any announcement or push campaign. Increased usage came from the platform being easier to navigate.

636 existing content items that were previously hard to find are now accessible through a clearer information structure.

For the 80+ core team members using KPH daily, tasks like finding content, raising requests, and managing updates became more straightforward and less time-consuming.

1.97K

Followers on the Lighthouse space

636

Content items now discoverable

80+

Core users. Zero workarounds.

Process

Research & Discovery

I started with a content audit of the existing portal, along with informal conversations with bid team members and internal KPH users. The feedback was consistent. People struggled to find content, internal tools were hard to access, and the platform lacked a clear structure.

I mapped primary user intents, high-friction interaction points, and gaps between what users expected to find and where things actually lived. That mapping became the foundation for every structural decision that followed.

I also reviewed other Lighthouse spaces within IBM to understand existing patterns and what users were already familiar with before arriving at KPH.

Information Architecture

Based on these findings, I made four structural decisions that shaped everything that followed.

The first was separating external and internal journeys entirely. Both groups were using the same interface and both were struggling, but for different reasons. External stakeholders couldn't find the Request Assistance entry point. Internal team members couldn't access their tools without navigating through client-facing content. One structure was failing two completely different needs.

The second was elevating Request Assistance from a buried header element to the primary CTA across all pages. High-intent actions shouldn't require searching.

The third was rebuilding the navigation hierarchy around how users think about content, not how the content was organised internally. Users should be able to anticipate where something lives before they look for it.

The fourth was applying Carbon DS consistently across every surface. Familiar patterns reduce friction. When users already know how a component behaves, they spend less effort on the interface and more on the task.

Wireframing & Prototyping

I started with low-fidelity sketches to define layout and hierarchy. The Request Assistance form was redesigned from a cluttered three-column layout into a simpler two-column flow. A "How it works" panel was added so users understood what would happen after submission, not just how to fill the form.

Usability Testing & Iteration

After launch, usability sessions were conducted with real users. Based on feedback, I refined navigation labels, improved CTA visibility, and adjusted content hierarchy. The platform continues to evolve, each iteration informed by how people are actually using it, not assumptions made at the start.

Visual Design

I designed all screens using the IBM Carbon Design System: tiles, data tables, notifications, and form inputs used consistently across KPH Utilities, My Requests, Contact Us, and the Request Assistance flow. Working within Carbon ensured consistency, aligned with familiar patterns, and made developer handoff efficient.

“ This looks great and is a significant improvement over the previous portal.”

SB

Shashi Bhushan

Associate Partner, IBM Consulting

Conclusion

Most of the key decisions in this project were structural, not visual.

Splitting the platform into separate journeys for external and internal users made it easier to navigate and reduced confusion across both groups. Elevating the primary action, rebuilding the navigation hierarchy, and applying Carbon DS consistently — each decision was made to reduce friction, not to add polish.

The redesign worked within IBM's existing system structures — which meant every decision had to be practical enough to ship, not just correct in theory.

This project reinforced that enterprise UX is less about visual polish and more about understanding how different users work, especially under pressure. Whether it was someone raising a request late at night or someone managing content internally, both needed a system that supported their tasks clearly.

The platform is live and continues to evolve. That ongoing work is part of the job. This project isn't finished, and that's expected.