01.
FabFunnel
How I turned a dashboard full of numbers into a tool that tells marketers what to do next - not just what happened.
ROLE
UI/UX Designer -(Collaborative)
DURATION
3-Month Sprint
PLATFORM
Web Application - SaaS / PaaS
TOOLS
Figma, Miro
PROJECT TYPE
Real Client Project
Completed under NDA. Screens are redrawn with dummy data. Metrics below are user-reported, not raw business data.
02.
Brief
Context, problem, and how I approached it
Snapshot
Media buyers running campaigns across Facebook, Google, and TikTok were spending most of their day waiting for launches and staring at dashboards that told them nothing actionable. FabFunnel set out to fix that: a platform that centralizes ad management, automates repetitive execution, and tells users what to do next instead of just what happened. The cost of the old way was real: inefficient spend, poor returns, and a team stuck on execution instead of strategy.
my Role
I was the UI/UX Designer, working alongside a Design Lead, a PM, and the CEO who originated the concept. The Design Lead set strategic direction; day-to-day decisions, component-level thinking, and delivery were mine. I built and maintained a modular component library through the sprint, so when requirements changed, a single update propagated across every screen instead of breaking consistency. That upfront investment kept paying off: every later iteration cost less because the system, not each screen individually, absorbed the change.
Outcome
Campaign launch time dropped from hours of manual setup to near-instant, and teams began running more tests in parallel as a result
Media buyers began setting automation rules at end of day and leaving the platform to run overnight, a clear signal the rules engine had earned trust
Scaling decisions that once required manually rebuilding a campaign now happen in a single click, thanks to cloning
Post-launch feedback asked for the quick actions, filters, and richer reports that had been designed but deferred, giving a user-grounded backlog for the next version instead of just validating the original direction
problem
"The reports just show numbers. I still have to figure out what to do with them myself."
Media buyers weren't short on data, they were short on direction. Every dashboard they used told them what happened, never what to do about it.
03.
Key design Decisions
Three design decisions defined this product. Each was made deliberately, with a specific user behaviour in mind.
Decision 1 — The dashboard: what to show and how
FabFunnel generates a lot of data across campaigns, platforms, and time. Showing all of it would make nothing feel important. Every metric was tested against one question: does this reduce a decision, or does it just fill space? Historical trends moved to a dedicated reports section, platform breakdowns became a drill-down instead of a primary element, and lifetime spend totals were cut from the main view entirely. What stayed: today's spend vs. budget, active campaign count, top campaign by ROAS, and a single alert flag for cost-cap breaches.
Everything else is one click away. A dashboard opened when a decision needs to be made now shouldn't have to compete with a report.
Decision 2 — Automation rules engine
Media buyers were manually checking performance all day, a constant load that left no room for strategic work. We considered tag-based templates ("pause if CPA exceeds ₹1,500" in one click), fast but too rigid for how variable real campaign conditions are. A condition-builder won instead, because it maps to how buyers already think: if [metric] exceeds [threshold], then [action].
The real challenge wasn't the logic, it was making that logic approachable for a first-time user without limiting an experienced one.
Decision 3 — Campaign cloning for rapid scaling
Scaling a high-performing campaign used to mean manually recreating its settings, slow and error-prone. Cloning replicates the full structure in one action, with room to adjust variables before launch. The decision that mattered most wasn't the feature, it was placement: the clone action had to sit right in the campaign list, not buried in settings, or it would go unused.
A feature only works if it's where the user already is when they need it.
04.
Reflection
The tension between data density and clarity was constant throughout, and progressive disclosure solved it: show the summary, let people drill down on demand. Testing happened later than it should have; at the wireframe stage it would have caught issues while they were still cheap to fix, and would have surfaced team lead needs on their own instead of getting drowned out by the more vocal media buyer feedback in shared sessions. Several UX enhancements got deferred under deadline pressure, the same ones users asked for again post-launch, which taught me to align scope with development at the wireframe stage, not after high-fidelity design is already done. Watching where users hesitated or what they ignored told a different story than what they said they wanted, a reminder that observed behavior and self-reported preference aren't the same data. The biggest lesson: information architecture is a UX decision, not a technical one. What you choose not to show matters as much as what you show.
"The shift from a team that manually monitored campaigns all day to one that set rules at night and woke up to results, that was the outcome worth designing for."
05.
PROCESS
The research, thinking, and considerations behind the 3 decisions above. Expand any section for detail.
