All work
AI UX Cortex Enterprise SaaS 2025

FDP AI

How I went from a strategic question about AI maturity to a shipped feature that helped the sales team win two enterprise deals before the code was in production.

Role
Product Designer
Timeline
~6 months
Shipped
December 2025
Team
Design, Product, Engineering

The problem

Rich data, conservative results

The Cortex Fan Data Platform centralises fan data for sports organisations into a single profile: ticket buyers, hospitality guests, app users, email subscribers. The Audience Builder let marketing teams slice that data into segments and send campaigns. But it required knowing which filters to combine, understanding the data model, and spending real time building segments manually.

Marketing managers at clubs like Arsenal FC and Formula 1 were sitting on rich, unified data and not getting the most out of it. The process was slow, the outputs were conservative, and a lot of commercial insight was being left on the table.

"The question was not whether to add AI. It was how to add it in a way that actually changed what clients could do. Not just a feature for the demo."

Design framing · FDP AI, Cortex 2025

Discovery

Four problems worth solving

I started with two cross-functional workshops with product and commercial leadership. We mapped the Audience Builder journey end to end, identified where users got stuck, and asked which friction points an AI layer could realistically address.

Speed to insight
Building useful segments required manual querying across multiple data sources. Teams spent hours on setup before they could evaluate if a campaign was worth running.
Missed commercial value
Clients weren't exploring the full depth of their data. Without knowing what to look for, they defaulted to simple, broad segments that underperformed.
No revenue forecasting
There was no way to estimate the potential value of a campaign before building it. Budget decisions were made blind.
Expertise barrier
Getting the most out of the platform required knowing the data model well. New users and non-technical marketers struggled to get meaningful results.

From the workshops we produced a prioritised list of AI features to explore. The highest value, most feasible starting point: a natural language assistant inside the Audience Builder that could query fan data, recommend audiences, and estimate campaign revenue.

Design and feasibility

Engineering shaped the design more than the brief

Before designing anything, I worked with engineering to understand what was actually possible. Key constraints: AI response time, reliability of natural language data queries, confidence scoring on recommendations, and how to communicate uncertainty without undermining trust.

The disclaimer visible in the final product came directly from those engineering conversations. Knowing the system's real accuracy ceiling shaped how we framed every output.

I ran the design process with engineers, not after them. Wireframes went in front of the team early. Each round surfaced technical constraints that changed the UX direction, and each design decision created new engineering questions.

01
Framing
Strategic workshops with product and commercial leadership to identify where AI was genuinely useful
02
Feasibility
Close collaboration with engineering around latency, NL query reliability and confidence scoring
03
Iterate
Wireframes with engineers from the start. Each loop changed both design and engineering direction
04
Validate
Beta with selected clients in production conditions, structured interviews after, then redesign and ship

Key design decision

Embedded panel, not a separate tool

The AI panel lives inside the existing Audience Builder rather than as a separate surface. Users go from a natural language question to a built audience in one flow, without switching context. A separate tool would have introduced a handoff step that broke the task's momentum.

AI assistant embedded in the Audience Builder

The AI assistant embedded in the Audience Builder, empty state and response state side by side

Beta

Real users in production conditions

Before full release, I worked with product to run a two-month beta with a small group of existing clients, free in exchange for honest feedback. The goal was to understand what actually happened versus what we designed for.

2
months beta with selected clients
Free
access in exchange for structured feedback
100%
of beta users interviewed after

I ran structured user interviews with every participant after the beta concluded. Sessions covered what they used, what they avoided, what confused them, and what they wished it could do. Findings were synthesised in Dovetail, clustered across sessions.

What we learned

Four things the beta actually revealed

None of these were obvious before users touched the product in real conditions.

Trust and transparency
Users wanted to understand how the AI arrived at a recommendation before acting on it. The reasoning needed to be visible, not just the output. A black box made them stall.
Revenue context was the hook
Estimated revenue per campaign was the most valued feature. Users said it changed how they justified campaigns internally, from gut feel to a data-backed proposal.
The data visualisation gap
Users wanted charts, not just tables. When the AI surfaced a trend, they wanted to see it before acting on it. Tables were for exporting, not understanding.
Thinking state confusion
The processing state during longer queries left users uncertain about what the system was doing. Uncertainty eroded trust faster than slowness did.

Redesign

Addressing each finding without reopening the scope

The second iteration targeted each of the four findings directly. Six weeks after the beta interviews, the redesigned version shipped.

Transparent reasoning
The thinking state now shows planning steps and SQL execution detail. Users see what the AI is querying before it returns results. The black box became a glass box.
Chart and table toggle
Every data response now includes a visualisation option. Users switch between chart and table depending on whether they need to read a trend or export precise numbers.
Revenue estimations built in
The AI proactively surfaces revenue estimates at 5%, 10% and 15% conversion rates. A manual calculation became an instant signal.
Clearer confidence signalling
The accuracy disclaimer is more prominent and contextual, helping users calibrate how much to trust a specific response before acting.
Chart and table toggle with revenue forecasting

Chart and table toggle with revenue forecasting built in

Redesigned thinking state showing planning steps

Redesigned thinking state with planning steps and SQL execution visible

Outcome

Commercial impact started before the code shipped

While we were still building it, the sales team took the prototype into two enterprise pitches. FDP AI was on the prospect wishlist. They won both.

Before shipping
2
enterprise deals won using a working prototype in live sales pitches
After shipping
Live
FDP AI shipped December 2025 with natural language querying, audience recommendations and revenue forecasting for all enterprise clients

"While we were still building it, the sales team took the prototype into two pitches. FDP AI was on the client wishlist. They won both."

Outcome · FDP AI, Cortex 2025

The process from first workshop to shipped product ran roughly six months. Two rounds of structured research, close collaboration with engineering throughout, and a beta that genuinely changed the direction of the final product rather than just validating what we had already decided.

The biggest design lesson: communicating uncertainty well matters as much as generating the right answer. Users who understood the AI's reasoning trusted it. Users who couldn't see the reasoning stalled. Transparent thinking states and clear confidence framing were load-bearing, not polish.

Tags

AI UX Natural language interfaces B2B SaaS User research Enterprise product Sports tech

Next case study

Fan Experience Platform
Gamified rewards SaaS · 50+ sports organisations
Read case study

Let's work together

Got a problem worth solving?

If you're building something where design matters, I'd like to hear about it.

jacopo.maio@gmail.com