As the sole researcher on a 0→1 B2B health-tech product, I built a well-being measurement tool and dashboard for HR leaders — then the research reframed what the product was actually for.
CheckingIn was an early-stage B2B health-tech startup. As the sole UX and product researcher, I built a research-grade workplace well-being assessment tool and analytics dashboard for HR leaders to evaluate, monitor, and improve their organization's policies and practices. Embedded across the 0→1 lifecycle, my research was about earning adoption from enterprise buyers — senior HR leaders deciding whether a new product was worth trusting, using, and paying for repeatedly. I interfaced between the board, the CEO, design, and engineering to translate an ambiguous business ambition into an evidence-based product and user direction.
The business goal was to build a well-being product HR leaders wouldn't just buy once, but return to and pay for repeatedly. That goal raised three intertwined unknowns:
I split the work into two jobs: first reduce ambiguity enough to commit to a roadmap and build, then test the experience of what we built. Together these formed a feedback loop — foundational evidence defined what to build, evaluative sessions tested it with real buyers, and what we learned fed back into the roadmap. Throughout, I prioritized research by ROI — its impact on an imminent decision versus its cost — which, for example, ruled out heavier survey psychometric testing as low value.
I triangulated three evidence streams to decide what to build:
These streams converged into two outputs. The first was the measurement instrument itself: I built the survey and scoring system from scratch, combining expert knowledge, the research literature, and my survey-design expertise for rigour, credibility, and ease of use. The second was a product definition and V1 roadmap: a primary persona (mid-market HR leaders who own well-being but lack the tools to act), a differentiated position (continuous, benchmarked measurement versus competitors' point-in-time surveys and consulting), and a defined V1 — an assessment survey on workplace policies and practices with a dashboard to monitor results.
To build and test these features, I ran a tight co-design loop with our designer: they shared Figma wireframes, and I annotated and revised them against what we'd learned about HR leaders' needs, mental models, and our product strategy. Once we had a working prototype, I ran moderated usability and prototype-testing sessions with the designer and HR leaders as participants (n=10).
The usability sessions were structured around three conceptual questions. Two returned quick fixes; the third surfaced a deeper problem that would reshape the product.
| Research question | Success metric | Result |
|---|---|---|
| Is the interface navigable? | Success rate & speed on key navigation tasks | 2 navigation pain points identified |
| Are the tools & data comprehensible? | Accuracy interpreting the dashboard's content | 2 comprehension issues identified |
| Would HR leaders value & repeatedly use it? | Qualitative willingness-to-pay evaluations | Critical repeat-use barrier: users need actionability, not more data |
The navigation and comprehension findings were mostly quick fixes — users struggled to find and change their organizational information, and didn't understand where or how the dashboard would update after changing their inputs. The third question was different. Usability was fine; the gap was one layer up, in actionability.
Getting insights adopted depends as much on relationships as on rigour, so I built a working partnership with each part of the team. With the CEO and the board's HR leaders, I earned trust over time — turning their goals and expertise into research questions, and treating the HR leaders as subject-matter partners so the user's voice carried weight alongside the business's. That trust let me shape the roadmap without formal authority. With our designer, the work was a continuous co-design loop: because they saw the evidence firsthand, they owned the design findings, and we brought recommendations to leadership together. With the PM, I matched my engagement to the decisions they owned — once research set the direction, I briefed them on the goals, personas, and roadmap rationale so they could scope and sequence the build on solid evidence, and when findings shifted priorities (as with the actionability pivot) they heard it from me first. With engineering, I translated what we were learning into terms they could act on, so early builds reflected the research.
Synthesis, for me, is triangulation toward a decision. I start by validating the data — face-validity and convergent-evidence checks, because a metric only counts if it's measuring what we intended. That same alertness to a mismatch between expected and observed is what made me stop and probe when the usability sessions surfaced a signal that didn't fit my protocol. Once validated, I read results up the ladder — from each success metric, to what it operationalized, to the conceptual question and the goal behind it — so no finding stands in isolation. And I treat delivery as part of the method: I framed the key finding in the team's own terms ("this is what will bring HR leaders back"), and passed insights along in the tools people already used rather than a deck they'd have to translate.
The research shaped the product at two levels. Upstream, the foundational triangulation defined V1 itself — the target persona, the differentiated positioning, and what to build and measure. Then testing reframed it. The pivotal insight was about experience, not interface: HR leaders weren't struggling to use the dashboard — they were struggling with what to do after they saw their data. I recognized "what do I do with this?" as a signal beyond usability and adapted the sessions to probe it deliberately. Synthesized, it reframed the product's core value proposition: what would bring HR leaders back — and make the product worth paying for repeatedly — wasn't better measurement, it was guidance on what to act on. On that evidence, leadership and I reprioritized the roadmap away from raw data-surfacing toward an actionable-recommendations experience. The product's goal moved from "measure well-being" to "tell HR leaders what to do about it."
Due to confidentiality agreements, product metrics and UI details are omitted. The research approach, findings, and impact described here are shared at a general level.
This is a gap that recurs in data-forward products: the difference between data legibility and decision support. Users who can see a number but not act on it experience the product as friction, not value — which is why "dashboard engagement" is not the same metric as "dashboard impact." Surfacing that distinction early, and treating an unexpected finding as data rather than noise, is what turned a set of usability fixes into a change in what the product was for.