NAVIT’s first research loop
When I joined NAVIT, the team had no structured way to hear from end users or understand recurring product issues beyond support tickets and occasional customer feedback.
I created a lightweight monthly research loop that brought user feedback into product decisions without adding heavy process. The loop connected employee feedback with Support, Customer Success, and Product so recurring issues could be traced back to product decisions instead of handled as isolated tickets.
NPS point improvement (23 → 44 within six months)
App Store rating improved over time
per month to run the research loop
user interviews in the first year
NAVIT was scaling, but the team had limited visibility into the employee experience.
User feedback appeared as scattered signals: support tickets, account questions, NPS comments, and onboarding confusion.
The team needed a lightweight system that could surface recurring patterns and turn them into product input.
How do you build useful research practice in a small startup without adding heavy process?
The system had to be lightweight enough for one person to run, reliable enough to repeat every month, and clear enough for Product, Support, Customer Success, and leadership to use.
I designed and ran the research loop while working as Senior Product Designer / UX Researcher.
I focused on:
Key decision 1
User signals were already coming from support tickets, NPS scores, Customer Success conversations, and occasional user feedback.
I used those signals as the starting point for a monthly research cadence. Each month, I reviewed recent feedback, prioritized low-score respondents and high-priority accounts, and turned the strongest signals into outreach.
Key decision 2
I focused outreach on users closest to recurring frustration: low-score NPS respondents, users connected to repeated support issues, and high-priority accounts.
Users could choose a 30-minute call or async email feedback. Calls were recorded and summarized with AI-assisted notes, then manually reviewed and grouped into themes so the findings kept context, nuance, and product relevance.
Key decision 3
Each month, I grouped feedback into themes, tagged findings in Notion, and created a concise readout with 2–4 product-relevant takeaways.
When useful, I added lightweight charts, quotes, screenshots, or examples so the team could understand the pattern quickly and connect it to specific flows such as onboarding, ticket pricing, allocation, or benefit value.
Key decision 4
I created a feedback loop between Product, Support, and Customer Success so recurring user issues could be discussed with the right context.
Support surfaced repeated pain points, Customer Success added employer-side context, and Product connected the patterns to active work and backlog decisions.
I also ran short usability tests with new joiners during their first days at the company. These sessions helped surface first-time-user issues while also giving new teammates hands-on product onboarding.
If I were continuing the system, I would add:
The loop was designed to stay lean, but better tracking would make prioritization sharper.