What an AI sales tool taught me about trust and adoption
MY ROLE ON THE PROJECT
I led product design on this project from early discovery through launch, working closely with Product, Sales and CSM to clarify the problem, understand how reps actually worked day to day, and define what a genuinely useful recommendation looked like. I owned the UX strategy, the interaction design, and the prototyping.
The business objective behind the project was tied directly to closing deals faster and reducing how much the sales funnel depended on SME bandwidth, both of which mattered for our 25/26 financial targets.
Sales reps closing B2B deals were losing momentum in the two weeks it typically took to move from a first conversation to an actual offer.
Three things were slowing them down. Many clients could not clearly articulate their own challenges, which made discovery calls inefficient and left reps without a structured way to turn a vague business need into a learning solution.
On top of that, a recent merger had tripled the content catalogue, and reps, especially new hires, struggled to keep recommendations consistent as they onboarded. And for most deals, reps depended heavily on subject matter experts to curate the right content, but SME availability was limited, so deals stalled whenever that support was not immediately there.
BEFORE AI CONTENT RECOMMENDER
Structuring what reps already knew, instead of asking SMEs to do it for them
To address this, I designed a recommender that let reps capture signals like industry, role, and challenges directly from a client conversation, get relevant content suggestions in minutes instead of weeks, and put together a first learning plan while the lead was still warm.
AFTER AI CONTENT RECOMMENDER
To support different working styles, I explored three input methods:
We launched with the guided flow first, to improve input quality and reduce risk.
Rather than launching all three at once, it felt safest to ship the guided Q&A first. Input quality was the thing the whole recommendation depended on, and this was the best way to reduce variability and prove the concept on more reliable data before opening it up to freer, and riskier, input formats.
The early numbers (first 8 weeks) looked like validation
Usage should have kept growing. Instead, it started to slip
As usage data came in, I noticed a gap between expected and actual behavior.
My first instinct, and the team's, was that this was an AI Output quality problem. When I looked at the usage data more closely, the pattern pointed somewhere else, toward user behavior and trust rather than the model itself.
One SME's behavior turned out to be the real signal
While reviewing usage logs and feedback, I noticed an unusual pattern from one of the curriculum specialists.
There was tension building more broadly too. The tool was meant to remove friction from the sales funnel, but some sales and SME stakeholders experienced it as something that reduced their control, and a few sales teams had already built their own informal AI workarounds before we launched, so they were resistant to replacing something that already worked for them.
There was tension building more broadly too.
The tool was meant to remove friction from the sales funnel, but some sales and SME stakeholders experienced it as something that reduced their control, and a few sales teams had already built their own informal AI workarounds before we launched, so they were resistant to replacing something that already worked for them.
I set up a 1:1 with the SME showing this pattern
Since he had not been engaging much in group discussions with product and engineering I tried talking to him solo and he was surprisingly open to talking to me directly.
That conversation surfaced the real issue: his concern was never that the AI was unreliable, it was that reps might lean on it without applying enough judgment of their own.
That reframed the whole problem for me.
SMEs were not only evaluating the system, they were also evaluating how reps would use it.
Trust in the tool was tied to trust in the user
Designing for trust and control, not just for accuracy
That insight changed what I chose to design next. Rather than focusing on optimize the recommendation itself, I designed for the system to check the completeness of a rep's input and flag whether a recommendation was safe to share as is, safe with caveats, or in need of expert review before it went to a client.
The goal was to balance speed with accountability, so reps could move faster while still being guided on when their own judgment, or an SME's, needed to be in the loop.
This kind of confidence tiering is close to how I think about responsible AI more generally: the value of a system is not just whether its output is accurate, but whether the person receiving it understands how much to trust it before acting on it.
To move this beyond a design exploration, I organized a working session with the SME, the Product Manager, and the Engineering Manager to align on the underlying trust issue directly.
That session shifted the conversation away from AI accuracy on its own and toward how we could support responsible usage and build confidence in how recommendations were actually applied.
Before settling on a solution, I weighed three different options for the recommednation card
Mandatory SME sign-off
The first was making SME sign off mandatory before any recommendation reached a client, which would have addressed the trust concern directly but reintroduced the exact bottleneck the project was meant to remove.
A simple confidence score
The second was simpler, just showing a match score or confidence percentage next to each recommendation. That would have been easy to ship, but it only offered surface level transparency. A number does not tell a rep what to actually do with it, and it does not address the SMEs concerns.
My choice: confidence label based on input quality
I chose the input completeness and confidence flagging approach instead because it kept reps moving quickly while still building in a real moment of judgment, rather than either blocking speed entirely or offering transparency that looked good without changing behavior.
The outcome was mixed, and I want to be honest about that
The direction I proposed resonated with the group, but it was never implemented. Adoption kept declining in parallel, driven by inconsistent support from sales leadership, reps' existing reliance on their own alternative tools, and a broader misalignment between the product and how teams actually worked.
The project was eventually deprioritized.
What I learned: adoption might depend on people, not just the design
This project reinforced that adoption of an AI product depends as much on organizational context and user behavior as it does on the quality of the solution itself. Early positive signals were not enough, because the system relied on behavior change, structured input and less reliance on SMEs, that needed stronger alignment across teams and leadership to actually hold.
Investigating the SME's feedback also taught me that trust in an AI system is not only about the quality of its output, it is about how confident the people around it feel in whoever is using it. Designing responsibly for AI means designing for appropriate levels of trust and control, not just better recommendations. And introducing one unified tool into an ecosystem where teams already had their own workarounds showed me how much resistance can come from ownership dynamics alone, regardless of how good the tool is, if that alignment is not addressed up front.
Check out more projects
From manual curation to self service: an AI advisor that grew adoption and retention
Enterprise learning relied heavily on admins to curate and assign training, which made personalization hard to scale. We used existing AI infrastructure to let learners create personalized learning paths based on their career goals, shifting learning discovery from an admin-led process to a more scalable, self-service experience.
63% adoption of AI-generated learning programs
70% retention on AI-generated learning paths vs. 24% on content library enrollments
Helping QA learners learn more confidently with an AI tutor built for trust
I led the end-to-end design of Ela, QA’s AI-powered learning assistant, transforming an inherited prototype into a trusted and scalable product in just two months. Designed to reduce friction and support learning momentum, Ela is now adopted by 80+ client accounts, holds a 4.5/5 satisfaction score, and has influenced the development of new AI capabilities across the platform.
4.5/5 Avg. Rating
1,178 Client Accounts
+34% Adoption Growth
From guesswork to guardrails: a panel redesign that cut client setup errors by 26%
I redesigned a complex admin tool used daily by Sales and Customer Success teams to configure enterprise client settings. The legacy system made critical errors easy. I rebuilt it around clarity, feedback, and safer workflows, reducing support needs and user stress.
Drop in support tickets tied to misconfiguration
New CSMs reporting higher confidence earlier
I redesigned QA's platform navigation to keep learners on track
I designed a universal sidebar to unify all content types during a major content merger. Learners can now track their progress without leaving the lesson, reducing distractions.
53% drop in users exiting lessons to track progress
28% reduction in fullscreen toggling to study
From hashtag challenge to a learning habit that lifted monthly cashflow by 18%
I designed a 3-month challenge that increased engagement, reduced churn, and boosted cashflow. 20% of participants stayed active three months after—well beyond typical subscription periods.
+18% increase in MoM upfront cashflow
1,178 Client Accounts
+34% Adoption Growth