BonusX Profile: a scalable redesign that brought completion to 95%
I took on a chronic friction point in the user profile and, together with product, Welfare & Tax and engineering, turned it into a system that scales itself.
context
BonusX helps people in Italy understand which government bonuses and benefits they’re entitled to. The user profile (personal data, household members, financial situation) is the core of the product: every bonus application is based on this information.
The previous profile had a significant friction point causing drop rate: users often had to complete entire questionnaire sections just to update a single field. Household data, in particular, was split across two separate questionnaires with different structures.
Within my first 3 months at BonusX, one question was already clear to me: “What if the profile only asked for what’s needed, when it’s needed?” That is where my work started: getting into the domain and designing a solution to ship across 2 quarters, in phases.
results
- New onboarding completion rate: 95%
- Sign-up conversion went from ~5% to ~10%
- Request time reduced by up to 50% for key services
- New categories and entities added in subsequent quarters fit into existing patterns without UI or code refactors: the bet on scalability paid off
my role
End-to-end design ownership of the new profile architecture: discovery, dynamic flows, family data, validation and handoff. With one choice I put at the centre from the start: designing to scale. The roadmap included new data categories in upcoming quarters, so every screen had to be able to “accommodate” features not yet defined.
cross-team collaboration
A project of this scale isn’t carried alone, and keeping the teams aligned was part of the job. I led discovery and validation with the support of the Product Lead, who managed the overall architecture and the phased release roadmap. With the Welfare & Tax team, who defined content and question eligibility logic, I validated the user flows. With the engineering team I managed the handoff, so the scalable patterns were implemented the way I had designed them.
process
- I ran interviews and usability tests to understand where users got stuck in the existing questionnaires, especially in the household flow
- I designed dynamic flows: instead of fixed sections, the system only asks for fields required by each specific request (fast-forward to missing data, direct editing without repeating the entire questionnaire)
- For household data, I unified the two questionnaires into a single flow: first establish who is part of the household, then add details for each member with direct editing from the list
- I prototyped the flow variants with Cursor + Claude: testable prototypes instead of static mockups, and more hypotheses checked in the time it used to take to test one
- I designed components with extensibility in mind: lists of “entities” (family members, activities, assets) built as a reusable pattern, not hardcoded for current fields
the key decision
Designing for what doesn’t exist yet
The new profile would roll out in phases, and we knew new data categories were coming in subsequent quarters. I chose to prioritise a scalable layout from the start, instead of designing only for the fields we had then. When the new categories arrived, they fit into the existing patterns without refactors to UI or code.
deep dive
reflection
In a live, high-traffic system, designing for scalability isn’t an added cost: it’s the only way to keep every new feature from becoming a mini redesign.
Vibecoding the test prototypes let me explore more flow variants in the time I would have spent testing just one. Today that way of working has become a system: I built my own Claude skill on the BonusX design system, the tone of voice and my strategic and UX guidelines. I start from there to design in context, in Figma and in Artifacts, open the cross-team conversation early, collect feedback and ship sooner.