🎬 Overview
This project introduces persistent conversation history into an AI Assistant platform used exclusively by licensed physicians. Currently, every session starts from scratch. No memory, no continuity, no way to return to a previous conversation.
The goal is to design a chat history experience that feels native to the product, works consistently across web and mobile, and gives users a reliable way to track, revisit, and build on past interactions without adding cognitive overhead to an already demanding workflow.
While the interface resembles a generalist AI chat, the content behind it is entirely different. All responses are curated specifically for physicians, backed by dedicated internal teams — including data specialists and medical professionals — who ensure the accuracy and relevance of clinical information. As with any AI tool in healthcare, the physician's own clinical judgement remains essential, and the product makes this clear through an explicit disclaimer.
Who is the user? 👩🏻⚕️
These physicians are power users with high cognitive load who interact with the assistant repeatedly as part of their daily workflow. They need to trust the product to remember what matters — making conversation history a natural extension of how they already use it.
The AI Assistant platform — web and mobile.
📚 Context
The AI Assistant is already in active use across mobile, web, and a Chrome extension. Users are engaged, but every conversation exists in isolation. There is no way to return to a previous session, no record of past queries, and no continuity between interactions.
The absence of history isn't a minor inconvenience. For users who rely on the assistant daily, losing context between sessions means re-doing work and re-asking questions they've already answered.
Without a way to revisit past conversations, the product can't support the kind of continuity physicians expect from a tool they use repeatedly.
📊 Why invest here
The AI Assistant is by far the most used feature on the platform. With this level of recurring usage, investing in features like conversation history becomes a clear opportunity to deepen the product's value for its most active users.
Platform feature usage — the AI Assistant consistently leads across the product. Other feature names blurred for confidentiality.
🔍 Core Problem
The AI Assistant has no memory.
Every session starts
from zero.
Users build clinical knowledge and refine queries through repeated interactions, but the product can't retain any of it. Each new session erases the previous one. For physicians relying on the assistant as a daily clinical tool, this isn't just friction: it's a meaningful gap in the product's usefulness.
The AI Assistant before chat history: no sidebar, no way to return to previous conversations.
No way to return to a previous conversation or build on past context
Repeated queries increase friction for returning users
No mechanism to review, export, or organise past interactions
The platform feels transactional rather than continuous, limiting long-term trust
🎯 Design Challenge
This wasn't a blank canvas. The product already existed on web and mobile, with established layouts, components, and interaction patterns. The challenge was to introduce a new capability that felt like it had always been there, without breaking what already worked.
Work consistently across web and mobile without duplicating interaction logic
Respect the existing product's layout, components and visual language, including an existing floating button on web
Introduce management actions (rename, delete, highlight) without cluttering the interface
Handle empty states, confirmations and feedback with clarity and care
Scope a true MVP: ship core value without over-engineering phase one, and make explicit decisions about what to leave for later
Design within a shared web app container used across platforms, with custom components instead of native components
Platform constraints
This feature runs as a web app, not as a native component. On both web and mobile, the interface lives inside a fixed container shared across platforms. This meant all chat history features, actions, and navigation had to be designed within that container, with no freedom to extend beyond it.
On mobile, native iOS/Android components couldn't be used in most cases. UI elements had to be built from scratch as custom components. This raised a key structural question: should the app replace the native top bar with a custom one to fully integrate the new navigation model — or keep the native bar and adapt around it?
These constraints were continuously aligned with the engineering team to ensure every design decision was technically feasible within the product's architecture.
Full-page layout — free positioning, not feasible within the product's architecture
Shared container — all features designed within the web app boundary, consistent across platforms
🛠 Process & Decision
Working in hi-fi from the start
Because the product structure is already well-defined on both platforms, low-fidelity sketches would have added little value. I moved directly into hi-fi wireframes, exploring within the actual interface constraints, with real components and real content. This approach compressed the feedback loop with engineering and made alignment conversations more precise.
Before touching the product, I mapped how leading AI tools handle conversation history, analysing patterns in sidebar placement, list behaviour, contextual actions, empty states, and cross-platform consistency. This grounded the direction in established mental models while identifying where the existing product could do it better.
Benchmarking: mapping established patterns across leading AI tools.
Web hi-fi wireframes: chat history flows.
The mobile decision: Option A vs B
On mobile, introducing the history sidebar required a structural decision about the top bar, one that couldn't be deferred. Two directions were evaluated in parallel, each with distinct UX, engineering, and rollout implications.
Option A
Update required: Custom top bar
Replace the native iOS/Android top bar with a custom bar aligned with the design system. History sidebar integrates fully into the new navigation model.
Pros
- • Full control over visual hierarchy and UX consistency
- • Cleaner, more coherent interaction model across platforms
- • Better use of screen real estate for primary AI actions
- • Standard AI pattern (sidebar + top bar actions) improves discoverability
Cons
- • Requires users to update the app to access chat history
- • Short-term split between updated and non-updated users
- • More engineering and QA effort (native bars, safe areas, gestures)
Option B
No update: Native top bar kept
Keep the existing native top bar. History sidebar adapts to work below it, without occupying top-bar space.
Pros
- • No user friction: feature rolls out automatically
- • Avoids splitting users across versions
- • Lower engineering and QA overhead
Cons
- • Less control over visual hierarchy and UX consistency
- • Native bar limits vertical space and top-bar AI actions
- • Slightly non-standard chat history layout
Final considerations
Adoption vs experience trade-off: Option A improves long-term UX consistency; Option B minimises rollout friction.
Analytics impact: Option A needs tracking on update rates and feature adoption post-update; Option B needs tracking on discoverability and usage of the adapted sidebar.
Support/comms load: Option A may generate more user questions during rollout.
Future scalability: A custom top bar may make future AI features easier to integrate cleanly.
Option A: custom top bar with integrated chat history sidebar.
Option B: native top bar retained, sidebar adapted to work below it.
🏆 Recommendation
Option A: Update required.
After weighing both directions, I recommended Option A as the stronger path forward. While it introduces short-term rollout friction, the long-term gains in UX consistency, design control, and scalability made it the more sustainable choice. The native update pattern also provides a natural communication moment to introduce the new feature to users.
MVP scoping (MoSCoW)
A key part of the process was deciding what goes into phase one and what gets deferred. The MoSCoW framework made these trade-offs explicit and aligned with the team.
Must
- Multiple simultaneous chats
- Persistent conversations (login-tied)
- Sync across devices
- Conversations ordered by date
- Reopen and continue old chats
- Permanently delete a conversation
- GDPR compliance
Should
- Auto-generate title from first prompt
- Rename conversation manually
Could
- Search / filter by keyword
- Star or pin conversations
- Share via secure link
✨ Final Solution
The solution introduces a conversation history panel integrated into the existing sidebar on web, and through a custom navigation model on mobile. Interaction logic is consistent across both platforms: the same mental model, adapted to each environment.
History list
Conversations grouped by date, auto-titled from the first prompt, ordered most recent first. Clean by default, with actions staying out of the way until needed.
Rename
Inline rename via contextual menu or double-click on title (web) / long-press (mobile). Toast notification confirms the change.
Delete
Permanent deletion with a confirmation modal to prevent accidental loss. Toast notification on success. Returns user to empty state or remaining list.
Highlight
Mark important conversations for quick reference. Follows the platform's existing favourite pattern for consistent visual language, with no new mental model required.
Empty state
A clear, helpful zero-state before any history exists. Guides new users without adding visual noise for returning ones.
Search
Scoped to a later phase, but the architecture accommodates it. The "Could" that becomes a "Must" once history volume grows.
The guiding principle throughout was: management actions stay out of the way until needed. The history list is clean by default, with actions surfacing contextually through a mini-menu on hover (web) and long-press (mobile). The same logic, the same clarity. Two platforms, one mental model.
🔗 Links
Final solution: web.
Final solution: mobile (Option A).
💡 Key Learnings & Next Steps
Impact Framework (Post-Launch)
As the feature is currently on the roadmap and not yet in development, live performance data is not yet available. Success will be validated against:
- Session continuity rate (do users return to previous conversations?)
- History feature engagement (rename, delete, highlight usage)
- Search demand signal (validates the Could → Must evolution)
- App update adoption rate (Option A-specific)
Strategic Takeaways
When a feature already exists, hi-fi wireframes aren't a shortcut. They're the right tool. They collapse the distance between exploration and implementation.
MVP scoping is a design decision. Choosing what not to build in phase one is as consequential as what you do build.
Platform constraints shape product decisions. The mobile top bar question isn't a styling choice. It's an architecture decision with real downstream effects.
Consistency across platforms matters more than feature parity. Same mental model, native interaction patterns per device.
What comes next
Search & filter — find past conversations by keyword as history volume grows
Projects — group conversations into projects for better organisation and context
This would likely require revisiting the current chat structure, moving from a fullscreen bottom sheet to a full-screen layout to make the most of the available space.
Document upload — allow users to insert their own documents for more personalised, context-aware responses
Share via secure link — enable physicians to share specific conversations with colleagues
Thanks for scrolling! ☕
If you made it this far, you've earned a coffee. Let's grab one together.