Quando si presenta un sito, quasi tutta l'attenzione va al frontend.
La homepage, il menu, le animazioni, le fotografie, la versione mobile. È comprensibile: sono le parti visibili, quelle che finiranno negli screenshot e nelle presentazioni.
Poi la riunione finisce, il sito viene pubblicato e qualcuno deve usarne il backend.
Quella persona potrebbe entrarci ogni giorno per i prossimi cinque anni.
Eppure il pannello di amministrazione viene spesso trattato come un locale tecnico: basta che sia accessibile e che nessun cliente importante ci finisca dentro per sbaglio.
Secondo me è un errore.
Il backend è un prodotto. Ha utenti, obiettivi, flussi, errori, vincoli e conseguenze. Il fatto che non sia pubblico non lo rende meno progettato. Lo rende soltanto meno fotografato.
L'utente del backend esiste davvero
Dietro la parola “cliente” si nascondono persone molto diverse.
Chi scrive gli articoli. Chi aggiorna i prodotti. Chi carica documenti tecnici. Chi approva le traduzioni. Chi deve cambiare un prezzo durante una telefonata. Chi entra nel CMS due volte l'anno e ogni volta ha dimenticato tutto.
Queste persone non condividono necessariamente competenze, frequenza d'uso o responsabilità.
Mostrare a tutte lo stesso pannello, con gli stessi campi e gli stessi permessi, equivale a progettare un'officina dando a ogni dipendente tutte le chiavi e sperando che riconosca quella giusta.
Prima di costruire il backend cerco quindi di capire:
- chi inserirà i contenuti;
- con quale frequenza;
- quali decisioni può prendere;
- quali dati può soltanto consultare;
- quali errori sarebbero più gravi;
- quali attività si ripetono;
- quali informazioni arrivano da altri sistemi.
Sono domande da UX design, anche se lo sfondo dell'interfaccia è grigio e nessuno la pubblicherà su Behance.
Un campo non è soltanto un campo
Supponiamo di dover gestire una scheda prodotto.
Potrei offrire un grande editor di testo e lasciare che l'utente scriva tutto: titolo, descrizione, misure, materiali, codici, link e note.
È molto flessibile. È anche il modo migliore per ottenere cinquanta schede formattate in cinquanta modi diversi.
Se invece ogni informazione ha un campo specifico, posso:
- validare il formato;
- riutilizzare il dato in più punti;
- ordinarlo e filtrarlo;
- tradurlo separatamente;
- esportarlo;
- modificarne la presentazione senza riscrivere il contenuto;
- impedire che un codice prodotto venga sostituito accidentalmente da una frase promozionale.
La struttura non limita necessariamente l'utente. Spesso lo libera dalla responsabilità di prendere decisioni che il sistema può prendere meglio.
Un campo ben progettato contiene una piccola istruzione sul funzionamento del progetto.
Le etichette fanno parte del software
Nel codice potrei chiamare un campo featured_items_relation. Nel backend forse dovrebbe chiamarsi “Progetti in evidenza”.
Sembra banale, ma molti pannelli espongono il linguaggio dello sviluppatore invece di quello di chi lavora.
Le etichette, gli aiuti e l'ordine dei campi dovrebbero riflettere il processo reale.
Se l'azienda parla di “schede tecniche”, il backend non dovrebbe chiamarle “attachment”. Se distingue tra “famiglia”, “serie” e “modello”, questi termini non sono dettagli editoriali: sono parte del dominio.
Usare le parole giuste riduce la documentazione necessaria. Usare quelle sbagliate trasforma ogni operazione in una traduzione simultanea.
Mostrare meno è spesso una funzione
Un pannello generico tende a mostrare tutto ciò che può fare.
Un backend progettato dovrebbe mostrare ciò che serve in quel momento.
Se un redattore non può cancellare una categoria, il pulsante non dovrebbe esserci. Se un campo viene compilato automaticamente dal gestionale, dovrebbe essere visibile ma non modificabile. Se una sezione riguarda soltanto gli amministratori, gli altri utenti non devono imparare a ignorarla.
La riduzione dell'interfaccia non è povertà funzionale. È controllo della complessità.
Ogni opzione ha un costo cognitivo, anche quando non viene utilizzata. Una schermata con venti possibilità obbliga l'utente a riconoscere ogni volta le tre che gli interessano.
Validare prima di correggere
Molti problemi che emergono sul frontend nascono nel momento dell'inserimento.
Un'immagine troppo pesante. Una data mancante. Un titolo lungo tre righe. Un file nel formato sbagliato. Una pagina pubblicata senza traduzione. Un collegamento a un elemento che nel frattempo è stato rimosso.
Il backend dovrebbe intercettare questi problemi il prima possibile.
Può farlo con:
- campi obbligatori;
- formati e intervalli consentiti;
- dimensioni massime dei file;
- anteprime coerenti con il frontend;
- messaggi di errore comprensibili;
- stati di pubblicazione;
- controlli sulle relazioni;
- valori predefiniti sensati.
La validazione non serve a rimproverare l'utente. Serve a evitare che debba scoprire l'errore quando il contenuto è già pubblico.
Il flusso editoriale non è sempre “salva e pubblica”
Per un piccolo sito può bastare che una persona modifichi una pagina e la pubblichi.
In altri contesti servono bozze, revisioni, approvazioni, scadenze, ruoli diversi e registri delle modifiche. Oppure i contenuti devono diventare visibili soltanto quando un dato esterno raggiunge un certo stato.
Il workflow deve essere proporzionato.
Aggiungere cinque passaggi di approvazione a un team di due persone crea burocrazia. Lasciare pubblicazione e cancellazione completa a trenta utenti crea invece opportunità di crescita professionale per chi gestisce i backup.
Il compito del backend è trasformare le responsabilità reali in un percorso chiaro.
Le automazioni devono rimanere leggibili
Un buon pannello può eliminare attività ripetitive.
Può generare slug, ridimensionare immagini, compilare metadati, duplicare strutture, importare dati, produrre documenti o segnalare contenuti incompleti.
Ma un'automazione invisibile può diventare inquietante.
Se un valore è calcolato, l'utente dovrebbe saperlo. Se arriva dal gestionale, dovrebbe conoscere l'ultimo aggiornamento. Se un pulsante avvia una procedura lunga, dovrebbe ricevere un esito.
L'obiettivo non è creare magia. È ridurre lavoro mantenendo comprensibile il comportamento del sistema.
La magia è molto apprezzata nelle demo e molto meno quando modifica quattrocento prodotti senza spiegare perché.
Anche il backend ha bisogno di gerarchia visiva
Il fatto che uno strumento sia operativo non giustifica un'interfaccia trascurata.
Titoli, raggruppamenti, spazi, colonne, priorità e feedback aiutano l'utente a capire dove si trova e cosa deve fare. Una buona gerarchia riduce il tempo necessario per leggere una schermata.
Non serve trasformare il CMS in un'opera grafica. Anzi, un backend troppo caratterizzato può diventare faticoso.
Serve soprattutto coerenza:
- azioni simili presentate nello stesso modo;
- informazioni importanti facili da trovare;
- campi correlati vicini;
- pericoli chiaramente distinti;
- messaggi che dicano cosa è successo e cosa fare dopo.
È design dell'interazione nella sua forma meno glamour e forse più utile.
Progettare per chi entra raramente
Gli utenti occasionali sono un ottimo test.
Chi usa il sistema ogni giorno impara anche un'interfaccia mediocre. Costruisce abitudini, ricorda scorciatoie e smette di notare le incoerenze.
Chi torna dopo sei mesi vede il backend per quello che è.
Se riesce a pubblicare una notizia senza telefonare, l'interfaccia probabilmente comunica bene. Se deve consultare un manuale per cambiare un numero di telefono, abbiamo trasferito il costo dello sviluppo sulla persona che userà il sito.
La formazione può essere necessaria, ma non dovrebbe compensare una struttura incomprensibile.
La manutenzione comincia dall'interfaccia
Un backend costruito attorno ai contenuti rende più semplice anche evolvere il progetto.
Campi strutturati e relazioni esplicite permettono di aggiungere nuove viste, API, filtri e formati di esportazione. Un grande contenitore di testo libero, al contrario, conserva bene l'aspetto attuale e molto male qualunque utilizzo futuro.
Progettare il pannello significa quindi progettare anche la qualità dei dati.
E la qualità dei dati determina quanto facilmente il sito potrà cambiare.
Il prodotto che nessuno vede
Il pubblico forse visita il sito per due minuti.
Chi lo gestisce potrebbe trascorrere nel backend centinaia di ore.
Per questo considero il pannello di amministrazione parte del progetto, non un accessorio incluso con il CMS.
Se è costruito bene, raramente qualcuno si complimenta. Le persone inseriscono contenuti, trovano ciò che serve e continuano a lavorare.
È un tipo di successo poco appariscente.
Ma tra tutte le animazioni che posso aggiungere a una homepage, una delle funzioni che preferisco rimane questa: evitare una telefonata che comincia con «Non trovo più il pulsante».