iPrevail

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

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. A card sort told us users came in two headspaces, so we split it into two. The design took a few weeks. Getting the decision through the company took most of a year.

People couldn’t find what they came for. The dashboard served every task at once. Drop-off peaked on landing. Support got two or three tickets a day for features that already existed. And many arrived wanting to talk to someone, not to start a program. The dashboard led with the program. It was built for the other user.

I solved the structure before any visual work. Two card sorts: one with users, one with stakeholders, to test the company’s assumptions against its users. They didn’t match. Users sorted by why they showed up: talk to someone, or work a program. Stakeholders sorted the way the product was already built. So we had to design for two users, not one.

Two dashboards, one per user, with a path between them. Chat-priority leads with chats, sessions, and the chat hub; tools sit below, and a chat-only user can upgrade without starting over. Program-priority leads with lessons, next steps, and rewards, chat one click away. Before either, a design system, so two screens didn’t mean two messes.

Task success went up 20% on average. Chat went from buried to reachable in seconds, and most tickets after launch were bugs, not missing features. Retention improved another 6% on top of the onboarding lift, mostly chat users. Chat-to-account conversion rose 5%. That number mattered most internally. It was the argument that got the split approved.

Most of that year went to defending the split, redoing onboarding, and rebuilding every subpage so two dashboards weren’t pointing at one old product. This is mostly the story of that year, and of the exercise that ended the argument.

Nobody was asking for new features. The tickets were people frustrated at not finding a solution to the problem they came with, or being offered features they had no interest in. That was the product problem.

The harder one showed up later. Returning 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, and that fear is what every review round came back to.

The user sort settled the design in a few weeks. Getting past the stakeholder sort took most of the year. Review rounds went back and forth between one dashboard and two, some at the executive level. Each time the design started drifting back toward a single merged view, I put the two sorts side by side again.

The argument that finally held wasn’t about layout. It came from the same research: if people were already arriving for chat, chat could stand on its own as an entry point, with a paid path to a full account. That reframed the split from a UX preference into a new way to bring users in.

Then we sequenced the risk. Onboarding first, because it was easier on returning users, and it lifted adoption slightly. Subpages next, to see how people took change at lower stakes. The two dashboards last.

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 whole 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.

The design system came first: shared components, type, and color pulled from iPrevail’s brand. Both dashboards and every subpage draw from one kit.

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

Most of the year was spent revising the UX of the whole product, and every stakeholder needed to be heard before a decision would hold. What ended the argument wasn’t a better mockup. It was taking the debate away from the UI, asking the room to sort the product themselves, and then showing them that users had sorted it differently. Once the gap was visible, the design stopped drifting.

That’s what I’d carry to the next one. When a structural decision keeps getting relitigated, the problem is usually the room’s model of the user, not the design. Test it the same way you tested the users.

Previous work WellPsyche