Netech: nuova UX per la taratura antiriciclaggio bancaria

Il problema

NordEst Technology vende sicurezza informatica a banche e pubblica amministrazione, cioè ai due settori dove la norma e la tecnologia si intrecciano di più. Fra i suoi strumenti c'è una piattaforma di taratura: quella con cui, dentro le banche, si impostano e si verificano i parametri su cui poggiano i controlli antiriciclaggio. È uno strumento operativo: qualcuno lo apre tutti i giorni per lavorarci dentro.

Funzionava, e questo va detto prima di tutto il resto. Aveva però due limiti di natura diversa. Il primo era di flusso: le operazioni che si ripetono più spesso chiedevano più passaggi di quanti ne servissero, e la fatica si accumulava sulle giornate. Il secondo era tecnico: lo stack del front-end non era dimensionato per le prestazioni che viste così dense di dati richiedono.

Come l'abbiamo risolto

Abbiamo iniziato da un'analisi del software esistente, fatto insieme al cliente, per trovarne i punti di forza prima delle criticità. L'obiettivo dichiarato non era riscrivere per il gusto di riscrivere: era capire quali passaggi dell'esperienza d'uso stessero effettivamente ostacolando l'operatore. I flussi esistenti li abbiamo mappati su Miro, ricostruendo i percorsi reali invece di quelli previsti dal manuale, e da lì sono nate le proposte di miglioramento, di grafica e di sequenza, portate al cliente e validate prima di toccare il codice.

Il motore non era il problema. Il problema era chiedere all'operatore di tenere a mente cosa aveva già tarato.

Il cuore del lavoro è la piattaforma di domain e discovery: l'ambiente dove si registrano i domini dei paesi per cui vanno fatte le tarature, si inseriscono i parametri e si definiscono i controlli da applicare ai diversi enti per le verifiche antiriciclaggio. È un dominio con molte dimensioni, e la difficoltà per chi lo usa non è mai il singolo dato: è tenere insieme la relazione fra paese, ente, parametro e controllo mentre si lavora.

È lì che ha agito la UX. Abbiamo riorganizzato la sequenza delle operazioni e reso esplicito nell'interfaccia quello che prima stava nella testa di chi lavorava: cosa è già stato tarato e cosa resta da verificare. Un'informazione che il sistema aveva già, ma che non mostrava, e che una persona era costretta a ricostruirsi da sola ogni volta che riprendeva in mano una sessione.

Sul fronte tecnico il front-end è stato ricostruito in Next.js con TypeScript. Le prestazioni sulle viste dense sono metà della ragione; l'altra metà è la tipizzazione forte, perché qui parametri, enti e controlli hanno strutture articolate e un errore di modellazione non si vede in sviluppo, si paga in fase di controllo. Tailwind tiene il linguaggio visivo coerente e vicino a quello validato in Figma, Redux Toolkit tiene coerenti le informazioni di taratura fra viste diverse lungo sessioni di lavoro lunghe, e il deploy sta su Vercel con la pipeline allineata al ciclo di rilascio.

I risultati

Quello che consegniamo fa esattamente le stesse cose di prima. È una frase che sembra deludente e invece è il punto: su uno strumento di compliance, cambiare quello che il software fa significa rimettere in discussione controlli che qualcuno ha già validato. Quello che è cambiato è quanto costa governarlo, su un impianto più moderno da mantenere negli anni.