La demo dei rendimenti negativi in verde

Summary

La giornata è stata dedicata a una ricognizione sulla dashboard wealth preparata per una demo interna post-fusione. Il problema non riguardava il calcolo dei rendimenti, ma la loro rappresentazione: alcuni valori negativi venivano mostrati in verde quando la variazione superava una soglia di significatività.

Il bug è stato trattato come incidente minore di presentazione. Non sono emerse modifiche ai dati, alle API o alla logica di portafoglio. È emersa invece una dipendenza fragile tra semantica finanziaria, componenti frontend e linguaggio di prodotto.

Context

La schermata in verifica aggregava tre fonti: performance giornaliera, andamento mensile e scostamento rispetto al benchmark. Il backend esponeva valori numerici firmati; il frontend applicava colore, freccia e label testuale in base a una funzione locale nata per evidenziare variazioni rilevanti.

La funzione era stata scritta per una dashboard operativa generica, dove il colore verde indicava “valore da osservare con priorità positiva”. Nella dashboard wealth, però, la stessa regola diventava ambigua: una perdita ampia era sicuramente rilevante, ma non per questo positiva.

Vas ha segnalato il problema durante il controllo pre-demo, dopo aver confrontato la schermata con un export CSV. Il valore -2,8% compariva correttamente nel dato grezzo e nella tooltip, ma la card principale lo presentava con accento verde e freccia verso l’alto.

Worklog

Adriano ha isolato il comportamento nel componente MetricDeltaCard, verificando tre ambienti: locale, staging e preview della demo. In tutti i casi il valore numerico restava corretto. Il problema era concentrato nella funzione resolveTrendTone, che riceveva delta, threshold e intent, ma ignorava il segno quando abs(delta) superava la soglia.

Andrea ha controllato i log e confermato che l’API non normalizzava il segno né trasformava il rendimento in valore assoluto. Nel commento sul ticket ha scritto: “Il backend restituisce una perdita. La UI la trova interessante. Sono due frasi diverse.”

Giulia ha chiesto se fosse possibile descrivere il comportamento come “highlight di attenzione” invece che come errore visuale. La proposta è stata accantonata perché avrebbe richiesto di spiegare al cliente perché una perdita evidenziata in verde dovesse essere interpretata come attenzione neutra. La spiegazione era possibile, ma meno economica del fix.

Giorgio ha aperto un ticket con titolo Normalizzazione cromatica delle performance negative in contesto wealth. La descrizione separava tre casi:

• variazione positiva sopra soglia: verde, freccia positiva;
• variazione negativa sotto soglia: rosso, freccia negativa;
• variazione rilevante ma semanticamente neutra: colore informativo solo se il dominio lo dichiara esplicitamente.

La classificazione è stata considerata sufficiente per la demo, senza trasformarla in nuova policy globale di design.

Findings

La ricognizione ha chiarito che il bug nasceva da una funzione riutilizzata fuori dominio. La regola “valore significativo uguale evidenza positiva” era accettabile in alcune schermate interne, ma non in un contesto finanziario in cui il segno del rendimento è parte del significato.

Sono stati individuati due punti fragili. Il primo è tecnico: la funzione accettava un parametro intent, ma il default copriva troppi casi. Il secondo è di prodotto: la parola “performance” veniva usata sia per indicare movimento misurabile sia per indicare esito favorevole.

Non è stato necessario modificare il Design System Qadra, né dichiarare un nuovo comportamento ufficiale dei componenti. Il fix riguarda solo la dashboard e introduce un mapping esplicito per le metriche di rendimento.

Decisione

Per la demo è stato applicato un fix locale: le metriche con domain: "return" usano il segno del valore come criterio primario e la soglia solo come criterio di intensità visiva. Le metriche non finanziarie continuano a usare la regola precedente finché non verranno ricontrollate.

La decisione evita un refactor generale prima della demo e rende verificabile il comportamento più rischioso. Il compromesso è stato accettato perché il problema era circoscritto, riproducibile e visibile solo in una famiglia di card.

Follow-up

Restano aperte tre attività: aggiungere test visuali per valori positivi, negativi e zero; documentare nel ticket quali metriche possono usare il colore come attenzione neutra; rivedere le altre card che riutilizzano resolveTrendTone fuori dal loro dominio originale.

La demo può procedere con il fix locale. Il problema più ampio, cioè la differenza tra significatività statistica e valore positivo dentro una dashboard finanziaria, è stato lasciato in backlog con priorità media e un owner frontend da confermare.