Sanity Studio è uno strumento estremamente flessibile che permette di creare un Content Management System (CMS) potente e personalizzabile. Tuttavia, quando si tratta di gestire strutture di dati complesse, può risultare difficile orientarsi a causa della mancanza di linee guida ufficiali dettagliate.
Noi abbiamo avuto la fortuna di usare Sanity in molti progetti, come Giulia by Treccani e Tomasi Auto, e nel tempo abbiamo definito delle linee guida per garantire un’ottima UX, non solo per il sito web visto dall’utente finale, ma anche per l’editor che utilizza il CMS.
In questo articolo, condividiamo la nostra esperienza diretta con Sanity Studio e le buone pratiche che abbiamo sviluppato per affrontare queste sfide in modo efficace.
Cos’è Sanity
Sanity è una piattaforma CMS che combina un database in cloud con un approccio headless, offrendo alle aziende la libertà di modellare la gestione dei contenuti in base alle proprie esigenze, senza vincoli imposti da strutture predefinite.
Sanity Studio è il software di editing collegato al CMS. Si tratta di un’applicazione open-source basata su React, progettata per essere completamente flessibile e adattabile, consentendo di personalizzare l’interfaccia e i flussi di lavoro in modo intuitivo e su misura.
Utilizzato da realtà come Cloudflare, Figma, Puma e Shopify, Sanity consente di creare interfacce su misura, integrare dati da fonti esterne e costruire flussi di lavoro personalizzati, rendendolo la scelta ideale per chi cerca un CMS potente, scalabile e moderno.
Perché è una tecnologia che sta cambiando il modo di gestire contenuti sul web e mobile
Sanity e le soluzioni API-first si sono affermate come alternative ai CMS tradizionali come WordPress grazie alla loro flessibilità, scalabilità e prestazioni. A differenza dei sistemi monolitici, l’approccio headless permette di gestire i contenuti in modo strutturato e distribuirli su qualsiasi canale, dal web alle app, fino ai social e all’e-commerce.
Sanity Studio, essendo basato su React, offre ai developer piena libertà di personalizzazione, evitando le limitazioni imposte dai temi e dai plugin di WordPress. Inoltre, grazie all’architettura in cloud, garantisce migliori performance, riduce la necessità di manutenzione e aumenta la sicurezza.
Di chi è la responsabilità della UX di Sanity Studio?
Immaginiamo un nuovo progetto: tutti in corsa per definire il design del sito web - flussi e architettura di navigazione, sketch & wireframe, poi la UI su Figma. E il CMS? Beh, è un task da developer! Così il povero sviluppatore di turno deve, in tutta fretta e alla bell’e meglio, trovare la struttura e la modalità di inserimento dei contenuti che ritiene più adatta, dovendo risolvere sia gli aspetti funzionali e tecnologici che quelli di esperienza utente del back-office editoriale.
Così, senza alcuna linea guida da parte del team di design, e con una visione parziale o assente di chi utilizzerà il CMS, con che frequenza, e per quali scopi, lo sviluppa adottando soluzioni predefinite, strutture standard o basandosi sulla propria interpretazione di ciò che potrebbe funzionare. Il risultato è un’interfaccia funzionale, ma spesso poco intuitiva o inefficiente, che non agevola l’utente ma è la pura espressione della logica del developer. È fisiologico: mentre il developer pensa a come far funzionare le cose, il designer pensa a come renderle chiare per chi le utilizzerà.
Il design al designer… anche del CMS!
Per questo la responsabilità di curare la UX del CMS non può che ricadere su entrambi: solo con una progettazione “a quattro mani” si può raggiungere un risultato che tenga insieme le necessità tecniche e quelle dell’utente. A partire da una collaborazione tra i team, in seconda battuta l’ideale sarebbe giungere a una standardizzazione, che permetta ai developer di lavorare su questi aspetti con maggiore autonomia grazie a regole e linee guida predefinite.
Pensiamo a chi sono gli utenti che utilizzano un CMS: possono essere redattori, amministratori, marketer, SEO specialist, developer, ma anche insegnanti, impiegati, utenti occasionali. Una gamma di utenti eterogenea, che presenta obiettivi e livelli di competenza tecnica diversi. Questi utenti dovranno poter inserire nuovi contenuti, tenere aggiornati articoli e news, modificare pagine obsolete, aggiungere sezioni a pagine già esistenti, curare la SEO… Proprio come gli utenti di un sito, anche gli utenti che navigano un CMS hanno diritto a un’esperienza piacevole e intuitiva.
I vantaggi di una buona UX sono presto detti:
-
Il lavoro di data entry e aggiornamento, spesso quotidiano, viene semplificato e si riducono il carico cognitivo, la frustrazione e l’inefficienza;
-
Si limitano errori e incongruenze;
-
È più semplice interfacciarsi con il CMS per i nuovi utenti, anche quelli che non hanno familiarità con sistemi complessi. Questo renderà il cliente ancora più autonomo nella gestione del proprio sito;
-
Il cliente è dunque più soddisfatto e ha una migliore percezione del lavoro svolto.
Sanity, rendendoci autonomi nella creazione del CMS fin dalle sue fondamenta, ci dà la possibilità di curare ogni aspetto della UX e di consegnare al cliente un prodotto usabile e soprattutto personalizzato e aderente alle sue esigenze. Questo compito non è sempre semplice e richiede sinergia d’intenti e di sforzi da parte di tutto il team di progettazione, ma può dare molte soddisfazioni a percorso ultimato.
La UX di Sanity Studio: linee guida
Abbiamo provato a definire una serie di buone pratiche pensate per Sanity Studio - ma che, astraendo, possono essere d’ispirazione per qualsiasi CMS. Non abbiamo la pretesa di scrivere regole universali, perché ogni team è diverso e deve trovare i propri metodi; preferiamo ragionare su alcuni concetti che abbiamo incontrato in questi anni di progettazione, sperando che possano esserti utili per risparmiarti un po’ di errori e tentativi lungo la strada.
1. Cura l’architettura informativa
Il primo aspetto di cui preoccuparsi è sicuramente l’architettura informativa. È come il menu di navigazione di un sito: il suo funzionamento, la logica che lo governa devono essere immediati. Questo significa suddividere la navigazione in sezioni intuitive.
Si possono seguire diverse strade: un modello classico, che ricalca anche quello di altri CMS come WordPress, potrebbe prevedere, ad esempio, una sezione per le pagine, una per gli articoli del blog, una per le impostazioni. In altri casi potrebbe avere più senso rifarsi a una strutturazione più vicina a quella dei contenuti specifici del sito. Avendo totale libertà nella strutturazione del CMS hai tra le mani uno strumento potente, che ti permette di progettare in modo molto personalizzato. Per questo ti consigliamo, se puoi, di seguire il modello mentale dell’utente finale: organizza i contenuti secondo gerarchie e relazioni che abbiano senso per lui, non solo per te.
Caso studio: Abbiamo progettato un sito per una concessionaria di maxi affissioni: le due principali sezioni per l’inserimento dei contenuti sono Location e Progetti, ovvero la tipologia di contenuto che andranno a inserire. In poche parole, parla la lingua del tuo cliente: questo ti permetterà di creare un prodotto personalizzato e quindi più comprensibile.
Pro-tip: Mantieni l’architettura snella, evitando molte sotto-pagine: su Sanity il rischio di creare un effetto a matriosca di sidebar infinite è sempre dietro l’angolo. Prediligi strutture orizzontali, così da evitare che sezioni importanti finiscano “nascoste” nei meandri del CMS.
2. Organizza i componenti in modo chiaro e ordinato
Sanity ti permette di personalizzare tutte le voci di menu e gli input che inserisci nel CMS. Segui alcune buone pratiche per rendere la strutturazione dei componenti intuitiva:
-
Pochi ma buoni. Struttura i componenti affinché abbiano senso ed evita di crearne troppi e troppo complessi. Componenti che si distinguono solo per qualche piccolo dettaglio possono essere accorpati; per capirci: una galleria di foto con scorrimento manuale e una con scorrimento automatico possono essere lo stesso componente, basta dare all’utente la scelta di attivare o meno lo scroll automatico.
Questo tipo di approccio richiede un maggior lavoro in fase iniziale di organizzazione dei componenti: il/la developer deve saper analizzare ciò che vede nel design e tradurlo in uno schema il più possibile lineare. In questo può (anzi deve) farsi aiutare dal designer, che già in fase di progettazione può strutturare i vari componenti e blocchi avendo in mente non solo l’utilizzo dell’utente nel CMS, ma anche il lavoro del developer. -
Spiegati meglio. I nomi dei componenti sono importanti: sono l’unico modo che l’utente ha per riconoscerli quando li deve scegliere, non avendo a disposizione un’anteprima immediata. Usa perciò una nomenclatura chiara e precisa, che rispecchi anche in questo caso il sistema mentale dell’utente, ma che allo stesso tempo segua gli standard predefiniti (ad esempio: il footer si chiamerà sempre footer). Cerca di essere preciso: un componente che si chiama “testo in linea” non è molto chiaro se non si ha presente la strutturazione del design. Opta quindi per titoli specifici e se possibile aggiungi una spiegazione per aiutare l’utente a capire cosa visualizzerà in pagina.
- Un’icona vale più di mille parole. Ok, più o meno: spesso le icone non bastano, ma possono essere un ottimo appiglio visivo per l’utente, specialmente per uno che utilizza spesso il CMS. Noi ci impegniamo a selezionare icone che riescano a veicolare il significato di ogni sezione, utilizzando quelle disponibili su Sanity in fase di customizzazione degli input.
Pro-tip. Se sei developer, mantieni coerente la nomenclatura tra codice e CMS: il/la te del futuro, che tra quattro mesi dovrà riprendere in mano il sito per correggere un typo, ti ringrazierà.
3. Descrivi tutto, ma non troppo
Ci piacciono molto le descrizioni: ogni componente, ma anche i singoli input, possono beneficiare di una o due righe di spiegazione. Le descrizioni possono servire a:
-
dare indicazioni di stile e buone prassi per la compilazione all’utente (“evita di superare le 300 parole” o “prediligi immagini grandi almeno 500x500px”)
-
chiarire l’utilizzo di un campo o di una sezione;
-
comunicare informazioni tecniche o funzionali (ad esempio il peso massimo di un file su un campo di upload)
La vera sfida a volte è l’opposto, ovvero impegnarsi a scrivere solo ciò che serve veramente. Ti consigliamo di evitare frasi troppo lunghe o verbose e di andare dritto al punto (gli strumenti di AI sono bravissimi a sintetizzare). Nel dubbio usa il vecchio barbatrucco di tutti i designer - e chi non l’ha mai fatto mente: mostra il campo e fai leggere la descrizione a una persona che non conosce il sito né come si utilizza, e chiedile «È chiaro? Si capisce?» oppure «Tu come lo useresti questo campo?».
Pro-tip. Se hai bisogno di 5 righe per spiegare un concetto, forse il campo non dovrebbe essere fatto in quel modo, o forse non dovrebbe proprio esistere nel CMS. Una buona progettazione della struttura delle query permette di nascondere automatismi e campi affinché il carico cognitivo dell’utente sia alleggerito.
4. Progetta i giusti limiti
Questo discorso vale per tutti i CMS, a dire la verità, ma noi lo ribadiamo perché repetita iuvant. Se vuoi che il sito mantenga il suo aspetto originale, ovvero quello che il/la designer ha creato e per il quale il cliente ha fatto un bell’investimento, è necessario che pensi fin da subito a quanta libertà vuoi dare all’utente in fase di data entry. Questa scelta si baserà su diversi fattori: vincoli di progetto, competenze digitali e sensibilità visiva dell’utente, richieste specifiche del cliente, ecc. Progettare i limiti ha ripercussioni su molti aspetti, tra cui la quantità e la complessità dei componenti, ma permette al cliente di muoversi in uno spazio sicuro, in cui le scelte che prende non compromettono la resa finale del sito.
Quindi, a meno che il tuo cliente non abbia a disposizione un intero team di design, ti consigliamo alcune linee guida basate sulle nostre precedenti esperienze (i muri contro cui abbiamo sbattuto la faccia, per intenderci):
- Limita gli stili di testo, facendo attenzione a rispettare le regole della SEO: fornisci sempre degli stili precisi per i vari headings (h1, h2, ecc.), e un massimo di 3 dimensioni per i testi semplici - a meno che il design non ne preveda di più.
- Riduci le scelte di colore: fornisci i colori del brand, nominati in modo coerente, e alcuni colori neutrali e di sistema se necessari. Un esempio: per un sito abbiamo previsto la possibilità di scegliere il colore di sfondo da utilizzare per ciascuna sezione di una pagina. Abbiamo dato all’utente la possibilità di optare solo tra i tre colori principali del brand (bianco, rosso e nero) e abbiamo progettato il builder affinché la scelta del colore di sfondo influisca automaticamente sul colore dei testi e di altri elementi grafici presenti al suo interno: ogni componente esiste quindi in versione “dark” (sfondo nero o rosso) e versione “light” (sfondo bianco). Questo approccio dà esattamente la giusta misura di libertà all’utente, che può utilizzare correttamente i colori del brand senza doversi preoccupare di modificare ogni singolo elemento.
- Evita di dare all’utente la possibilità di modificare i padding delle sezioni e i gap tra gli elementi. Se proprio è necessario, fornisci poche scelte (ad esempio “gap stretto” e “gap largo”, senza aggiungere quantità numeriche come 40px o 80px) o opta per l’aggiunta di un componente “spacer” che permetta di inserire un gap più importante tra vari componenti. Noi optiamo ultimamente per un approccio “a sezioni”, in cui ogni componente non ha padding verticali ma è inserito in sezioni che li hanno, così da poter gestire al meglio le distanze tra gli elementi e i colori di sfondo. Ci vuole pratica, ma con un po’ di sana progettazione a monte si possono evitare molti mostri di Frankenstein a valle.
Pro-tip. Rendi chiaro fin da subito al tuo cliente la lista di componenti che ha a disposizione per popolare le pagine del suo sito. Se ha necessità di inserire testi affiancati da immagini, per esempio, è necessario che sia creato un componente apposito (magari con diverse varianti): è sempre meglio saperlo in fase di progettazione che a sito ultimato.
5. Permetti all’utente di scegliere come usare il CMS
Sanity permette di costruire un CMS modulare e ogni sezione che lo compone deve essere scelta con cura da chi lo progetta. Ti consigliamo di prevedere sempre alcuni di questi plugin e feature che renderanno ancora più completo e usabile il sito per l’utente:
- Presentation mode. Una feature che permette di modificare testi, immagini e impostazioni dei componenti “direttamente” sull’anteprima del front-end. È una funzionalità potente perché dà all’utente la possibilità di fare modifiche veloci sui contenuti verificando subito la loro resa in pagina. Un’unica accortezza: fai in modo che il cliente non diventi dipendente da questa modalità, ovvero forniscigli gli strumenti per comprendere a fondo anche la modalità “Structure” da cui inevitabilmente dovrà passare per gestire alcune sezioni e modificare alcune impostazioni.
-
Gallery. È un plugin che mostra la repository di tutti i media caricati sul CMS. Normalmente l’utente vi accede dai singoli input (ad esempio quando deve selezionare una foto già caricata). Questa modalità permetterà di avere una visione completa e soprattutto di gestire più agevolmente le risorse presenti.
-
Schedules. Funzionalità a pagamento su Sanity Studio, permette di programmare la pubblicazione di pagine e contenuti. Uno strumento fondamentale per alcuni tipi di siti, soprattutto quelli in cui avviene un aggiornamento costante di contenuti.
Pro-tip. Non tutto è necessario: valuta sempre in base al tipo di progetto quali sono le modalità più rilevanti e se pensi che sia meglio farne a meno, disattivale.
Conclusioni
Abbiamo capito che anche il CMS deve seguire una progettazione user-centered. I clienti sono essi stessi utenti, e meritano di ricevere uno strumento non solo potente e che funzioni bene, ma anche facile da usare e da mantenere nel tempo.
La responsabilità di curare questa progettazione ricade sia sui developer che sui designer, che possono contribuire in egual modo a facilitare l’esperienza dell’utente. Insomma, il designer deve poter comprendere i meccanismi che si celano nelle logiche di sviluppo, per poter supportare i developer anche in fase di creazione del CMS con design ben strutturati e documentati.
Allo stesso modo il developer deve essere in grado di crearsi un occhio critico, quasi da designer, mantenendo l’utente finale al centro del proprio lavoro di sviluppo. Lo diciamo da sempre: avviciniamo e contaminiamo le competenze, perché senza un buon lavoro di squadra, soprattutto quando si progettano i CMS, non si va da nessuna parte.
