Atlas: Designing Trust and Clarity for an LLM-Powered Employee Platform
Overview
RBC Assist is an internal AI-powered platform that consolidates search, task completion, and information retrieval into a single tool for bank employees. Instead of navigating fragmented systems across HR, risk, finance, and technology, employees can use natural language prompts to find answers, generate reports, complete forms, and access role-specific workflows.
I joined the project at the alpha stage and worked through beta and full live launch for multiple assists. I designed across the platform's core search functions and several role-tailored assists, partnered with compliance to ensure AI interactions met regulatory requirements, and presented work to directors and assist owners throughout the process.
Role: Product Designer (Alpha to Live Launch)
Duration: September 2024– June 2025 (Phased Rollout)
Team: 8 designers, 5 product managers, 8 engineers, compliance partners, and business stakeholders, including directors and owners
Platform: Internal enterprise AI platform used by RBC employees
Scope: HR Search, People Search, Application Search, and role-tailored assists across Risk, Finance, HR, and additional assists including Compliance and Technology & Operations
The Problem
Employees across the bank relied on dozens of disconnected systems to complete daily tasks. Finding an HR policy meant searching one portal. Looking up a colleague meant another. Accessing a risk report meant a third. Completing an HR form meant a fourth. Each system had its own logic, its own search behavior, and its own access rules.
The result was friction, duplicated effort, and time lost to navigation rather than work.
The business goal was to unify these experiences into one AI-powered platform where employees could type a question in plain language and receive a usable answer, a generated report, or a completed task.
The constraint: This is a bank. AI cannot be a black box. It must be governed, auditable, and honest about its limits. Every design decision had to satisfy users, compliance, and owners simultaneously.
Platform Struction
Atlas had two branches:
Search — HR Search, Application Search, People Search. Retrieval-focused. Find information fast.
Assist — HR Benefits, Risk, Finance, Compliance, Technology & Operations. Task-focused. Generate reports, complete forms, surface role-specific workflows.
Each assist launched on its own timeline and to its own audience. Some were in alpha with the project team. Some were in beta with select departments. Some were live bank-wide.
What I Designed
I worked from alpha through live launch on:
HR Search — natural language Q&A across HR documents. First to launch to production, bank-wide.
People Search — finding colleagues across the bank. Beta launch with Technology & Operations.
Application Search — finding internal tools and who owns them. Beta launch with Technology & Operations.
HR Benefits Assist — HR forms and benefits changes. Separate from HR Search.
Risk Assist — generating risk reports and charts from prompts. Alpha.
Finance Assist — retrieving financial reports, transcripts, and charts. Beta with senior finance stakeholders.
I also built platform-wide patterns for access gating and AI trust that applied across all assists, including Compliance and Technology & Operations.
Working Context
This was a fast-moving project with many designers, product managers, and stakeholders working in parallel. Information moved quickly and sometimes got lost. I worked across multiple assists at different times, and it wasn't unusual to return to an assist after a week and find something had changed — a stakeholder had shifted direction after a single meeting, or a PM had made a call without design in the room.
Assist owners had high expectations, which was fair given what the platform promised. But the backend often couldn't deliver what they wanted. We held sessions to find compromises, because overpromising was not an option — if we designed something the backend couldn't support, we'd ship a broken experience.
The work was less about having the perfect answer and more about keeping the design honest, current, and buildable while the ground kept shifting.
Four Design Decisions That Mattered
1. One chatbox that couldn't exist → help/ assist selection
The vision was a single chatbox that would automatically route any question to the right assistant. The backend couldn't reliably determine what users were asking about, as too many topics overlapped and jargon could have different meanings across departments.
The decision: users select an assist/search first, then ask within it. More friction upfront, but more reliable and transparent results. A persistent header reinforced which assist each conversation belonged to — helping users who returned after time away, wanted to refer back later, or needed to separate and find different topics across assists. This became the platform's foundational interaction model.
2. Trust without distrust
The AI hallucinates. Users need to verify. I designed AI-generated labels, source citations, and disclaimers that signal uncertainty without making the tool feel unusable.
Citations and links let users go directly to the source and read it themselves. As with any search tool, especially that AI is rather new, users will always have some uncertainty and want to verify the information independently or explore it in more depth. The links also show users where the information lives, so they can find it again on their own.3. Access gating
Assists launched at different stages — some in alpha, some in beta, some in production. Access varied not just by department but by role within. Assist owners had different preferences: some wanted locked assists visible but greyed out so users knew they existed; others wanted them hidden entirely to avoid access requests during alpha and beta.
We ran conversations across assist owners. Preferences conflicted.
The final decision: assists do not appear at all unless the user has access. For users who discover an assist exists through other channels, the help forum includes a request-access path via email to admins.
This meant designing for the absence of information, not just the presence of a locked state. Users couldn't request what they couldn't see. The help forum became the deliberate escape hatch.
4. Designing around backend reality
The backend couldn't deliver results in a single pass. Flows went back and forth between frontend and backend to retrieve, generate, and validate information. Many of these workarounds were invisible to users but shaped the interface directly.
I designed flows that guided users toward their answer in a linear, predictable way — preventing them from looping back, losing their place, or confusing themselves by trying to re-enter a process midway. In some cases, this meant designing one-way flows where users couldn't return to a previous step once they had moved forward, because the backend state had already changed.
Loading states, progressive results, and error recovery made multi-step processes feel intentional rather than broken. The goal was to make constrained backend behavior feel like a deliberate product decision, not a limitation.
Impact
HR Search launched bank-wide inside the HR portal, appearing as a chatbot. Most users never knew it was the LLM-powered tool — the AI lived on a separate portal.
26% of employees used HR Search during benefits renewal
14% reduction in HR calls compared to the previous year during benefits renewal
Drove cross-department demand — stakeholders across the bank requested new assists, securing ongoing budget for the platform
Established a scalable framework for future Search and Assist streams
Reflection
I spent most of this project designing around things I couldn't see.
I couldn't see how the model worked. I couldn't see why the backend needed a flow to go one direction and not the other. I couldn't see what Compliance Assist actually did, and I didn't work on it. I often couldn't tell where the AI ended and the retrieval logic began.
What I could see was the interface — and that turned out to be the part that mattered most. Every constraint the backend couldn't solve became a design problem instead. The single chatbox failed, so the assist selection became the product. The model hallucinated, so citations and disclaimers carried the trust. The backend couldn't loop back, so the flow moved forward and users learned not to try.
I stopped thinking of the interface as a layer on top of the AI and started thinking of it as the place where the AI's limitations become a usable product. That's the part of this work I'd carry into any AI product, in any industry.