Making 170 public services findable, in 48 hours.

A brief that said “enhance UI/UX” — and an organiser who asked for one measurable problem.

MPay set the challenge as a broad “enhance UI/UX” task. During the hackathon we worked directly with MPay’s director and had access to the platform’s Google Analytics.

Alexandr Pleshco, the organiser, pushed us to pick one specific UX problem and solve that — it is far easier to measure the impact of the work. So we chose.

It’s tough to find the right one.

Finding the service you need to pay for is the problem.

MPay lists more than 170 services and offers no filtering, sorting or categories — only a broken alphabetical order. In practice the order is random: a parent paying a kindergarten fee has to scan a wall of institution names to find the right one.

Seventy percent pay from a phone, and most pay the same five services.

Google Analytics gave us the shape of the problem before we spoke to anyone. The platform handles about 1.5 million payments a year; 70% of users pay from a mobile browser; 78% pay for the same five services regularly.

That settled two things at once. We would design mobile-first, and the catalogue had to serve the repeat payer, not the browser.

Eleven interviews, one person who stood for all of them.

Because of MPay’s reach, finding users was easy. We wrote a question list and ran qualitative interviews with eleven people.

How often do you use MPay, and from which device? Which services do you pay for most? What got in the way while paying? What would you change? The answers clustered fast.

Ramona pays the same kindergarten fee every month — and searches for it every month.

Her three complaints were everyone’s: no templates for recurring payments, trouble finding the right service, and typing the same data again on the same service.

Where the journey breaks: before the form, not in it.

We mapped every stage from intent to receipt and wrote down what people expected against what actually happened. Expectations: search by service name, filter by category, have your data remembered. Barriers: an unsorted list, no search frame, nothing saved between payments.

Put the services people actually need on the first screen.

We stayed on one problem — structuring the services — and reorganised the MPay flow around it. The core functions and the services people use most had to fit on the first page.

Since 78% of users pay the same six services out of 170+, those became horizontal cards at the top. Every service got a category in plain language, and search took the prime position.

The same task on the old and the new home screen.

From one path through a list to five ways into a service.

The old flow forced everyone through the services page and a long scroll. The new one opens five doors from the main page — search, QR code, popular services, categories, and the scroll for those who want it — and all of them land on the same service form. The payment step didn’t change; it didn’t need to.

Both interfaces, running.

These are not screenshots. The left frame behaves like mpay.gov.md did in a mobile browser — open the service picker and you get the same undifferentiated list. The right frame is the redesign: search it, filter it, pay a kindergarten fee from a saved template.

Two quick tests, one number: 82% faster.

Reuse a payment as a template; make the payment page read like one.

Two smaller changes came straight out of the interviews. Any completed payment can be saved as a template — so next month the kindergarten fee is a confirmation, not a form. And the payment page itself went from a wall of bank instructions to a list of payment methods.

First place at UX4GOV — and about 23,000 hours a year handed back.

An 82% cut in time-to-find, spread across MPay’s users, works out to roughly 23,000 hours a year — about 1.5 million lei. The call centre gets fewer “I can’t find the service” calls.

What made it defensible in the room was not the visual work. It was that we could name the problem, show the number, and say how it would be measured after launch.