Revolut budgeting

01 / 07

The brief

This was a practical exercise during Revolut’s recruitment process, not commissioned or shipped product work. The brief asked me to identify weaknesses in the app’s budgeting and analytics, propose a precise alternative and explain how I would respond to disagreement with a Product Owner.

I approached it by separating what I knew from what I was assuming: who might use the feature, what problem it could solve, which business and user goals mattered, and what evidence would be needed before making a product decision.

02 / 07

Focus on a traveller’s changing routine

I chose digital nomads as the focus for the exercise. A published interview with Pieter Levels informed a provisional persona; I did not interview him directly.

The opportunity was flexibility. A person might want a daily limit for a coworking routine, a weekly budget during a business trip and a monthly budget while staying in one city. A fixed monthly model could make those different situations harder to manage.

I also considered other audiences, including people travelling in a second language, older users and people with accessibility needs. These remained areas to investigate, not validated segments or findings.

03 / 07

Explore widely, then choose a small change

The early ideas included trip budgets, custom expense tags, weekly limits, excluding transactions, category limits, reminders, custom date ranges, shared budgets, family controls, exports and integrations.

I used impact and effort to compare options, considering reach, customer value, potential business value and implementation effort. The selected direction was to support daily, weekly and monthly budgets with a configurable start date.

It was a focused addition to an existing flow. Reusing the app’s established patterns, including patterns from Vault, could preserve consistency and reduce the amount of new interaction behaviour users had to learn.

04 / 07

Make the assumptions testable

I documented questions for Product and Data partners rather than treating the concept as proven. These covered acquisition, registration errors, time to set up a budget, use of analytics, category changes and differences between people with and without an active budget.

The design goals were to minimise input, make the value visible early, keep relevant information together and support different contexts. A research proposal would test whether the added choices helped users rather than complicating setup.

I did not run that usability study during the exercise. The screens are a design hypothesis, supported by a rationale and an explicit validation plan.

05 / 07

Three scenarios, one familiar flow

The proposal starts with the existing budget-goal step, then asks how the user would like to set the budget. The analytics card reflects the selected cadence, so the setup choice remains visible afterward.

• Daily: set a recurring daily amount for a routine such as using a coworking space.
• Weekly: choose the day the budget begins, useful for a trip that does not start on Monday.
• Monthly: choose the start date to match the user’s own financial cycle.

06 / 07

Use a prototype to discuss behaviour

The prototype explored states, transitions and how the new choices would appear within analytics. It made the difference between the three scenarios concrete for a design review.

Before release, I would agree success measures with Product and Data partners: setup time, successful completion and whether people understood the resulting budget. These were proposed measures, not observed outcomes.

07 / 07

Handle disagreement with evidence and collaboration

The second task asked what to do if a Product Owner considered the flow too complicated. My proposal was to discuss the concern with the team, return to the user and product goals, and test the specific point of disagreement with realistic tasks.

The objective would be to find a simpler, better-supported solution together. This exercise showed the value of making assumptions visible and keeping the scope small enough to evaluate.