Pulse Voices
2026
Introducing the Inbox Approach: Redesigning How Participants Navigate Pulse Voices
The new panelist experience led to increased invite acceptance and more study applications per user.
OVERVIEW
A redesigned navigation around the inbox model.
Over time, multiple shifts in the research platform left the Pulse Voices product structure feeling disjointed for participants. The Design Director trusted me to help envision the future of the platform for the participants our customers depend on.
Before and after the new Pulse Voices experience on web.
PROBLEM
Our participants needed (the right) support.
Participants had to hunt across disconnected tabs and message types just to find and act on a study invite. When they ran into an issue, there was confusion on who to reach out to: our customer or our internal support. This confusion led to participants reaching out to our customers (the researchers) and our research managers for support.
~50%
Analytics
Low onboarding completion, low notifcation tap-through
Existing user research
Support tickets
Participants were missing time-sensitive invites and commonly asking "where's my study"
What I did to learn more
I audited support tickets, reviewed drop-off funnels, met with the PM on customer concerns, and ran a competitive analysis. Dscout was the closest comparable product, but the difference with their platform is that everything was built internally and for less complex data capture. Later into my process, I had to deal with third-party constraints affecting how I handled the scope.
Insights
I started out by working with our product manager to go through our app and gather support tickets from our research team. After analyzing what we had, I did a competitive analysis on what other companies were doing with their apps. Dscout was the closest to what we do, but had less use complexities that I needed to account for. Our product relied on SurveyJS for survey functionality and CometChat for in-app messaging.
In addition, we were in the process of reworking and expanding our capture methods. So, the objective became to design a seamless experience around two external platforms with their own UX patterns, constraints, and limitations.
Studies -> Projects
As studies evolved to include multiple capture methods and ongoing tasks, I reframed them as projects. The difference of projects is that they could last for months with ongoing tasks in a fast-moving research environment. Restarting with new building blocks felt like the right move because the original blocks couldn't handle the new work our platform was taking on.
An observations project detail page and a survey.
In Progress, First
I kept active projects as the opening view despite internal pressure to lead with new opportunities. With project scopes trending longer, participants needed to check current work first. The team was already handling recruitment outreach separately, so discovery didn't need to compete for the top of the screen.
The tab bar for the projects inbox.
Action Items -> Project Details
I moved action items from the dashboard into a new detail page for each project. The actions list at the top seemed logical, but it didn't separate project tasks from internal actions. The most important task per project still surfaces on the dashboard card, keeping tasks visible without the clutter.
Inbox Approach
To solve confusion and inefficiency for the notification bell, the message center, and a flat project feed, I drew inspiration from a range of email inbox flows to create a unified space. I achieved this by grouping in progress/past projects right next to the customized CometChat integration housing messages, invites, and notifications.
The project inbox and message feed.
OUTCOME & RESULTS
A new experience for getting paid to test
Participants now open the app to a clear view of where they stand: what projects they're actively in, what needs their attention, and what's waiting in their inbox, without having to hunt across tabs or decode which notification type means what. The inbox consolidates researcher messages, project invites, and internal notifications into a single, scannable space organized by relevance.
Studies have been reframed as projects, reflecting the reality of how they're structured on the researcher side and the experience now scales naturally with that, whether a participant is doing a quick one-time task or contributing to a bigger, ongoing project. Action items live inside each project rather than competing for space at the top level and the dashboard surfaces just enough to orient without overwhelming. Lastly, participants are one tap away from exploring new opportunities and they’re led to the explore tab from the start when they aren’t involved in any projects yet, through a CTA null state.
Key features
Unified Inbox
Faster Dashboard Scan
Less Clutter
Studies Projects
Guided Null State
The Results
Fewer usability
& support tickets
REFLECTION
What worked
Working closely with the PM early to dig into support tickets before jumping to solutions helped make the research phase feel credible and gave the team confidence that the redesign was grounded in real pain rather than a design preference.
Leading with the inbox model as an organizing principle rather than trying to incrementally fix the existing tab structure was the right call. It gave the whole redesign a clear rationale that the team could align behind, and it made individual decisions — like where action items live — easier to justify because they all served the same logic.
Keeping In Progress projects at the forefront despite internal pushback was also the right instinct. The pressure to surface new opportunities first made sense commercially, but it would have created a worse experience for participants who had active commitments. Holding that line preserved the trust-building the redesign was trying to achieve.
The projects dashboard, project detail page, and explore tab.
What I'd do differently
Test with participants earlier
Earlier feedback could have caught issues sooner and it would have validated the design to the rest of the team faster in the internal reviews.
Audit third-party constraints upfront
CometChat limitations were added after starting rather than being mapped at the start, which created avoidable scope adjustments and an entire round of iteration for messaging constraints.
Add payout visibility with its own treatment
Anchoring payouts to Past Projects is a temporary move, but it deserves a dedicated design pass when the development environment allows for it.