Product
AIRIAM — AI-powered, context-aware knowledge assistant (live: airiam.com)
AIRIAM · ENTERPRISE AI PRODUCT · DOCUMENT-GROUNDED KNOWLEDGE ASSISTANT
Designing Trust into Enterprise AI
How I designed AIRIAM — an AI knowledge assistant that turns internal documents into grounded, controllable conversations
Product UX and UI owner · 2026. Core product implemented; additional states and accessibility requirements are documented separately from production evidence.
- Zero-to-one product design for a live enterprise AI assistant
- User-controlled context with document-grounded answers
- A familiar chat interface with explicit source controls
The 30-Second Version
Documents → selected context → grounded answers
AIRIAM turns internal documents into a conversational system: users upload files, choose which ones the AI may use, and get answers grounded in those sources.
- Designed the product UX and UI — sign-in, AI Assistant, context selection, conversation and Knowledge Upload — shipped live at airiam.com.
- Defined the context-control model: the user sets what the AI knows before it answers, and can change that scope without losing the conversation.
- Built AI trust patterns into the UI: a persistent active-context chip with Change File / Remove, a visible RAG Search mode, and permanent calibrated-honesty microcopy.
- Kept the surface familiar so the new mental model is the scope control, not the layout.
Product Objective
Beyond the user problem, four business objectives shaped every decision:
- 01Make internal knowledge usable, not merely stored
- 02Reduce friction in knowledge retrieval across teams
- 03Create a scalable document-intelligence product, not a one-off tool
- 04Establish a differentiated enterprise AI experience against generic chat assistants
Project Overview
Year
2026 · zero-to-one through to live implementation
Role
Senior UI/UX Designer — product UX and UI
Category
Enterprise AI · retrieval-augmented document intelligence
Team
Founders and AI/backend engineering; I was the design owner
Core modules
AI Assistant (conversation) · Knowledge Upload (document base)
Tools
Figma (design, prototyping, QA) · Figma AI · Claude
Related work
Shufti Product Transformation — enterprise decision journey and global experience system
Ownership
So the boundary is unmistakable:
AreaWhat it coveredOwnership
UX architecture, interaction model, UI, states, microcopy
Both modules and the flow between them; the context-control model; composer design; visual system
I designed and owned this
Retrieval behaviour and AI architecture
Document processing, embedding, retrieval quality, model responses
Engineering implemented; I designed the interface around it
Product scope and priorities
Which modules shipped first, feature scope, release timing
Founders decided; I contributed recommendations
Implementation fidelity
Front-end build of the designed screens and states
Engineering built the product; I specified the interface and reviewed implementation fidelity
The Challenge
The product brief described knowledge scattered across PDFs, reports and internal systems. The design challenge was to help people find useful answers while making the source documents explicit. An assistant without access to those documents could not reliably answer questions about the organisation's internal knowledge.
The central risk was a confident answer with no clear connection to the organisation's source documents.
Product & Domain Discovery
A zero-to-one build without a research budget. No user interviews, usability tests or analytics existed. What informed the design:
- Founder and stakeholder discussions — the product vision, the target enterprise buyer, and what would differentiate AIRIAM from generic assistants.
- Existing workflow analysis — mapping how people currently retrieve internal knowledge: search, open, skim, repeat — and where the time actually goes.
- Competitor and product audit — reviewing how general-purpose assistants and document-chat tools expose (or hide) their sources and scope.
- Engineering and AI architecture constraints — working sessions on what retrieval could reliably do, and what the interface must therefore never promise.
- Document and retrieval workflow analysis — tracing the path from upload to processed to selectable to cited, which became the backbone of the state model.
- Accessibility considerations — contrast, focus and non-colour signalling reviewed as design requirements from the first component.
Reframing the Problem
The brief began with a chatbot for internal documents. Discovery led me to focus on source visibility: people needed to see which documents informed an answer and how to change that scope. I treated trust calibration as a design hypothesis to validate, rather than a measured user outcome.
So three questions had to be answerable at every moment: what does the AI know right now, where did this answer come from, and how do I change it. That set the objective — as simple as ChatGPT on the surface, a controlled knowledge system underneath.
Constraints
The constraints shaped the product more than any preference of mine.
Technical / retrieval
- Answer quality depends on what is retrieved — the interface must never imply certainty the retrieval cannot support
- Documents require processing before they are usable as context, so "uploaded" and "ready" are different states the UI has to distinguish
- Retrieval is scoped to selected sources, which makes selection a required step rather than an optional refinement
Product
- Two modules had to ship as one coherent product, not two disconnected tools
- The experience had to read as enterprise-credible while remaining immediately familiar
- The architecture had to hold as the knowledge base grows from a handful of files to an organisational corpus
User / UX
- The product brief called for a familiar conversation model with a short learning curve
- Context selection adds a decision before the first message; that cost had to be minimised and justified
- Users must be able to correct scope mid-task without losing their drafted prompt
Engineering / resource
- A small team: every designed state had to be worth its build cost
- Patterns had to be reusable across both modules rather than bespoke per screen
Time / scope
- Zero-to-one delivery meant the core loop shipped first; secondary states were specified for later build
- That sequencing is why this case study labels shipped and specified states separately
Comparing Three Directions
Three structural directions were explored in Figma, each judged against a named constraint.
Open chatbot over everything
What it wasIndex the whole corpus; the AI always answers from all documents
Outcome and whyRejected — scope is invisible, so a wrong answer is indistinguishable from a right one. Fails the retrieval constraint that the UI must not imply unsupported certainty.
Search-first with AI summaries
What it wasKeep search primary; AI summarises the results
Outcome and whyRejected — traceable, but preserves the find-then-read burden the product exists to remove. Fails the product objective of reducing retrieval friction.
Context-controlled conversation
What it wasUser selects documents as active context; answers are grounded in them; scope stays visible in the composer
Outcome and whySelected — makes source scope inspectable and correctable within the conversation. Accepted cost: one decision before the first message.
The Designed Experience
Five decisions carry the product, each visible in the shipped UI below.
01
Familiar entry. Greeting, one question, one composer. The learning curve is spent on the scope model, not the layout.
02
Context on the user’s terms. Attach a file directly or use Select Context to pick from the knowledge base. The chosen document becomes a persistent chip showing the filename and a content preview, with Change File and Remove on the chip itself.
03
Grounded conversation. With context active, answers come from the selected sources. RAG Search is a visible mode in the composer rather than hidden behaviour, and the permanent microcopy keeps confidence calibrated: "Airiam does its best to help, but it might not always be right."
04
A separate knowledge layer. Knowledge Upload builds the organisation’s document base, so files become reusable context rather than one-off attachments.
05
Continuity. Named conversations, history and New Chat keep long-running work organised without crowding the core surface.
States and Edge Cases
These cards describe the intended recovery and uncertainty states. The core product is live; this section documents design requirements and does not claim that every edge case is deployed.
No context selected
the scope situation is explicit rather than silently answering from nothing, with a path to Select Context.
Wrong file, safe recovery
Change File and Remove sit on the chip; correcting scope preserves the drafted prompt.
Uploading and processing
document status in Knowledge Upload distinguishes uploaded from usable-as-context.
Calibrated uncertainty
the honesty line is permanent, not a first-run popup.
Accessibility requirements
Design and implementation requirements. This case study does not claim a completed accessibility or WCAG conformance audit:
- Visible focus states specified for interactive elements in the composer and sidebar
- Contrast targets specified for the orange accent on light surfaces, including small text and icon-only controls; implementation checks remain outstanding
- Status and selection never signalled by colour alone — always paired with a label, icon or text
- Long-filename handling specified to keep Change File and Remove accessible
Key Design Decisions
- 01
Visible context
The active document is a persistent object in the composer
WhyThe user can always answer "what does the AI know right now?"
- 02
Editable scope
Change File and Remove sit on the chip itself
WhyCorrecting scope never costs the conversation
- 03
Grounded retrieval
Answers are drawn from selected sources; RAG Search is a visible mode
WhyRetrieval is inspectable rather than implied
- 04
Familiar conversation model
Standard chat layout and rhythm
WhyThe novelty budget is spent on scope control, not on layout
- 05
Explicit recovery
Designed states for no-context, wrong file and processing
WhyThe product behaves predictably at its worst moment
- 06
Separate knowledge layer
Knowledge Upload as its own module
WhyDocuments become reusable context, and the system scales with the corpus
Visual System
Generous spacing, soft contrast on near-neutral surfaces, charcoal for primary actions, and the AIRIAM orange reserved for identity and the moments that matter — active context, send, current selection.
Outcomes
What shipped
- A live enterprise AI product at airiam.com — sign-in, AI Assistant, context selection, grounded conversation and Knowledge Upload
- The context-control interaction model implemented in the product composer
- One visual and interaction language across both modules
Design outcomes
- A reusable interaction pattern for grounded AI — visible scope, editable mid-flow, explicit retrieval — transferable to any retrieval-based product
- A documented state model covering the no-context, wrong-file and processing paths, with build status separated from design status
- An architecture designed to support a growing document base, with scalability still to be validated in use
Future impact hypotheses — not yet measured
- That visible, editable scope improves trust calibration — users correctly judging when to rely on an answer
- That grounded conversation reduces time-to-useful-answer versus the search-and-read workflow
- That the familiar surface lowers the adoption cost of the context model
What I Would Measure Next
GroupMetricQuestion it answers
Efficiency
Time-to-first-useful-answer vs the search-and-read workflow
Does conversation actually beat search here?
Context adoption
Share of conversations started with context selected
Do users accept the extra decision the model asks for?
Answer quality
Grounded-answer acceptance vs correction or re-ask rate
Are the answers usable as delivered?
Recovery
Wrong-file changes and Remove frequency, and completion after them
Does scope correction keep users on task?
Trust calibration
Can users correctly state what the AI was and was not referencing
Is the scope model actually legible?
Knowledge base
Document upload growth and reuse of the same sources
Is the knowledge layer compounding in value?
Reflection
The interface’s job in an AI product is to make the model’s knowledge boundaries visible. Context management, retrieval design and state design all serve that. Familiarity is part of it — a conventional surface lowers the cost of understanding an unfamiliar system underneath.
What I would do differently: run early usability sessions specifically on the context-selection model, since it is the one extra decision the design asks of users, and instrument the product from day one so the trust patterns could be evidenced rather than argued.
In enterprise AI, trust is an interface decision you make at the start, not a disclaimer you add at the end.
