Platform
Responsive web app
My role
Director of Product
Reported to
CTO
Scope
Design + research strategy
The situation
SponsorPulse surfaces consumer insights and market intelligence for sponsorship decisions, a data-heavy, SME-driven product built by and for analysts. When I joined as Director of Product, there was no discovery process, no design system, and no shared design language across a platform that had grown through engineering-led iteration.
My scope: lead design and research strategy, reporting directly to the CTO.
The core problem
The platform had deep domain expertise baked in, but domain expertise and user needs aren't the same thing. SMEs knew what the data meant. Users needed to know what to do with it. The product was accurate. It wasn't usable.
What I owned
- Built the customer discovery practice from scratch: interview process, beta program, synthesis framework
- Introduced FlowBite as the design system foundation, defining what to adopt off the shelf and what to customize
- Led 30+ user interviews and 10 usability tests across the platform
- Designed and shipped Pulse, an internal reporting tool, then applied the same modular patterns to eliminate confusion in the SponsorPulse consumer product
- Translated SME domain knowledge into product decisions that actual users could act on
The SME-to-user translation gap
Research revealed a specific pattern: SMEs knew things users didn't, but also held assumptions users didn't share. The gap between "what the data shows" and "what a user needs to do next" was the product's core UX problem.
My value was sitting in that gap, running enough research to know where the SME was right, where users needed more than the data offered, and where SME assumptions didn't hold up in practice. Then designing a system that bridged the two.
Key decisions
Research-first, design second
Established the discovery process before touching Figma. This shifted the organization from "engineers build what SMEs specify" to "we test assumptions with users before we build." That shift changed what got prioritized and surfaced a gap the team hadn't named: users needed to know what to do with the data, not just read it.
Design once, apply twice
Rather than designing Pulse (the internal reporting tool) and SponsorPulse separately, I built a modular reporting system whose patterns could be applied across both products. Patterns validated with internal users directly informed the consumer-facing redesign without starting from scratch.
Insights-first reporting
Redesigned the reporting layer to surface what users should pay attention to, not just what the data contained. The distinction matters: a dashboard full of correct information can still leave users without a clear next action. The redesign prioritized signal over completeness.
FlowBite as foundation, not ceiling
Introduced FlowBite as the design system base. Adopted the component library off the shelf for speed, then defined what to customize for the platform's specific patterns. Established the shared design language the team builds from, across a product that had never had one.
Outcome
Designed once, applied twice. The same modular system served two products, reducing redundant design and engineering work
Reduced CX inquiry volume through better usability and self-service
Established discovery and research as a repeatable practice in a previously research-free organization
Gave the CTO a design partner who could translate between technical capability and user need, and build systems that outlast any single project
What this shows
Technical teams often build what they know, not what users need. The work here wasn't just design. It was building the infrastructure for the organization to make better product decisions. That's what I do when there's no design practice yet: establish the process, ship the work, and make sure both hold after I'm gone.