La progettazione centrata sull'utente pone l'attenzione sulle modalità con cui gli utenti utilizzano un prodotto e sulla loro soddisfazione nell'uso.
I principi alla base della disciplina si concretizzano in un processo che ha come obiettivo la realizzazione di un prodotto che permette all'utente di svolgere i compiti previsti, le operazioni, i servizi e le azioni supportate con la massima efficienza.
Il design "user centered", e la conseguente applicazione della relativa metodologia progettuale, sono alla base di molte delle best practice in rete: siti web ma anche Intranet Redesign. Anche nei progetti interni che fino a poco tempo fa, e in alcuni casi tuttora, sono considerati come appannaggio unico e "proprietà diretta" del dipartimento di Information Technology, inizia ora a farsi strada un approccio diametralmente opposto rispetto a quello centrato sul software o sulla tecnologia.
Lo stesso approccio può rivelarsi vincente per un'altra classe di progetti interni: i sistemi di backoffice.
Nonostante le attività e i processi aziendali siano ben noti ai team di lavoro interni, non sempre i prodotti finali corrispondono ed incarnano i principi di efficienza e di soddisfazione dell'utente che, in questo caso, hanno un impatto forte e diretto sulla velocità e sulla precisione con cui vengono svolte le attività aziendali.
Un sistema di backoffice non è, infatti, sempre semplicemente un sistema di content management e publishing, ma un sistema di supporto al sito integrato e strutturato per inserirsi nel flusso operativo aziendale. Nel caso di un'azienda che è presente in rete con un sito editoriale, in cui quindi le attività sono solo in funzione del sito, il sistema di backoffice viene utilizzato per la gestione e l'aggiornamento dei contenuti, la pubblicazione dei contenuti, la gestione del rapporto con l'utente (registrazioni, assegnazione e verifica di password, profilazioni) e la gestione dei forum o delle newsletter.
Nel caso invece di un'azienda con un sito di e-commerce, in cui invece il sito è funzionale all'attività dell'azienda ed è uno strumento per la gestione dell'operatività, il sistema di backoffice ha come obiettivi la gestione del catalogo, dei clienti e dei pagamenti, il tracciamento degli ordini ed infine la gestione del magazzino e degli aspetti logistici.
Obiettivi del sistema e indagine sugli utenti
Come affrontare la progettazione dei sistemi di backoffice secondo i principi del design "user centered"?
Innanzitutto, è necessario chiarire quali sono gli obiettivi che ci si pone quando si disegna un sistema di backoffice. Si preferisce una maggiore comprensibilità da parte dell'utente esperto ma anche del nuovo assunto? O si privilegia una migliore velocità, con operazioni più veloci da compiere anche se meno guidate, facendo aumentare però anche le possibilità di errore? Non sempre i due obiettivi sono raggiungibili contemporaneamente. Solitamente viene privilegiata la velocità quando il sistema rappresenta un processo aziendale già consolidato, quando c'è possibilità di fare training, come ad esempio per un call center. Ma la velocità di operazione è ottenuta limitando al minimo le interazioni con il sistema (es. conferma, scelta etc), le segnalazioni di ciò che è richiesto all'utente e i feedback.
Gli obiettivi vanno valutati e determinati tenendo anche in considerazione quali sono gli utenti che dovranno utilizzare il sistema. Possono essere utenti interni all'azienda, sia facenti parti di un team completamente dedicato al sito internet sia utenti che solo periodicamente svolgono l'attività di aggiornamento e pubblicazione di contenuti, oppure utenti esterni che si occupano di quest'attività per conto dell'azienda.
Le tecniche di indagine come l'intervista, i questionari e i focus group possono servire per capire quali sono i bisogni degli utenti, e quali sono le competenze informatiche o la conoscenza del sistema o del processo aziendale di ogni categoria di utenti.
Modelli mentali e modelli del sistema
Particolare attenzione deve essere rivolta alla comprensione e all'analisi dei modelli mentali degli utenti, cioè alla loro personale interpretazione del funzionamento del sistema (ad esempio gli oggetti manipolati possono essere visti come pagine web, record di database o file) da confrontare e paragonare con l'effettivo modello del sistema, cioè come esso funziona realmente.
Nel caso in cui il modello del sistema e il modello mentale dell'utente sono molto dissimili tra di loro, quale modello privilegiare? E inoltre, gli utenti hanno gli stessi modelli mentali?
Ognuna delle due possibilità presenta pro e contro, da valutare attentamente. Applicando il modello mentale dell'utente (nel caso emergano più modelli mentali si darà la preferenza a quello più diffuso o a quello più frequente tra gli utenti più "importanti"), tutte le caratteristiche del sistema devono essere presentate coerentemente al modello scelto, cosa che non sempre è possibile in quanto richiede spesso uno sforzo notevole di coerenza, di astrazione e di completamento del modello nel caso in cui ci siano caratteristiche e funzionalità del sistema che non sono "coperte" dal modello mentale dell'utente.
In questo caso, come devono essere rappresentate? Può essere salvato il modello del sistema, se non entra in conflitto con quello dell'utente? O l'integrazione e l'espansione del modello mentale dell'utente va spinta al massimo? D'altro canto, l'adozione del modello del sistema può creare problemi agli utenti inesperti (che non conoscono il sistema o ne utilizzavano un altro differente, oppure che utilizzano il sistema solo saltuariamente), rendendo difficoltoso se non impossibile lo svolgimento delle attività senza una fase di training o senza la consultazione di un help o di un manuale. Tuttavia questa soluzione presenta evidenti vantaggi in fase di progettazione e realizzazione, in quanto lo sforzo di astrazione e di adeguamento ad un modello differente e difforme rispetto a quello del sistema è ridotto al minimo.
Prima di scegliere il modello da adottare, bisogna anche considerare quale sia tra gli utenti il livello di consapevolezza del processo e dei suoi obiettivi. Gli utenti possono infatti svolgere le stesse azioni ma percepirle in modi diversi a seconda del loro livello di visibilità sul processo: esse possono essere viste in funzione del risultato finale oppure come azioni a sé stanti. Ad esempio, in funzione degli utenti finali del sito web, gli utenti del sistema di backoffice interpretano l'azione "cancella pagina" come la cancellazione fisica della pagina dal sito, anche se i contenuti rimangono archiviati sul sistema di backoffice. Viceversa, l'azione "archivia" per chi si focalizza sull'azione singola, è percepita come archiviazione di contenuti, e il fatto che questo corrisponda anche alla cancellazione dal sito web è considerato solo come un effetto marginale e secondario.
Tipologie di sistemi e di struttura
Scelto il modello da applicare, e in funzione dell'elasticità del modello stesso, va valutato se adottare un sistema centrato sul task (presentare le azioni e solo in seconda battuta gli oggetti sui cui svolgere l'azione) o centrato sugli oggetti, (immediata visibilità degli oggetti, e solo in seguito la presentazione delle azioni da eseguire sugli oggetti selezionati).
Possono anche essere presi in considerazione modelli misti e più complessi. Questi modelli sono indicati nel caso in cui gli utenti siano esperti e conoscano bene gli oggetti da manipolare e le loro relazioni. Questo permette di modificare in progress l'obiettivo dell'azione senza ricominciare un nuovo task, favorendo l'esecuzione rapida di operazioni complesse. Per utenti poco esperti, invece, rischiano di essere confusi e di distrarre dal task principale. È possibile, però proporre il modello misto anche solo per alcuni profili, mantenendo un approccio più guidato per altre tipologie di utenti meno esperti.
Ad ognuna delle varie tipologie di sistema si può applicare una struttura orizzontale o una verticale.
I due modelli di struttura differiscono tra loro principalmente per il numero di livelli e per l'ampiezza delle scelte. La struttura orizzontale si caratterizza per la molteplicità di link e di riferimenti incrociati che permettono di raggiungere qualsiasi funzionalità o parte del sistema in tempi brevi (cioè in pochi passaggi). Questo risultato si ottiene grazie al fatto che non sono costruiti percorsi chiari e precisi, e ciò richiede che l'utente conosca il task e capisca da solo quali strumenti ed elementi utilizzare tra quelli proposti. Viceversa, una struttura verticale è composta da un numero maggiore di livelli, in ognuno dei quali si propone un numero limitato di azioni/oggetti. Rispetto ad una struttura orizzontale, sono necessari molti più passaggi per raggiungere l'elemento su cui lavorare, ma le categorie di azioni/oggetti sono chiaramente distinte fin dall'inizio, riducendo la possibilità che l'utente scelga percorsi che solo alla fine si rivelano sbagliati.
esempio di sistema centrato sul task e l'accesso agli oggetti sui cui operare avviene tramite ricerca
esempio di sistema centrato sugli oggetti, è utilizzata la metafora del sito e l'accesso agli oggetti avviene tramite navigazione tra le cartelle del sito.
Navigazione ed interfaccia
Oltre agli aspetti sostanziali e fondanti del sistema di backoffice, durante la progettazione vanno comunque presi in considerazione e risolti problemi apparentemente più "estetici", che però in realtà, facendo parte dell'interfaccia o essendo strumenti di navigazione, hanno un elevato impatto sul lavoro quotidiano dell'utente.
Per quanto riguarda la navigazione, intesa come modalità di ricerca e di raggiungimento delle informazioni, bisogna valutare se è più utile proporre un approccio per navigazione (browse), per ricerca (search) o un approccio misto, e come strutturarli. La navigazione degli elementi ad esempio può essere particolarmente indicata quando si è scelto di rappresentare gli elementi con la metafora del sito: per raggiungere la pagina da modificare è più intuitivo "navigare" attraverso l'albero del sito. Il sistema di backoffice diventa quindi speculare al sito online e permette agli utenti che percepiscono le azioni e gli oggetti in funzione del sito web, di orientarsi in maniera immediata anche sul sistema di backoffice. In altri casi, come ad esempio per un backoffice di un sito di e-commerce, potrebbe risultate più semplice raggiungere gli oggetti attraverso una ricerca one shot o per raffinamenti successivi. Questo velocizza l'individuazione degli oggetti soprattutto quando l'insieme è molto vasto e poco strutturato, non gerarchizzato. Per un insieme ampio ma fortemente gerarchizzato, la navigazione potrebbe invece risultare ancora la soluzione migliore.
Al momento della definizione dell'interfaccia, come ordinare le labels o le voci di menu? Anche in questo caso va operata una scelta che sia coerente con l'impostazione generale del sistema di backoffice. Qualora si voglia privilegiare un segmento di utenti specifico (gli utenti più esperti, quelli meno esperti, quelli più frequenti etc), si deve fare attenzione al fatto che la soluzione adottata non svantaggi sensibilmente gli altri segmenti rallentandone in maniera consistente la produttività. I criteri di ordinamento più spesso adottati sono: per frequenza d'uso (maggiore evidenza alle azioni o oggetti di utilizzo frequente), per flusso teorico o ciclo di vita dell'oggetto (es. creazione, modifica, pubblicazione, archiviazione, cancellazione), azioni libere (svolte e completate individualmente) o azioni all'interno di workflow (es. apertura della pratica in un call center, ordinamento e smistamento della pratica, report dell'intervento, supervisione, risoluzione della pratica), oppure per priorità/urgenza: es approvazione di pagine da pubblicare.
In ultimo, ma non meno importante, va preso in considerazione l'aspetto della prevenzione o dell'impedimento degli errori. Ha senso rendere impossibili alcune azioni? Le azioni a cui solo alcuni profili di utenti sono abilitati vanno mostrate e impedite, o non mostrate del tutto? Inoltre nei sistemi con grossa interazione: bisogna porre attenzione a come le informazioni vengono presentate e ai punti in cui le informazioni vengono richieste (information design), come ad esempio la segnalazione di campi obbligatori, campi critici, messaggi di errore, alert, messaggi di aiuto, campi informativi ma non interattivi. Sui sistemi con grosse interazioni e con task complessi va seriamente valutata l'opportunità di creare dei wizard, cioè sequenze di azioni più elementari in cui il passaggio da una fase all'altra è rigidamente controllato e in cui l'inserimento delle informazioni è particolarmente guidato. In questo caso è il sistema che decide, in funzione dei dati inseriti dall'utente, con quali step proseguire, in maniera talvolta non trasparente o non percepibile dall'utente.
