Life-cycle payment management platform

From two function-built platforms to one role-based service

Designed, shipped, and released open source in 14 months

ClientPagoPA, SPAC consortium, Regione Lombardia, Regione Veneto.RegionItalyRoleService and User Experience DesignerToolsFigma, FigJam, Figma Slides

Summary

The fix was structural, not technical: order the platform by role, not by function. SPAC had built MyPay and MyPivot so Italian public administrations could adopt digital payments — more than 400 million of payments through the PagoPA node — without further development, but split across two systems, each organized by function rather than by who used them. Working with operators across Lombardia and Veneto, we mapped the full payment lifecycle and rebuilt it as one configurable platform.

Challenge

How might we turn two separate legacy platforms into a single plug-and-play service across the public payments life-cycle, for organizations that each work differently?

Outcome

Role-based experiences for public employees across the full payment lifecycle, configurable by each organization without new development.

Users came to consult, not to create

The platform was structured for creating and managing individual payments. Almost nobody used it that way.

With two other designers, I ran interviews with users of both legacy platforms, mapping the payment lifecycle end to end: how work actually moved, where friction accumulated, and which ideas users would accept. The findings were consolidated into a full-service blueprint identifying the key roles, current pitfalls, and opportunity areas.

Key insights

Experience fragmented by design

Two platforms, each organized by function rather than by task.

Periodic consultation of payment group

Instead of a single payment creation.

High cognitive load, delays, & workarounds.

In retrieving the status of a payment.

Three principles turned insights into structure

The core of the design works focused on the most valuable objective of the platform:

Reducing the cognitive load of tracking a payment's history.
Order information by role, since different users need different things from the same record.
Integrate not only the platform but the whole ecosystem, from citizen communication through to the payment model architecture.

Those principles produced four core moves:

A role-based homepage carrying each user's daily shortcuts.

A payment history that surfaces key status information directly.

A reusable template system for activating each payment type (taxes, fees) a public organization manages — who can handle it, and what gets communicated each time a payment is created.

Visual cues for accounting status.

New platform structure, validated.

[XX] Core tasks of users were tested with final with [XX] users. It confirmed the platform's usefulness and surfaced dead ends and improvements that fed the following iterations.

User test

Published on Developers Italia.

Design completed at 8 months; development finished at 14.

The platform is now published as open source on Developers Italia.

Phase two: beyond tracking payments, recovering them

Until now, the platform handled the happy flow. It had nothing to say about the case that costs public administrations money: when citizens don't pay, and operators have to act.

I ran [XX] 1:1 co-design workshops with operators to understand how they manage recovery today, what they're ultimately trying to achieve, and what each phase would need.

The output was a report setting out which evolutions to pursue and how to structure them — turning a platform that records missing payments into one that flags them and prompts action.

workshop

Report

Key Takeaways

sdsd