SQL Bot
Project Details
Tool: Figma, AI prototyping
Company: LinkedIn
Platform: Embedded desktop tool
Time: 2024 Jan-Feb
Sole designer on the project, moving at a fast, exploratory pace to stand up an AI-assisted text-to-SQL experience. I owned the end-to-end UX and partnered with data scientists, ML engineers, infrastructure engineers, product managers, and internal analytics users on user research, workflow mapping, wireframing, and high-fidelity mocks.
This is a story about building trust in an AI agent.
An end-to-end design of a GenAI data insights bot that helps non-data experts access,
explore, and validate data with more confidence.
Overview
SQL Bot is an AI assistant built inside LinkedIn's enterprise SQL notebook. It helps product managers, analysts, and other non-data experts get from a business question to a trustworthy answer, without needing to be a SQL expert to do it.
The challenge was not only generating queries. It was designing an AI workflow people could trust in a production environment, where users needed to understand what the bot was doing, inspect its logic, and stay in control of the output.
Interactive prototype
SQL Bot prototype
Explore the working prototype of SQL Bot inside the Darwin SQL notebook.
Open prototype in new tabWhat you'll find in this case study
How I used interview and workflow research to uncover the real pain points behind the data access gap, instead of designing off assumptions.
How each decision, from guided query generation to explainable, reviewable output, was made to build user trust and confidence at every step, not just at the end.
How that trust takes shape in the actual UI, from the dataset selection card with certification signals to the step-by-step query review flow.
The problem
A data-driven org with a data access gap
At LinkedIn, high-stakes decisions happen every day. But the people making them aren't always equipped to get to the data themselves, so they turn to internal tools.
For routine questions, that works. Dashboards cover predefined answers. But the moment a question requires custom analysis, the system breaks down.
Users get routed to SQL workbooks, where you write code to directly query a database. It's a more flexible environment, but it comes with no guidance, no trust signals, and no safety net for non-technical users.
Most users aren't engineers. Landing in a SQL workbook with a business question and no support is where things stall. At that point, there are only two options: ask a data expert, or attempt it yourself. Asking creates bottlenecks and slows decisions down. Going solo means writing code with partial knowledge, and often no way to know if the result is even right.
Research
What I heard from users
Even with a tight timeline, I made space for research before touching any design. I partnered with our product manager to interview 9 PMs across the org to understand their biggest needs and pain points around getting trustworthy data insights to inform product decisions.
Before defining any direction, I wanted to understand how PMs were actually navigating the data landscape today, what tools they used, where the process broke down, and where they gave up and asked someone else instead.
The conversations surfaced something beyond what I expected. It wasn't just about SQL fluency. The frustration was deeper: trust, speed, and the invisible cost of depending on others for something that should feel self-serve. Every PM I talked to had a version of the same story, a question that should have taken minutes, but took days.
Key problems I identified
Those pain points pointed to three consistent problems that showed up across every conversation:
Difficulty constructing a trustworthy query
Lack of SQL fluency isn't the only barrier. Existing tools prioritize output over understanding, leaving users unable to verify what they're running.
Low confidence in finding the right data
Switching between tools to locate the right table and understand ownership makes it hard to trust what users actually find.
Uncertainty in validating output correctness
Queries are hard to verify. Users frequently run copied queries they don't fully understand, with no way to know when something's wrong.
Design the Solutions
Those research problems translated directly into product directions. Instead of asking one feature to solve everything, I framed the solution as three connected moves: guide users through query generation, embed search to surface certified data, and make AI output visible, explainable, and reviewable.
Difficulty constructing a trustworthy query
Guided, hand-holding query generation experience
Low confidence in finding the right data
Embedded search to find certified data
Uncertainty in validating output correctness
Make AI output visible, explainable, and reviewable
Each of these solutions helps users get to an answer. But looking back at the problems I identified, one challenge sat underneath all the others: getting users to actually believe the answer.
The core challenge was not generating answers, but building trust in them.
We can use other AI tools to generate results, but trusting the results independently remains the hardest part.
That became the product's north star. From there, the design principles started to take shape almost on their own: guide users through query generation, embed search to surface certified data, and make AI output visible, explainable, and reviewable. Putting those together, I realized what we wanted to build was an AI assistant guiding users through data discovery, SQL writing, and metric validation.
Designing for Trust
The core design work was about balancing speed and trust. I explored not only what SQL Bot should generate, but how it should guide users through query logic, how it should live inside the notebook workspace, and where the user should stay actively involved in decision-making.
Balancing speed and trust in query generation
I started by exploring how different interaction models impact user confidence when generating queries. The key tension: generating a query instantly felt fast but opaque, while a step-by-step approach felt slower but earned trust.
We landed on a step-by-step flow to build trust, walking users through the reasoning before producing a result. Seeing each step helps users catch wrong assumptions early and feel confident in what the tool is doing. But once that trust is built, users aren't locked in. They can switch to a faster mode and skip straight to the query when they're ready.
Grounding trust in the existing data workspace
Rather than ask users to trust a brand-new tool, we leveraged the trust they already had in the SQL workbook they used every day, embedding SQL Bot right alongside the query and output.
Users never had to jump between tools: they could start with a question, generate queries, and see outputs all in one place.
Empowering users to participate in query generation logic
Handing users a finished query outright was the fast path, versus pausing to ask which datasets to use. Instead of generating the query immediately, we designed the flow to guide users through selecting which datasets to use first, surfacing certification and popularity signals along the way.
Showing the bot's own checks, not just the answer
Trust didn't stop once a query was generated. Every SQL response includes a Verifications section confirming the tables exist, the columns are valid, and the syntax checks out, so users can see SQL Bot checked its own work before they run anything.
Turning a failed query into another trust-building moment
Queries don't always run clean. If there's an error running the query, whether SQL Bot generated it or the user wrote it themselves, a Fix with AI action explains what went wrong and offers a corrected query, so a failed run doesn't mean starting over.
Interactive prototype
SQL Bot prototype
Explore the working prototype of SQL Bot inside the Darwin SQL notebook.
Business Impact & Results
SQL Bot shipped, and this is how it actually performed once PMs across the org started using it.
95% of users rated results usable or better, with little to no rework needed to move forward. 53% of expert-reviewed responses were rated accurate in real user workflows. The tool reduced dependency on the Data Team, improving speed to insight and unblocking product teams. The work was also recognized beyond LinkedIn: our paper Text to SQL for Enterprise Data Analytics was accepted and presented at the Agentic AI for Enterprise Workshop at KDD 2025.
The launch went beyond the metrics. The team announced it company-wide through LinkedIn's internal Connect platform, and the response from users was genuinely positive. It was encouraging to see people who had struggled with data access for years feel like the tool was actually built for them.
Why This Matters in a Portfolio
- Designing AI for real work environments. The challenge wasn't generating answers. It was building a workflow people could trust, inspect, and stay in control of in a production environment where wrong data has real consequences.
- Balancing automation with user agency. Rather than optimizing for speed alone, we designed a step-by-step flow that earns trust before offering shortcuts. Users move faster when they understand what the tool is doing.
- Systems thinking applied to AI UX. SQL Bot was not a chatbot on top of data. It was a carefully integrated assistant designed around workflow fit, interpretability, and confidence in the output.
