02 · Vitality US
Aug 2022 – Mar 2024 · 7 min read
Admin Portal
One
overloaded
portal
became
two,
with
access
for
every admin role.
As the sole designer for most of the project, I redesigned the admin tools behind Vitality US, where people join Vitality through their employer. One developer-built portal carried every admin task for every admin. Vitality’s product vision split it into a Client-Employer Portal and the internal Admin Portal, and I redesigned the tools for both, with role-based access for every admin level, from verbal brief to developer-ready handoff.
*Screens are recreated and data is illustrative. Internal tool names have been changed.
Role
Product Designer (UX/UI)
Sole designer, most of the project
Timeline
19 months
Type
Enterprise admin portals (B2B2C)
Category
Health and insurance
Status
Rolled out
Worked with
Design lead
Product owners (US)
Development team (Georgia)
Member-side design team
Business architects
Tools
Figma
Asana
Mural
Microsoft Teams
Notion
Deliverables
Audit and new IA of the original portal
Requirements and user stories
Role-based access flows
Wireframes and prototypes
High-fidelity designs
A shared component library
Design reviews every sprint
Annotated, developer-ready handoff files
One → two
portals, split by who uses them
Every level
accounts, groups and teams
A different product owner
for each tool, no BA
01
Two portals, split by who uses them
Every tool from the old portal went to the Client-Employer Portal or the Admin Portal, and was redesigned.
02
Access that follows the organisation
Who can see and access what, from Vitality’s own teams down to a single team.
Case study
At a glance
The product
Vitality turns healthy choices into points and rewards, and in the US, users join through their employer. Behind the programme, admins configure challenges, surveys, messages and reports, and manage who has access. The Admin Portal is the administrative portal where Vitality’s teams do that work.
My role
Product Designer (UX/UI), full-time embedded consultant, August 2022 – March 2024. I worked closely with a design lead for about six months; after that, I owned the design work, from requirements to developer-ready handoff.
The team
A different product owner for each tool based in the US, changing every sprint or two, and a development team from Georgia, with the member-side design team in my design reviews.
The challenge
The original developer-built portal carried every admin task for every admin role, with no business analyst and two-week sprints.
The outcome
One portal was replaced with two: a Client-Employer Portal and the internal Admin Portal, with role-based access designed for every level of the organisation.
The outcome
One portal became two, each built for the people who use it
There was no analytics baseline and no usability testing on this project; the outcome is what I delivered and what was built.
Two portals instead of one. Every tool in the original portal went to the Client-Employer Portal or the Admin Portal, and was redesigned with the people who use it in mind. Some, like the survey builder, were designed from scratch.
Access for every level. From a Vitality super user to an admin who manages a single team, every access flow was built as I designed it.
Help inside the portal. Guides that used to be downloadable PDFs and Word documents became a help centre inside the portal.
Built as designed, sprint after sprint. Each tool reached development with written requirements and annotated handoff files.
The portals were rolled out to employer clients and to Vitality’s internal teams. The wider global rollout followed after I moved to my next project.
A visual to show how user access is assigned
My role
Sole designer for most of the project, with a product owner for each tool
Product owners (US), one per tool
Each tool’s features, priorities and sign-off; a new owner every sprint or two
Development team (Georgia)
Feasibility and build
Member-side design team
Feedback in my design reviews, keeping the portal and the app aligned.
Design lead
Worked closely with me for about the first six months; we unpacked the access roles together
Me
All design on the portals: requirements and user stories, research, IA, user flows, wireframes, prototypes, design reviews, the component library and handoff
I worked remotely from South Africa with US stakeholders and a development team in Georgia. There was no business analyst: gathering requirements, writing them down and confirming them with each product owner was part of my role. I kept the shared Asana board current, giving every owner a view of what was in progress and what was next.
The challenge
One portal for every admin, and no shared map
Vitality turns everyday healthy choices into points and rewards. In the US, people join through their employer: employees earn points for activities such as exercise, health checks and assessments, and employers use challenges and communications to keep them engaged.
Everything lived in the original portal. Employers used it to create challenges, submit activities, send messages and pull engagement reports, and Vitality’s teams used it for their internal tasks. It had been built by developers as each need arose, without designs, an information architecture or a sitemap.
When I mapped it screen by screen, the problems were easy to see:
Similar jobs lived in different places. Mobile messages, newsfeed posts, alerts and Vitality Check banners each had their own board and form, though most fields were the same.
Help lived outside the portal, in downloadable PDFs and Word documents, some of them out of date.
Submitting data meant downloading a template, filling in up to 22 columns in the right format and units, and uploading it as a CSV.
Every admin saw the same portal, though an employer’s admin and a Vitality super user needed very different access.
The IA audit map: every element marked keep, remove or implement, before I redesigned it with improved suggestions.
Key decisions
Three decisions that shaped the portals
1 · Two portals, split by who uses them
Before designing anything new, I audited the original portal screen by screen, marking every element to keep, remove or implement. The resulting information architecture put the product vision into practice: each tool moved to the portal of the users who actually use it. Employer tools went to the Client-Employer Portal, and internal tools went to the Admin Portal.
Choose who you’re working for. After login, admins pick the group and product they work on, and can switch at any time from the header.
2 · A closer look: access that follows the organisation
Role-based access was new to the admin portal, and it had to match how clients are organised: accounts hold groups, and groups hold teams. Everyone is a user; admins are users who’ve been given access. My design lead and I unpacked each role together, I took the questions to the product owners, and I designed every flow. To make the roles easier to discuss, I drew them as diagrams, with a colour for each role and its access rights, which made it easy for shared rights to stand out at a glance.
Who can grant what. A Super User grants access to Account Managers, Group Leads and Admins. A Group Lead grants access across their own group or to chosen teams.
One flow to grant access. Find the user, choose their role, configure their access, set the dates, then confirm on a summary.
Profiles for consistency. Change a profile once, and every admin assigned to it updates.
Friction where data is sensitive. Access to sensitive data asks for an extra confirmation before it is granted.
Trade-off: I designed the most complex access first, the Super User, and after that, each simpler role could reuse steps from the flow before it.
The colour-coded role visual: accounts → groups → teams, and who can grant what.
3 · One way to build
In the old portal, every kind of message had its own form, though most fields were the same: a title, the message, a schedule date, and which teams and products it goes to. In the new portals, surveys, challenges, activities and communications follow the same step-by-step pattern. An admin who has created one challenge already knows how to create a survey.
The process
Requirements without a BA, a review every sprint
Understand. Meetings with the product owner, captured as user stories and requirements the owner confirmed before design began.
Research. Competitor admin dashboards and best practice, within the sprint.
Explore and design. User flows and wireframes, then high fidelity and a clickable prototype.
Review. A design review at the end of each sprint with the product owner, developers and the member-side design team. In the wider formal reviews, with business architects and broader development teams, feedback rarely changed a decision; I documented it and added it to the backlog.
Alongside the design work, I built and maintained the component library the tools were designed from, and researched and facilitated an accessibility workshop for stakeholders and developers.
What I’d do differently
Build the evidence in from the start
Test with employer admins before launch. Stakeholder reviews caught a lot, but not how admins work day to day.
Agree one requirements format with every product owner on day one, keeping changes tracked in one place as owners changed.
Define success measures early, such as the time it takes to grant an admin access.
Splitting one portal into two taught me to start with the map, because a clear structure gives every later decision a home.
Screens are from the delivered designs. Member and employer data is illustrative.