Multi-FIN
Fines

Problem framing

When I open the fines screen…

This JTBD statement came directly from user research. The existing flow treated every fine check as a one-off transaction — users checking fines on behalf of family members had to manually enter that person's FIN on every visit. Friction at this step was measurable in drop-off.

Before & after

What changed

Before — single FIN entry

After — saved FIN list

Exploration

What we tried first

We tested a version that looked close to final — a saved-FIN list with each person's fines listed directly underneath, and swipe-to-reveal actions for editing or deleting a saved FIN. It didn't survive testing.

Tested concept — swipe-to-edit/delete on saved FINs, with each person's fines listed underneath

Two problems came out of it. Seeing every saved person's identity and fine totals on one screen at once was cognitively heavy. And usage data showed people barely used the swipe gesture to edit or delete a FIN.

Final interaction — swipe was dropped for a tap-to-open menu with explicit Rename and Delete actions

We simplified to a flat list with an overflow menu per FIN, replacing swipe with a deliberate tap — fixing both the density problem and the gesture nobody was using.

Final design

The complete flow

Five screens: choosing a search method, adding a FIN, renaming or deleting a saved FIN, and the error/limit/empty states along the way.

Adding a FIN — enter the number, confirm, and it's saved to the list

Renaming a saved FIN — labeling it so it's easy to recognize later

Deleting a saved FIN — a confirmation step before it's removed

Error, limit, and empty states — clear messaging for a duplicate FIN, the 4-FIN cap, a failed fetch, and the reassuring ‘no fines’ result

Edge cases

Designing for the limits

The HOP API and business rules introduced hard constraints that required explicit design decisions at the edges.

• Duplicate FIN. If a user tries to add a FIN already in their list, show inline error before submission — don't navigate away.
• 4th FIN limit. At maximum capacity, the "Add new FIN" button is replaced with a nudge explaining the limit and offering to remove an existing FIN.
• HOP unavailable. When the traffic police API returns an error, show a clear status screen — not a generic error — with retry and a timestamp of the last successful check.
• Empty state. First-time users see a zero-state with a single clear CTA. No onboarding carousel, no explanation of what FIN is — just an input.

Outcome

Target & status

The feature just shipped to production. It's early — the target metric is a +10% increase in fine payment transactions within the first month post-launch, based on the hypothesis that saved FINs reduce drop-off at the entry step.