iPrevail

One overloaded dashboard, split into two. Task success went up 20%.

UX/UI Design
Information Architecture
Design Systems
UX Research

RoleUX/UI Designer · IA · UX redesign · design system

TeamTeam of 4 · PM · Designer (me) · Developer · QA

PlatformDesktop web app

Timeline12 months

Year2025

iPrevail is a peer-support mental health platform. The old dashboard showed everything at once: programs, chats, tools, assignments, communities. It caused confusion and abandonment. Research called for two experiences, so we built two dashboards and overhauled the product end to end.

Users had a hard time finding features because the dashboard was built to do too many tasks at once. It overcomplicated the experience and gave people too many options at the same time. During testing we found drop-off was highest when users landed on the dashboard, and task completion was low because of poor discoverability.

My biggest priority was to solve the structure before any visual work.

A card sort answered our biggest question. People didn’t sort features the way the system did. They sorted by what they came to do: talk to someone, or work through their guided program. We had to build for two different users.

Two dashboards, one for each user, with a path to convert to a full account.

Chat-priority leads with chats, scheduled sessions, and the chat hub. Tools and communities sit below, and a chat-only user can upgrade without starting over.

Program-priority leads with lessons, next steps, and rewards. Chat stays one click away.

Task success went up 20% on average. Chat went from buried to reachable in seconds. Most tickets that came after were for bugs rather than missing features.

Retention was already climbing from the new onboarding. After the redesign it improved another 6%, mostly chat users. Conversions from chat to full accounts went up 5% too.

iPrevail is a peer-support mental health platform. The old dashboard showed everything at once: programs, chats, tools, assignments, communities. Nothing stood out.

The design answer took a few weeks. A card sort told us users came in two headspaces, so we split one dashboard into two. Getting that decision through the company took a year. Most of it went to defending the split, redoing onboarding, and rebuilding the subpages.

This is mostly the story of that year.

Users weren’t asking for new features. The biggest problem was that people were frustrated trying to find solutions to the problem they came with, and many were being offered features they had no interest in.

That was the product problem. The harder problem showed up later: users had years of muscle memory on the single dashboard. Any structural change meant breaking a habit for the exact people we were trying to keep.

My biggest priority was to solve the structure before any visual work.

I used existing analytics, a card sort with users, and notes from the support team. The card sort answered the biggest questions we had. People didn’t sort features the way the system did. They sorted by what they came to do: talk to someone, or work through their guided program. We found that to build an optimal experience we had to build for two different users.

The dashboard had two major directions pulling at it: users who wanted to talk to a coach, and users who wanted guided programs. During research I found competitors had solved this with two different UIs, so I proposed we go that route because of the familiarity it would bring.

After three months of discussion and workshops, the bigger shift happened outside the design. The two-dashboard structure gave the company a new way to bring users in: chat could stand on its own as an entry point, with a paid path to a full account.

We hit a roadblock with the first iterations. Users were used to the old experience, and returning users found it difficult to navigate change all at once. Review rounds went back and forth between one dashboard and two, some at the executive level. I kept the card sort data in front of people to stop the design from drifting back to a single merged view every time someone got nervous.

We found that postponing the complete overhaul and starting with the onboarding experience was easier on users. After redesigning that, adoption went up slightly, and it gave us confidence to keep pushing.

Then we moved to the subpages so we could test how users received changes with lower stakes. After a couple of iterations we moved on to the two dashboard designs and completed the project.

Two dashboards, one for each user, with a path to convert to a full account.

Chat-priority is for people who come to talk. Chats, scheduled sessions, and the chat hub sit up top. Tools and communities sit below. And it converts: a chat-only user can upgrade to a full account without starting over.

Program-priority is for people working a program. Lessons, next steps, and rewards lead. Chat stays one click away.

The split forced work I hadn’t scoped on day one. If the entry point changes, onboarding has to change with it, so we redid the entire onboarding flow. Then every dashboard subpage, because two dashboards pointing at one set of old subpages felt broken. That’s where most of the year went.

Building two screens instead of one could have doubled the mess. It didn’t, because I built the design system first: shared components, type, and color pulled from iPrevail’s brand. Both dashboards and every subpage draw from one kit.

Time ran out on the visual polish, so what shipped was an MVP of the UI I designed. The structure shipped whole.

Task success went up 20% on average. Chat went from buried to reachable in seconds. Most tickets that came after were for bugs rather than missing features.

Retention was already climbing from the new onboarding. After the redesign it improved another 6%, mostly chat users. Conversions from chat to full accounts went up 5% too. Internally that second number mattered more, because it was the argument we’d used to get the split approved.

Most of this project was spent revising the UX of the entire product. Every choice spawned more questions than answers, and every stakeholder wanted to make sure they were heard in the decision making. Ultimately the workshops we came up with, and doing the work away from looking at the UI, is what led us to a place all stakeholders could agree on.

Back to work WellPsyche →