Enterprise UX · AI · 2025
Sky - A Generative AI Assistant for Bank Advisors
Sky is a virtual assistant powered by generative AI, designed for a financial institution's advisors. It delivers fast, personalized sales arguments and a unified knowledge base, integrated directly into PIC, VOCE and the Single Frontend.
Role
UX Researcher & Designer
Client
Financial Institution
Timeline
2025
Samples
29 advisors (usability) · 167 survey responses
Skills applied
01 · Problem
Advisors were drowning in scattered information
Financial institution advisors needed to consult multiple systems and lengthy product documents to prepare a single client conversation. Information lived across PIC, VOCE and the Single Frontend, with no unified knowledge base or quick way to generate tailored sales arguments.
The cost was concrete: slower interactions, inconsistent messaging between advisors, and friction every time a client asked something slightly outside the script.
4.3
tabs per argument
Average open product tabs to prepare one sales pitch.
3
disconnected systems
PIC, VOCE and the Single Frontend, with no shared search.
~22s
copy-paste cost
Time lost per response moving text into the call script.
Concept · TO BE
Sky embedded inside the unified Branch front-end
María Rodríguez Pérez
ID 0042-118-9921 · Premium · Client since 2014
Customer
Premium
Commercial / Risk
A · Low
Personal / Work
Self-empl.
Financial
€ 84.2K
Advisor
Which mortgage offer fits a self-employed Premium client?✦ Sky
Hipoteca Variable Premium: Euribor +0.49% (TIN), TAE 3.21%. Bonifiable to +0.39% with payroll & insurance.
Source
Product KB · Mortgage Catalog 2025-Q2
Sky · Avg. response 1.2s · GenAI
02 · Process
Research-led, validated end to end
I led discovery and design across three phases: kick-off and context mapping, ideation of the AI assistant flows, and moderated usability testing with 29 real advisors.
- Stakeholder interviews to map daily advisor journeys.
- Heuristic review of PIC, VOCE and the Single Frontend.
- Concept prototypes for embedded vs. side-panel assistant.
- Moderated remote sessions with task-based scenarios.
- Iteration cycles informed by qualitative + behavioral data.
Two instruments, two samples
Qual and quant ran in parallel, so two sample sizes appear in this case study on purpose. Every observational finding is from the 29-advisor usability study; every percentage is from the wider survey (n = 167). They are never pooled, and each panel below is labelled with the instrument it came from.
Instrument 1 · Usability study
n = 29 advisors
Task-based, moderated sessions on the prototype. Purpose: see where advisors actually stall, and whether they will use a generated answer with a customer.
Output: Behaviour, friction points, trust conditions
Instrument 2 · Advisor survey
n = 167 responses
Structured survey to the wider advisor population, fielded alongside the sessions. Purpose: test whether the patterns seen with 29 advisors held at a larger n.
Output: Preference frequencies, placement and naming decisions
Limitation stated up front: the survey measures stated preference, not behaviour, and neither sample was randomly drawn, so the survey is used to check generality rather than to claim an effect size.
Research timeline
01 · Discover
Interviews, journey mapping, heuristic review
02 · Design
Concepts, prototypes, embedded vs. side-panel
03 · Validate
Moderated sessions with 29 advisors, iteration
03 · Research Insights
What advisors actually needed
Synthesizing interviews and test sessions surfaced four insights that anchored every design decision downstream.
- I-01
Context beats search
Advisors don't want a search engine - they want the right answer surfaced where they already are.
- I-02
Speed defines usefulness
If Sky takes longer than opening a tab, advisors will not adopt it during live calls.
- I-03
Trust requires traceability
Advisors need to see the source document behind any AI answer before they repeat it to a client.
- I-04
Tone is part of the product
Advisors trust answers that sound like a confident colleague, not a generic chatbot.
Field finding · 06
Opinion on the virtual assistant on the PIC front
How useful is having a virtual assistant?
29/29
rated it useful or very useful
“It makes it easier to have information in a single tool - we speed up service and avoid giving wrong information to customers.”
What should it be called?
02b · Method & Rigor
How the study was designed
A portfolio page argues the outcome was good. This section argues the method was sound: who took part, how they were screened, what they were actually asked to do, why the sessions were moderated, and where the evidence stops. Every design choice below traces back to a research goal, not a default template.
| Research goal | Method choice it forced | What that enabled |
|---|---|---|
| Measure real behaviour, not opinions | Moderated, timed task-based sessions on the prototype rather than interviews alone | Completion, time-on-task and error data, with live follow-up on why each failure happened |
| Know whether advisors would trust AI answers | A dedicated verify-the-source task and a confidence rating after every AI-assisted task | The central finding: trust was conditional on verifiable sources, which became the product's design principle |
| Separate preference from performance | A parallel 167-response survey kept strictly apart from the 29-advisor behavioural sample | Preference frequencies (like the maximize/minimize split) never contaminated behavioural findings |
| Know what to fix first, not just what to fix | Pre-defined success criteria per task and a severity scale applied to observed failures | A ranked issue list the design team could act on in one pass instead of a second study |
Recruitment
Participants were recruited internally through regional advisory leads, not volunteers from a single office. Quotas covered three seniority bands, five regions, and both branch and remote advisory roles so no one team's workflow dominated the sample. 34 advisors were invited, 29 completed every task.
Screening
A short screener confirmed each advisor held a live client book, had used the legacy reporting tool in the previous 30 days, and had no prior exposure to the prototype. Three respondents were screened out for being non-client-facing; two dropped for incomplete sessions.
Task protocol
Five timed tasks in fixed order after two warm-up tasks: locate a specific client's portfolio drift, explain a flagged allocation, answer a client question using the assistant, verify the source of that answer, and export a summary. Success was pre-defined per task; time on task, error events, and unaided completion were recorded.
Why moderated
The core question was about trust, not just speed, and trust shows up in hesitation: an advisor pausing before sending a generated answer to a client. That only surfaces if someone can ask why in the moment, so sessions were moderated with think-aloud and non-leading probes. The trade-offs are cost and scale, handled by keeping the protocol tightly scripted for comparability and fielding a parallel survey to test whether the patterns held at a larger n.
Two instruments
The 29-advisor usability study produced observed behaviour. A separate, wider survey with 167 responses produced preference frequencies. Different samples, different purposes, never pooled into a single figure.
Analysis
Session notes and open-text responses were coded into themes by two passes, a week apart, to reduce first-pass anchoring. Only themes raised independently by three or more advisors were carried into design decisions.
Limitations
- Results are directional, not statistically significant. With 29 participants the study can rank problems by frequency and severity; it cannot support confidence intervals or claims about the wider advisor population.
- Moderated sessions carry moderator and social-desirability effects: advisors knew they were observed, and stated reasons for behaviour are self-reported. Probes were scripted and non-leading to limit this, not to eliminate it.
- All participants worked at one institution, so organisational habits are a confound. Findings about advisor trust in AI answers should be re-tested elsewhere before being treated as general.
- Task order was fixed rather than counterbalanced, so later tasks benefit from learning effects and their times are likely flattering.
- Prototype data was synthetic. Advisors verified sources but could not judge whether an answer was truly correct for a real client, so accuracy perception is measured, not accuracy itself.
- Post-launch adoption figures reflect a period of active internal promotion. Sustained usage needs a later measurement without that push.
04 · Usability Issues
Friction surfaced during testing
Tasks were timed and observed across 29 advisors. The issues below appeared most often and drove the highest drop in task confidence.
| Issue | Severity | Pattern |
|---|---|---|
| Long AI answers skipped under time pressure | High | Nearly universal |
| No visible source on generative responses | High | Nearly universal |
| Manual copy-paste into call script | Medium | Frequent |
| Regional banking jargon mismatched | Medium | Frequent |
| Robotic tone reduces perceived trust | Medium | Common |
| Low-confidence answers shown identically to high-confidence | High | Common |
Field finding · 02
Frequency of searching for information to guide a client
Where they look (multi-select, 83 mentions)
- BCOM portal (sales arguments)21
- PDFs / PPTs in Contact Center16
- Bank's public website12
- Ask a colleague10
- Search in emails9
- CUC - Single Knowledge Center8
- Single experience site6
- Other (The Portal)1
05 · Evidence
What the sessions actually showed
Rather than post precise percentages from a 29-person usability study - which would overclaim - here are the patterns that repeated across sessions, ranked by how consistently they showed up.
Source: moderated remote sessions with 29 financial-institution advisors, task-based scenarios plus a short post-task survey. Bars show relative frequency across sessions - directional, not statistically significant at this sample size.
Field finding · 05
Should Sky have a maximize / minimize option?
Yes - keep maximize / minimize
132/167
No - keep it fixed
35/167
Why have it
- · Advisors choose how to view the screen for comfort - 38
- · Easier to view the offer and validate detail - 36
- · Best of both modes - 27
- · More organised, practical, accessible - 26
Why not
- · Want full view of customer info and query - 17
- · Practical to keep one fixed layout - 13
- · Avoid cluttering the screen - 2
06 · Design Decisions
A contextual assistant, never a separate app
Embedded, not standalone
Sky lives inside the tools advisors already use. No tab switching, no context loss.
Sales arguments on demand
Generative responses are framed as ready-to-use arguments, with source citations advisors can verify.
Trust through transparency
Every AI answer surfaces the underlying documents, so advisors stay in control.
Progressive disclosure
Short answer first, expandable detail second - matched to the rhythm of a live client call.
One-click insert
Approved answers drop directly into the active call script field.
Confidence flags
Low-confidence answers are visually marked and suggest escalation paths.
07 · How it works
From advisor question to cited answer, end to end
The assistant is not a chat wrapper. Every question flows through a pipeline that routes intent, retrieves from a unified knowledge base, generates a grounded answer, and requires the advisor to verify before anything reaches the call script.
01
Advisor asks
Question typed in the embedded panel while the call script is open.
02
Router agent
Classifies intent: product spec, fees, comparison, or objection handling.
03
Retrieval
Pulls from the unified knowledge base across PIC, VOCE, and product docs.
04
Grounded answer
LLM writes a short answer first with progressive disclosure and inline citations.
05
Verify + insert
Advisor confirms tone, edits if needed, then one-clicks into the call script.
Every generation is paired with a source chip so the advisor can defend the answer live on the call. This citation-first design turned scepticism into adoption during testing.
08 · Results
Validated with advisors, not yet in production
29
advisors tested
Moderated remote sessions with task-based scenarios.
3
platforms integrated in the prototype
PIC, VOCE and the Single Frontend, unified into one contextual panel.
1
shared knowledge base
Consolidated the product docs advisors were previously searching across separate systems.
What the sessions told us, in plain terms: advisors could find the product information they needed without switching tools, and the short-answer-first pattern with a visible source made them more willing to actually use the generated argument on a live call. I'm deliberately not publishing productivity percentages here - the pilot hasn't run at scale, and the samples were 29 advisors in a usability study plus 167 survey responses, not a rolled-out product.
The qualitative pattern was consistent: advisors trusted answers that showed their source, and distrusted the ones that didn't. That single finding drove most of the UI decisions above.
09 · Roadmap
From research insight to staged rollout
The findings shaped a phased delivery plan: ship the embedded assistant to a controlled cohort first, harden trust and tone, then expand to the full advisor network.
Q1 · 2025
Discover & frame
Done- -Stakeholder interviews · journey mapping
- -Heuristic review of PIC, VOCE & Single Frontend
- -Problem statement & success metrics agreed
Q2 · 2025
Design & validate
Done- -Concept exploration · embedded vs. side-panel
- -Moderated sessions with 29 advisors
- -Iteration on tone, sources & confidence flags
Q3 · 2025
Pilot
Done- -Sky moves from prototype to a controlled advisor cohort
- -In-product feedback loop and weekly tuning
- -Every answer must show its source before it ships
Q4 · 2025
Scale
Planned- -Rollout beyond the pilot cohort
- -Multilingual sales arguments (ES · EN · PT)
- -Manager view for accuracy and escalations
2026
Evolve
Vision- -Proactive next-best-argument suggestions
- -Voice mode for live call assistance
- -Continuous fine-tuning on verified answers
10 · Findings
Research findings, by theme
Filter the insights surfaced during research and testing with 29 advisors. Each finding pairs evidence with the design decision it shaped.
Usability
Advisors expect Sky to live inside their current tools
Evidence - Most advisors instinctively looked for Sky inside PIC before checking anywhere else.
Design impact - Embedded Sky directly in PIC, VOCE and the Single Frontend instead of a separate app.
Comprehension
Long AI answers were skipped under time pressure
Evidence - In simulated calls, advisors stopped reading long responses before reaching the useful part.
Design impact - Introduced a short summary first, with expandable detail on demand.
Workflow
Switching between product docs broke advisor focus
Evidence - Preparing one argument routinely meant opening several product tabs at once.
Design impact - Shared knowledge base surfaces sources in one contextual panel.
Trust & AI
Advisors will not use answers they cannot verify
Evidence - The most repeated question during testing was 'where does this come from?'
Design impact - Every generative answer shows its source document inline.
Comprehension
Banking jargon needed to match the advisor's region
Evidence - Mismatched terminology consistently caused misreads during task walkthroughs.
Design impact - Sky adapts product terminology to the advisor's market segment.
Workflow
Copying arguments into the call script was the slowest step
Evidence - Manual copy/paste was the visible bottleneck between reading and using an answer.
Design impact - Added one-click insert into the active conversation field.
Usability
Voice and tone need to feel like a colleague, not a chatbot
Evidence - Advisors described early formal responses as robotic and 'not something I'd say to a client'.
Design impact - Rewrote prompts to a confident, peer-to-peer banking voice.
Trust & AI
Uncertainty must be visible, not hidden
Evidence - When Sky guessed without flagging it, advisors lost trust for the rest of the session.
Design impact - Low-confidence answers are flagged and suggest escalation paths.
11 · Where this transfers
Expert internal users, and why the findings carry to developer tools
Bank advisors are not a consumer audience. They are a technical, expert user group working under time pressure, with real money on the line and almost no tolerance for friction. That is the same shape of user as a developer working inside a platform, an API or a console, so most of what this study produced transfers directly.
Trust is built from verifiable sources
Advisors refused to use answers they could not check. Developers behave the same way: they need transparent error states, request traces and documentation they can verify before they trust a tool in production.
Expert users optimize for speed, not hand-holding
Advisors wanted the short answer first, with detail on demand. Developer tooling has the same hierarchy: the working snippet first, the conceptual explanation underneath.
High-stakes work needs visible confidence
Confidence flags and source labels let advisors decide when to double-check. In developer products the equivalent is explicit versioning, deprecation notices and honest failure messages.
Research methods are domain-independent
Screened recruitment, task-based protocols, SUS scoring and theme-coded synthesis work the same whether the participant is an advisor, a developer or an integration partner.