Healthcare marketers using Freshpaint’s Attribution feature had all the data they needed and no clear next step. Recommendation Cards was built to close that gap, surfacing a specific, ranked action every week instead of a table to interpret. Here’s how it was designed, and what happened after it shipped.
Context
Recommendation Cards is an AI-powered feature I designed at Freshpaint, inside Attribution, where healthcare marketers track ad performance and attribution credit across channels. Each card makes a specific claim, backs it with a number, and closes with a single recommended action, tagged by category (Channel Performance, Funnel & Journey, Budget, and others) so a marketer knows at a glance what kind of signal they're looking at.
Before I worked at Freshpaint, I designed Recommendation Cards, sort of by accident. The final stage of my interview process included a take-home design challenge: no mention of Recommendation Cards, no feature spec. Just a brief describing a healthcare marketing lead drowning in data spread across disconnected systems, unable to get a clear read on what was working without deep technical help.
The task was to design something that let that person explore their own data and act on it with confidence, however I saw fit.
The brief for the design challenge
I called my concept Pulse. The scenario I built centered on a marketing manager who didn't need more data, she needed more confidence in the data she already had. Pulse surfaced that confidence through a feed of insight cards that explained to her how her channels are performing and what to do about them in a way she can understand, act on, and share. The response to this concept was strong enough to become one of the deciding factors in getting me hired onto the team that owned this space. Then came the harder part: turning a concept into something real customers would trust.
Freshpaint customers were stuck sifting through three, four, sometimes five disconnected marketing sources, a browser tab open for each one, manually stitching the data together into a readable signal they could actually act on. For them, data wasn't the problem, they had plenty of it. What they didn't have was confidence in it, or a built-in way to back up a decision if anyone asked them to defend it.
Same campaign, same week. Three ad platforms, three different conversion counts
The reality of manually synthesizing several sources of data is that the margin for error is large, and small problems can go undetected for weeks. Traffic could keep flowing to one of a customer's marketing sources while the thing they actually cared about, a booked appointment, quietly stopped happening entirely, and without someone checking in constantly, that could go unnoticed while budget kept flowing toward it. By the time anyone noticed, a month of spend might already be gone, spent on something that was never going to convert.
Upon joining Freshpaint, I was assigned to the Attribution team and went straight into my first project: something the PM was referring to as "Insight Cards". The name sounded familiar, and the digging into the PRD confirmed why: this was almost the exact idea I came up with for the design challenge during my interview. Though this version was leaner. It called for a single card type instead of the three I'd pitched. Those three told a better, more readable visual story with the data and I wondered if that same pattern could earn its place here, if it actually held up against the real data model the Eng team was building.
The original, leaner Insight Cards referenced in the PRD
1
Getting started
Before pitching anything to the team, I needed to know if the single card type was a hard requirement, or if there was an appetite for telling a more interesting story through multiple types. I sat down with the PM and Eng team to find out. Our discussion revealed interest from both parties, especially after showing the deliverable from my design challenge. I got the green light to explore, and while Eng sized the lift for adding more card types, I turned to the data to see if it could actually back up what I'd proposed.
Two raw insights, two different structures, one open question: could I map my card types to these?
Efficiency Decline
Broken Signal
Efficiency Surge
Channel Win
Efficiency Gap
Portfolio Rebalance
❖ Category Badges V1 – my initial synthesis
The original six categories I was able to surface from the raw customer insights
Proposed: three card types
Agreed direction: one card type
Two directions from the design review: three distinct card types (single metric, comparison, recommendation), and the single recommendation card, with categories, that we ultimately agreed on
Budget
Portfolio
Channel role
Channel performance
Attribution
Funnel & Journey
Trend
Other
❖ Category Badges V2 – after refining with the data team
Six categories became eight after Data Eng checked my work against a larger dataset.
With that settled, I was ready to build. I connected Claude Code to the Figma MCP and built the design into a functional prototype, including a per-card drilldown drawer that surfaced the data behind each recommendation. When you're designing something meant to shape a user's decision, you need a trust layer, a way to explain how you landed on a recommendation instead of asking them to take it on faith. I also built in a feedback mechanism, a simple thumbs up or down on every card, so we'd have a direct signal on whether a recommendation actually landed. When it didn't, that same feedback gave us a way to improve the underlying model. With the prototype complete, I brought it back to the team for a final look. It got the green light, and we moved straight to booking user testing sessions.
We recruited a group of customers to put our assumptions to the test. Three questions sat at the center of it. Did they see it as a meaningful add? Did they trust the recommendations? And if so, what would they do with them?
Before each session, I preloaded the prototype with the participant's own data. Nothing they saw was hypothetical. Every recommendation was real.
07
Participants
03
Weeks of testing
02
Rounds of Testing
Positive
overall sentiment
What users said:
USER TESTING CANDIDATE 04:
"…There is nowhere else where you have this type of data. Neither of the ad platforms individually is going to give me this. Meta is certainly not going to tell you to cut budget, let alone where to send it to."
USER TESTING CANDIDATE 01:
"Is this my real data? Wow guys. I mean, this is a game changer. Honestly."
Key takeaways
Four pieces of feedback stood out from our sessions. Each one starts with what a customer told us, then the reasoning behind it, then what we did about it.
"I want to know which attribution model this is based on"
SHIPPED
Cards are filter-agnostic, so it wasn't clear which attribution model a recommendation was built on.
why we acted on it
Building trust in our recommendations was key to this succeeding. In order to do that, we needed to show our work.
"Is there a way to see which conversion events I've defined from here?"
SHIPPED
Users set their conversion events once during Attribution setup, then forget them. With no easy way to see which events a recommendation used, they had less basis for trusting it.
why we acted on it
Recommendations are AI-generated, so we wanted to show whats behind them. Surfacing conversion events is another step in helping the user judge a recommendation by its input, not just its output.
"Now, what I'm looking for is a way to do something about this. Is there a button somewhere in the drawer?"
DID NOT SHIP
A recommendation tells users what to do, and the next thing they ask is where to start. Users wanted the drawer to answer that by letting them act on the recommendation right there instead of figuring the next step on their own.
WHY WE SKIPPED THIS ONE
This was a good callout. Acting on a recommendation from the card would have shortened the path from insight to action, and it would have given us a direct signal on whether users followed our recommendation. But it was out of scope for this release, and we weren't yet sure how to build it well.
"One thing that would make this truly indispensable is being able to filter or change the attribution model or conversion event and have [the cards] update accordingly."
DID NOT SHIP
He wanted to pressure-test a recommendation by switching the attribution model or conversion event. If it held up under different settings, he could act on it with more confidence.
WHY WE SKIPPED THIS ONE
While appealing in theory, there was a technical constraint behind this one. Cards take about a full day to generate once data is ingested, so changing the attribution model or conversion event couldn't update them on the fly.
What shipped had more value than the original concept, and stayed simple by design. One card type. A drawer behind it for the supporting data. A thumbs up or down on every card, so feedback could inform how future recommendations are generated. Two details came directly from testing: the attribution model shown on each card, and the conversion events in the drawer.
Every element has a job
Category and headline make a card scannable. The attribution model and the action make it credible and useful. The thumbs are the one part built to teach us something, so we could see which recommendations people found useful.
1
1
2
3
4
5
Category
Claim
Attribution model
Recommended action
Feedback mechanism
Tags the signal type at a glance, before the marketer reads a word.
Category
Always show your work
The card makes a claim. The drawer shows the data and conversion events behind it, so a marketer can judge a recommendation by its input, not just its output.
Clicking a card opens the drilldown drawer, giving customers the supporting data and conversion events behind each recommendation.
Built for one event, or dozens
Customers track anywhere from one conversion event to over a dozen. I built a small panel to test the layout across that range, using real distribution data from Snowflake.
A quick tool I built to stress-test the conversion-event layout against real customer data, from a single event to over a dozen, so the design held up no matter how much or how little data someone had.
Following a round or two of design QA to confirm the execution matched spec, Recommendation Cards launched on schedule, on May 28th, 2026. We showed it off at that week's company all-hands, including clips from the testing sessions. We were excited to finally get it into customers' hands and see how they'd put it to use. Coming out of the retro, we set a plan to revisit the numbers in a month, to see how it was performing across our user base.
What we launched wasn't AI for the sake of having AI in the product. It closed a real gap in our customers' tech stack, giving them a view into their data they'd never had before: an unbiased read on how their initiatives were performing, and what to do about it. Best of all, it had already been tested and validated with real customer feedback and real user data, so we knew we were built something people actually wanted.
In accordance with the plan we'd set, the whole team kept an eye on the Looker dashboard over the following month. We tracked a few key metrics, starting with how many customers enabled AI, a required step before we could generate any cards for them. From there we watched engagement: card views, drawer clicks, and feedback submissions.
AI adoption was healthy. We saw it firsthand on customer calls too, watching them navigate to Attribution and land right on the cards. Engagement with the cards themselves told a different story. We'd set an early goal of at least half of all recommendations getting a thumbs up, a deliberately modest bar meant to confirm the model's output was useful before expecting anyone to act on it. We came in well under that. Card clicks were low, and thumbs up/down submissions were even lower. A couple of weeks in, we talked through the early numbers but held off on any real conclusions until the full month had passed.
Once that trend held, I started digging into why. I'd had some distance from the cards since designing them, which gave me a chance to look at the experience with fresh eyes. I ran through a few scenarios and landed on five hypotheses.
HYPOTHESIS #1
Low click rates might actually indicate cards are already doing their job.
The headline and recommendation may deliver enough value on their own, the drawer exists mainly for people who want the proof behind it. If click-through itself needed to be the success metric, the card would need to show less up front and require the click to unlock the full recommendation.
HYPOTHESIS #2
Low engagement with the thumbs up/down warrants direct user interviews, not just more data-watching.
Feedback timing may be part of it: cards regenerate weekly, so by the time a recommendation proves right or wrong, the card that prompted it is often already gone. Worth understanding when and why users actually would rate a card.
HYPOTHESIS #3
The card doesn't clearly signal it's clickable
While the card has a hover state, that alone isn't enough of a cue. A "View details" affordance on hover could make the interaction more obvious.
HYPOTHESIS #4
The moment someone forms a real opinion on a recommendation may happen inside the drawer, not on the card.
Duplicating the thumbs up/down there could catch feedback that never gets given on the compact view.
HYPOTHESIS #5
Card clicks and thumbs ratings might not be the right signal for real-world impact at all.
A better measure could be following up directly. A smart check-in system triggered by engagement, a click, a thumbs rating, any signal of interest, could prompt a follow-up a week later asking if they acted on it. It's also worth revisiting the action-button idea we passed on during testing: if we built it, clicking it could double as a signal that someone was ready to act.
Underneath most of these hypotheses is a bigger question, whether clicks and thumbs were ever the right thing to watch. Talking it through with our PM afterward, the real goal was never engagement for its own sake. It was giving people recommendations that move a metric they actually care about, something like ROAS. Clicks and feedback were a proxy for that, a way to check the model was landing before we could measure the real outcome. If the recommendations are useful enough that people just act on them without clicking through or rating them, that's not necessarily a failure. It might be the feature working the way it was supposed to.
At this point, I was fueled by genuine curiosity, eager to follow up with customers and dig into their experience with the cards. Before I could, Freshpaint was hit with a wave of layoffs, and unfortunately I was affected by it. I still think about how this one plays out, and I'd love the chance to find out.
Looking back, what stands out to me isn't the cards themselves. It's how consistently I let real data settle an argument instead of my own instincts. Almost every real decision in this project, from which card types survived to how many events might show up in a drawer, got checked against something real before it shipped. And that wasn't a one-off habit for this feature. It's become how I default to working. Data over assumption, every time.
There's also something worth saying about ending a story without a bow on it. Most case studies wrap clean. This one doesn't, and I'd rather leave it that way than force a resolution I don't actually have. In my experience I've found that good product work rarely finishes the moment the person doing it walks away. Mine just ended earlier than I would have liked.