Slack AI Search
Designing how the search AI on Slack's sales site talks- how deep it goes, how it shifts for the person asking, and when it hands off to a real person.
TL;DR
Slack.com had an AI chat nobody used. Its answers read like an FAQ page, so buyers Googled Slack instead of finding answers on the site. Over one semester, our nine-person team redesigned search for Salesforce, where the AI sits, how AI and traditional results share the page, and the chat that follows you when you check a source. I led the design direction: setting the research approach and steering the team through its concept rounds and final documentation.
Inside it, I owned one layer end to end: how the AI actually talks. Every call about what it says, how deep it goes, how it shifts between a small-business owner and an IT lead, and when it stops and hands off to a person.
Team
9 Designers
Salesforce Design Team
My Role
Lead UX Designer
Tools
Figma, Claude Code, Paper.design, React, Vite, Tailwind, Netlify
Timeline
4 months
(Aug ‘25 - Dec ‘25)
Impact
From testing with 6 target users and 14 buyer interviews:
Preferred by 6/6
All testers chose the AI's answers over the old link list when working through their real concerns.
Resolved concerns for 5/6
Reached a satisfying answer inside the flow, without leaving the page to hunt elsewhere.
Trusted
Heuristic review tested whether answers felt trustworthy and whether errors resolved cleanly and whether ratings landed at the top of the scale.
Frees Reps
Sales reps burn hours educating buyers who aren't ready. When the site answers those early questions well, buyers arrive at sales already informed, and reps get that time back.
Context
For 25 years searching a website worked one way but recently, that changed.
Since the beginning of the internet, searching for something has barely changed. Then ChatGPT and Perplexity taught everyone to expect an actual answer, not a list of links.
But Slack.com had not caught up. Its AI chat was flat enough that people ignored it and went back to Google.
One small-business owner in our research put it plainly:
Why can't I just google it? It's much easier and it gives me a short summary.
That was the project: how should search on Slack.com work now that people expect it to respond?
Problem Space
Almost everyone who lands on Slack.com is a potential customer thinking about the same question: is this worth our time and money? But who's asking varies, and so does what would convince them.
For our project, we focused on small-business owners and IT leads as our core user personas, as they make critical decisions to purchase software for their organization, and we had access to this demographic.
A static page with a one-size fits all answer is a trap
Small business owners want clear answers they can act on.
IT leads won't trust a word of it until they see the limits and the proof.
How does AI fit here?
An AI response can read the question and shape the answer to the person asking.
And when it genuinely doesn't know eg. custom pricing, region specific compliance, it can say so and hand off instead of dead-ending.
Problem Statement
How might we help different people get answers they can trust through AI supported search, so they can decide whether to buy Slack?
Design Highlights
The system came down to five patterns for how a reply gets shaped: how far it goes, when it shows a source, and when it steps back to a person.
SEARCH BAR
INTERACTION DESIGN
Guiding Discovery with Adaptive Search Prompts
The suggestions in the search bar change with the page you're on- product discovery questions on the Home Page and pricing questions on the Pricing page.
Design Decision
Instead of staring at an empty search bar, users get pre-written questions. This mattered because people stall on phrasing, not intent, so the page does that work for them.
DEPTH CALIBRATION
AI JUDGEMENT
Adaptive Complexity
AI calibrates its technical depth based on user input, mirroring plain language or providing technical specifics as needed.
Design Decision
Instead of relying on fixed depths or manual toggles, the calibration happens automatically. This mattered because toggles hand the work back to the user, but this way AI adapts on its own.
AUDIENCE-AWARE RESPONSES
CONTENT DESIGN
Adapting Tone to Intent
The AI infers the user's role based on their query, delivering plain, benefit-led answers for business questions and cited, specific proof for technical edge cases.
Design Decision
Instead of a one-size-fits-all tone, the system adapts to the implied persona. This mattered because business owners look for practical fit, while IT leads require verifiable proof, so the AI shifts its language accordingly.
GATHER BEFORE RECOMMEND
AI JUDGEMENT
Guiding Choices with Pre-Recommendation Prompts
Before generating a comparison, the AI asks clarifying questions about team size and needs, then recommends options using the user's words.
Design Decision
Instead of assuming users know what to evaluate, the system initiates a short back-and-forth. This mattered because most people don't know the criteria, so the AI does that thinking with them.
AI TO HUMAN HANDOFF
TRUST AND TRANSPARENCY
Preserving Trust with Seamless Human Handoffs
When there is no honest answer, the AI states what it cannot do and hands off to a human with the conversation history intact.
Design Decision
Instead of making a confident guess, the AI openly admits its limitations. This mattered because guessing breaks user trust, so the honest handoff became the safer design choice.
RESPONSE RUBRIC
Designing the rules was half the job. The other half was judging whether an answer was actually any good, so I built a rubric.
A line-by-line rubric that turns subjective "trustworthiness" into a measurable checklist.
It maps four distinct question types against strict success criteria, scored examples, and rationales.
Research Overview
As the team's lead designer, I set the research approach to understand how people search a sales site when deciding whether to buy, and where Slack.com was losing them.
How were people searching Slack.com?
I ran the site's UX audit and led two research sessions while teammates ran the rest. As a team, we did a competitor analysis of six platforms (HubSpot, Microsoft 365, ServiceNow, Asana, Google, Adobe) and conducted contextual inquiries and interviews with 14 decision-makers, from C-suite to small-business owners to team leads.
The finding was consistent: search and the AI chat ran as two separate systems, and neither answered the way people now expect.
Who were we actually designing for?
We started by examining broad search behavior, but soon narrowed our focus to small-business buyers mid-decision to keep the scope actionable.
Because workplace adoption involves both champions and approvers, we targeted the full purchase circle: Taylor, the business owner, and Eric, the IT lead.
Solving for this dual-audience dynamic shaped the rest of our work.
What did the research point to?
Our findings pointed directly to the response layer. Buyers know what they want to achieve but lack the search vocabulary, and they will only trust AI if it gives it to them straight.
Keyword Gap
Buyers arrive with a clear end goal, but translating that intent into the perfect search query is a major roadblock.
"No-BS" AI Rule
Users are highly skeptical of AI-generated content. They demand straight, verifiable facts and will abandon tools that feel untrustworthy.
Beating the "Black Box"
To build trust, I grounded our response rules in industry guidance (Nielsen Norman, Google PAIR, Microsoft HAX) and adopted Slack’s model of using clear, verified citations.
Evaluation
Concept testing with six target users proved that building a great AI tool isn't just about adding features, it's about knowing what to strip away and where we still need to learn.
Users leaned heavily on familiar patterns, preferring AI and traditional search results side-by-side. We actually scrapped a text highlighting feature after testers found it distracting, proving that testing drives subtraction just as much as addition.
We scored our flows at 89% against a custom heuristic* rubric.
Rather than framing this as a vanity "pass rate," we utilized it as a strict internal stress test to surface friction points before finalizing the design.
While our response rules are grounded in solid research, they need live validation. My immediate next step would be to watch real IT leads interact with the system to see how accurately the AI calibrates its depth based on their natural follow-up phrasing.
Reflection
The instinct every AI product fights is the pull to sound certain, and most of this project was about designing against it. A few things I'd still do differently:
Latency and pause: I designed what the AI says, but not what happens in the silence before it speaks. In a conversation, waiting feels like a system failure, making those thinking and streaming states hugely influence the experience.
Depth calibration: Relying on a follow-up message to gauge technical depth means the first answer often misses the mark. I would pull signals earlier from the page context and initial phrasing, much like search suggestions do, so the AI never falls a step behind the user.
The recovery turn: I have not designed a fallback for when the AI misreads intent. All the flows assume perfect understanding, but gracefully recovering from mistakes is also where user trust is won or lost.