Strong engineering capability. Real adoption barriers.

The original implementation demonstrated genuine AI capability — the engineering team had built a full, functional product. But working technology and usable technology are not the same thing. UX was brought in as a proof of concept: the client wanted to see whether a structured, user-centered approach could make the product meaningfully better. The answer was yes — but first, the gaps had to be named.

The gap between technical demonstration and enterprise usability was significant. Leadership and users alike could see the AI doing something interesting — but couldn't visualise how it would fit into real operational workflows, or trust what it was producing.

As a result, a technically complete product was stalling at the adoption layer. The engineering work was done. What it needed was a user experience that made it feel real — and usable — to the people who would rely on it every day.

UX direction that went beyond interface design.

I led the UX direction for the initiative, working closely with engineering teams and stakeholders to redefine how enterprise users interact with AI-driven knowledge systems. This was not primarily a visual design engagement — it was a strategic and structural one.

The engagement required balancing what the AI could technically deliver against what enterprise users would actually need — and finding the design layer that connected both.

The PoC had one answer shape. Users had four different intents.

The engineering PoC already returned plain English — language wasn't the problem. The problem was shape: every query received the same response structure, regardless of what the user was actually trying to do. Diagnosing that gap started with a direct question to stakeholders: what would you actually query this system for?

Sixteen prompts came back. Reading across them, four distinct intent types emerged — each requiring a fundamentally different shape of answer. The second input was GenAI design guidelines: established output patterns for different information types. Mapping the two together produced the design foundation for how the system should respond.

From chat interface to structured knowledge interaction.

The core reframe was conceptual before it was visual. The original system treated AI as a generic chat interface — you type something, it responds. That model works for consumer applications where the cost of a wrong answer is low. In enterprise environments, it creates friction, uncertainty, and distrust.

Instead, I introduced more structured interaction patterns designed for enterprise usage: progressive navigation through complex information, guided discovery of what the system knows and how to reach it, and output formats that communicate certainty alongside content.

Six design moves that changed how the system felt.

Each move addressed a specific gap between what the PoC demonstrated and what internal teams would need to actually use it — not just aesthetically, but structurally. The goal was to build the interaction layer that made the AI's technical capability reachable.

The same AI capability — a completely different experience.

The before/after is not about visual redesign. It's about the interaction contract between the system and its users — what the system communicates, how it communicates it, and what users are expected to do with it.

Before — Engineering PoC

Chat-only AI demonstration

• Open chat input — no guidance on what to ask or how to ask it
• No source references — users had no way to verify what the AI returned
• No interaction structure — navigation was entirely instinct-driven
• Unpredictable output format — hard to validate, act on, or share
• Access gaps were invisible — entitlement boundaries created silent dead ends
• No mechanism to act on or circulate what the system produced

After — Enterprise Knowledge System

Structured interaction model

• Prompts Gallery — contextual examples reduce the effort of formulation
• Incomplete queries surface refinement suggestions rather than failing silently
• Entitlement boundaries communicated, not hidden — users know what they can access
• Plain-English summary with expandable raw content — speed and depth in one response
• Every answer attributed — users can verify and build on what the system returns
• Structured feedback + Copy/Share makes the system part of the workflow

A PoC that earned stakeholder sign-off and a roadmap slot.

The engagement moved the initiative from a technically-led demonstration to a product direction leadership could evaluate and act on. The design was presented to stakeholders — the interaction layer made the AI's capability concrete enough to discuss, validate, and plan around. It moved to the product roadmap. The outcome wasn't a shipped product; it was a credible product direction where none had existed before.

The shift that mattered most wasn't in the interface — it was in how leadership understood the system's potential. When users could navigate it, trust what it returned, and act on what it produced, the conversation changed from "interesting technology" to "this is something we can build on." That's what structured UX direction delivered.

UX as the layer that makes AI enterprise-ready.

One of the most rewarding aspects of this initiative was demonstrating how UX can shape enterprise AI beyond interface design. The biggest shifts happened not in how the system looked, but in how it communicated — what it surfaced, when, and in what form.

In enterprise AI, the interaction layer is not decorative — it is the product. An AI system that users cannot navigate, trust, or integrate into real workflows will not be adopted, regardless of how capable the underlying model is. That belief shaped every decision in this engagement.