01 · Vitality Global
Mar 2024 – Oct 2025 · 8 min read
Configuration Portal
More
than
ten
markets,
one
role-based
portal,
one designer.
As the portal’s first and only designer, I owned the design of Vitality Global’s Configuration Portal: the role-based admin platform where global and market teams configure Vitality’s rewards app for their members. I redesigned developer-built tools, designed new ones from scratch and brought them together behind one landing page, 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
Timeline
19 months
Type
Enterprise role-based admin platform
Category
Health and insurance
Status
Live
Worked with
Design lead
Senior Platform Product Manager
Senior Business Analyst
Business architects
Senior developer and team
Tools
Figma
Lexicon components
Asana
Mural
Microsoft Teams
Notion
Deliverables
Requirements documents and user stories
Post-launch research with 13 users
Information architecture
Wireframes and prototypes
High-fidelity designs
A shared component library
Design reviews with stakeholders
Annotated, developer-ready handoff files
Hero loop: the landing page, search, recently used, then a tool opening.
Business context
Why does this portal matter?
Vitality rewards more than 50 million members in 36 countries for healthier habits. Members only see the app: their points, goals, rewards and articles.
Behind the app, each market tailors that experience to its own members, and the Configuration Portal is where Vitality Global’s teams do it. Users told me in research that they spend 40 to 90 percent of their working day in the portal.
Every change made in the portal reaches members.
The problem
What was getting in the way?
Developers had built each tool as the need arose, without designs. The tools worked on their own, but nothing tied them together, and nothing written explained how they should behave.
01
No way between tools
The developer-built tools had no front door and no back button. Moving between them meant logging out and back in.
02
Direction arrived verbally
Each new tool started with a kick-off meeting, where direction was spoken and often at screen level.
03
Nothing to inherit
No requirements documents, no UX artefacts and no shared process to design from.
04
Sprints sized for screens
Two-week sprints matched the consumer design teams, but each cycle here had to deliver a whole tool with many features.
10+
markets configured in the portal
40–90%
of their working day users spend in the portal
*From post-launch research with 13 users.
0
requirements documents or designs to start from
Needs
What the portal needed
Three needs ran through every tool I designed.
→
One way in
How can teams move between tools without logging out, and find the one they need in seconds?
✎
Requirements first
How can verbal direction become written requirements the whole team corrects before a screen is drawn?
▦
One portal, not many tools
How can every tool look and behave the same, whichever developer builds it?
Research
What did 13 internal users need the redesign to fix?
After I delivered the first tool, I made the case that the rest of the portal couldn’t be redesigned without input from the people who use it, and the research was approved.
How the interviews worked
1.
A month learning alongside a consumer-side UX researcher, before the first session.
2.
Interviews with 13 internal users, starting with their feedback on the rebuilt first tool.
3.
Walkthroughs of the developer-built tools and the portal as a whole.
4.
Affinity mapping and thematic analysis, which turned the feedback into six themes.
What they said
They described the rebuilt tool as “logically designed”, with “how we work in mind”. The six themes then set what each redesign had to change.
Insight
Six themes came out of the interviews: confusion, missing feedback, navigation, functionality, efficiency and visual elements.
Opportunity
Redesign each developer-built tool around the six themes, not around its old screens.
Themes from the post-launch research board, names removed.
Constraints
Which limits shaped how I designed the portal?
One designer for the whole portal, with weekly updates to my design lead.
Direction given verbally and at screen level, often for tools developers had already built.
Designs built from Lexicon components the developers already had.
No analytics baseline to measure against.
Approach
How did I approach it?
Understand the tool before designing the screen.
Wrote user stories and a requirements document before any screen, and had the team correct them until we agreed.
Proposed four-week cycles in place of two-week sprints. My design lead and the Senior Platform Product Manager approved them together.
Grouped the tools by the job they do, behind one landing page.
Built every tool from one component library, which I maintained and shared with the developers.
Annotated every handoff with the business rules and states that weren’t visible on screen.
Key decisions
Three decisions that shaped the portal
1 · One front door for the portal
Problem
The developer-built tools had no front door and no back button. Moving between them meant logging out and back in.
Decision
One landing page: tools grouped by the job they do, with search and recently used.
Result
The landing page went live with the first tools, and each new tool got its own entry card.
Trade-off: the first landing page went live early, with large visual cards, to give teams one way in while the portal was still growing. As more tools arrived, I reworked the cards into quieter, denser entry points that scaled with the portal and suited an internal tool.
The landing page: tools grouped by the job they do, with search and recently used.
2 · A closer look: the Member Segmentation Manager
The first portal tool I worked on, designed with no documentation and from verbal direction alone. Configuration teams write the rules here that place each member into segments, which decide the goals, rewards and content that member receives.
The brief asked for a pyramid. My first note on it was a question: why a pyramid? Sketched with real examples, it broke wherever one category fed several others, and the levels could go deeper than four.
Six directions, one test: what happens beyond four levels? The levelled accordion was approved.
Levels instead of a pyramid. I explored six directions, tested each against what happens beyond four levels, and proposed a levelled accordion as a prototype in the design review. It was approved. Trade-off: a less visual first release, built with components developers already had, with a tree view logged for later.
One meaning per action. The check labelled “Approve” actually sent data through the rules engine. After interviews with the developers and the product team, it became “Run data”, with separate Manage data and Verify data tabs.
Errors that point to their fix. The business architects explained how the engine behaved at the edges. That shaped an error list for five failure types, each with an Edit action that opens the fix.
Verify data: each level opens to its segments and rules.
The error list: Edit opens the item to fix.
Result: the structure finally matched the data, and broken rules surfaced before release. In the post-launch research, users said the tool “functions really well”.
3 · Requirements before screens, in four-week cycles
Two-week sprints, matched to the consumer design teams, left no time to understand a tool before designing it, and each cycle delivered a whole tool with many features. I made the case to my design lead for four-week cycles that start with written requirements: user stories and a requirements document the team corrected until we agreed. My design lead and the Senior Platform Product Manager discussed it and approved it together.
Week 1
Understand
Week 2
Research
Week 3
Explore
Week 4
Design and review
Trade-off: a slower cadence than the consumer teams, for prototype-led reviews with fewer rounds of questions.
One cycle, start to finish, with the artefact behind each step.
The outcome
A redesigned portal, used across global markets
With no analytics baseline, the outcome rests on what I handed over and what people said.
→
One way in
The landing page brought the tools together. Moving between them no longer meant logging out.
▦
One look across every tool
Every tool was built from the same component library, which I maintained and shared with the developers.
✓
Every tool ready to build
Each reached development with a requirements document and an annotated handoff file.
●
Live when I left
Every tool I designed for the portal was live when I rolled off the project.
✎
Redesigns led by research
Six themes from interviews with 13 users set what each redesign had to change.
◎
Four-week cycles adopted
My proposal for four-week cycles that start with written requirements was approved and adopted.
“Anika provided solutions that abstract the complexity of the functional requirements into something more palatable for users.”
Senior Platform Product Manager
What’s next
Where could the portal go next?
In the post-launch research, users asked for three improvements to the Member Segmentation Manager:
A tree view of the segment levels, logged for later during the first release.
Links between categories shown on hover.
A view of how members spread across segments.
Each new tool joins the landing page with its own entry card, and the component library keeps it consistent with the rest of the portal.
Reflection
What would I bring forward?
Agree the words and rules on day one. A short workshop with the developers, the Senior Platform Product Manager, the BA and the business architects would have surfaced naming and structure questions in days rather than across cycles.
Test prototypes with the people who use the portal before launch, alongside the stakeholder reviews.
Define success measures up front, giving the team a way to measure impact from launch.
Make a written case for design support from the first cycle, setting out what a second designer would take on and which risks it would reduce, such as testing before launch.
Screens are recreated and data is illustrative. Internal tool names have been changed.
02 · Next project
The Admin Portal, Vitality US
→