11 - Design dell'interazione: il progetto www.comunitazione.it (2)
Comunitàzione.it
Seguendo le indicazioni di Alan Cooper, per lo sviluppo di comunitàzione[1] sono stati tracciati dei profili degli utenti ipotetici:
Giovanni, lo studente;
Sara, la ricercatrice;
Luigi il content manager;
Franck, l’amministratore di sistema;
Nel design finalizzato al raggiungimento degli obiettivi il primo passo è la definizione dei personaggi e dei loro obiettivi. Una volta identificati, gli obiettivi possono trasformarsi in potenti strumenti di design. Personaggi e obiettivi sono inscindibili, come due lati di una moneta. Un personaggio esiste per raggiungere gli obiettivi che si prefigge mentre gli obiettivi esistono per dare concretezza a un personaggio.
Il buon design dell’interazione ha senso solo a condizione che una persona lo usi veramente per un suo scopo[2].
Lo studente:
Giovanni deve preparare la propria tesi di laurea in marketing esperienziale; ha bisogno di accedere ad una banca dati che gli fornisca una bibliografia di riferimento, un insieme di spunti sull’oggetto della sua tesi, la possibilità di discutere l’argomento con i suoi colleghi e con, magari, i saggi della materia.
E’ un ragazzo di 23 anni, nato nell’era dell’informatizzazione ha una buona dimestichezza con l’informatica, l’internet e le community.
L’importanza che riviste per lui, la chiusura di un ciclo di studi, rappresenta comunque una spinta forte per imparare ad usare degli strumenti a lui utili.
La ricercatrice:
Sara, la ricercatrice ha bisogno di confrontarsi con gli altri, quindi strumenti di dialogo, e di poter pubblicare le ricerche (o parti delle ricerche) che fa per proprio conto. Per lei è importante avere visibilità nel mondo della ricerca e quindi ha bisogno di pubblicare i propri elaborati su una piattaforma che sia affidabile, abbia un buon posizionamento sui motori di ricerca e sia frequentata da suoi colleghi e professioni del suo campo.
Sara ha 26 anni, una discreta conoscenza dell’internet e delle mailing list che frequenta con piacere.
Il Content Manager
Luigi, il content manager, è un ragazzo di 27 anni, appassionato di scrittura. Il suo ruolo all’interno del sito è quello di controllare gli elaborati degli utenti e inserirli in un palinsesto di programmazione. Deve contattare gli utenti per indicare loro la data di pubblicazione del testo e, di tanto in tanto, accendere nuove discussioni inerenti argomenti di carattere generale o specifico, in modo da spingere e invogliare gli utenti a discutere e creare ricerche su quel dato argomento.
Luigi conosce molto bene l’informatica e la piattaforma di comunitàzione.
L’amministratore di sistema
Franck è il supervisore, coordina e gestisce il sistema. Ha bisogno di strumenti operativi diversi, perché sarà lui ad occuparsi di risolvere i problemi che si dovessero incontrare gli utenti.
E’ una persona molto forte, con gli occhi piccole e attenti. Appassionato di lettura, gestisce senza troppi problemi le sue relazioni interpersonali basate tramite
Franck è certamente un “integrato” della tecnologia, ma anche uno di quelli che sfrutta la tecnologia solo per portare avanti i propri compiti.
Progettare per gli obiettivi
Progettare per gli obiettivi significa analizzare e risolvere i problemi che gli utenti (che per il momento sono i personaggi individuati) incontreranno. Ad esempio, l’obiettivo di Luigi è quello di far funzionare al meglio comunitàzione senza alcun tipo di problema:
a) organizzare il palinsesto;
b) correggere eventuali errori degli utenti;
c) monitorare il flusso di elaborati in arrivo da parte degli utenti;
d) inviare un’informativa agli utenti sulla data di pubblicazione del loro elaborato.
Per Luigi quindi il suo compito è un flusso indistinto dei quattro compiti principali, al fine di ottenere il massimo funzionamento del sistema.
Per un progettista sarebbe normale a questo punto offrire a Luigi, per ogni funzione, un’interfaccia diversa. Quando in realtà Luigi percepisce i compiti come indistinti. L’obiettivoche deve raggiungere il funzionamento del sistema, e per farlo probabilmente basta una singola interfaccia. In effetti, per Luigi è sufficiente tenere sotto controllo il palinsesto per eseguire gli altri compiti. Ecco perché è stata progettata per lui un’interfaccia estremamente comoda ed intuitiva che presenta tutti i testi in entrata.
Scenari
Per addentrarci e finalizzare il progetto dell’interazione, Cooper suggerisce di utilizzare, dopo i personaggi gli scenari. Mettere il nostro personaggio in uno scenario in realtà, è come far salire sul palco di un teatro degli attori. Immedesimarsi con i loro obiettivi, analizzare i loro compiti e quindi tradurli in operazioni di design.
Uno scenario veramente efficace, deve guardare più all’ampiezza che alla profondità, cioè è meglio una descrizione che lo comprenda dall’inizio alla fine, di una che si perda nella minuziosa analisi dei componenti. L’importante è sviluppare soltanto quegli scenari orientati ad agevolare lo sfozo della progettazione senza perderci nei casi limite. Per questo motivo ne prendiamo in considerazione soltanto due tipi: (a) quello dell’impiego quotidiano e (b) quello dell’uso in caso di necessità.
Gli scenari di uso quotidiano.
Gli scenari di uso quotidiano riguardano le azioni principali più frequentamente compite dall’utente. Di regola, la maggior parte degli utenti ha un repertorio limitato di scenari di uso quotidiano. Luigi, per esempio, deve accedere al sistema e quindi controllare il flusso di dati in arrivo. Questo è lo scenario classico di utilizzo del sistema.
Gli scenari dei casi di necessità.
E’ importante prevedere anche gli scenari dei casi di necessità, per evitare di chiudere il sistema in rigide e stupide scatole troppo strette nei casi limite. Per esempio, sul sistema di comunitàzione, ogni utente deve inserire da solo il proprio elaborato. Ma sarebbe sciocco non prevedere la possibilità che l’utente possa incontrare un qualsiasi problema e che quindi chieda l’intervento di Luigi. In quel caso, Luigi deve poter inserire l’elaborato per nome e per conto dell’utente che ne avesse fatto richiesta.
Le interfacce elastiche.
Per semplificare l’interazione è sempre possibile ridurre il numero delle funzionalità e rendere il prodotto meno potente. A volte può essere una tattica vincente, ma non è la regola dal momento che il problema più arduo da risolvere è proprio quello di conservare la semplicità senza sacrificare le funzioni. Anche se un programma deve essere dotatati di moltissime funzioni, non è detto che debbano essere presenti tutte nello stesso momento, in ogni parte del software o per tutti gli utenti.
I comandi a disposizione di Luigi saranno tanti in più , rispetto a quelli di Giovanni, lo studente, o di Sara
E soprattutto è il design dell’interazione che deve semplificare i compiti complessi e aiutare, il più possibile tutti gli utenti.
Le interfacce devono consentire agli utenti di utilizzare l’artefatto con il minimo sforzo e poter interagire con il sistema per raggiungere i propri obiettivi. Parte essenziale dei compiti devono essere affidati al sistema stesso che, da solo, deve poter anticipare le esigenze dell’utente.
Adesso partendo da questi elementi, personaggi e scenari d’uso, vediamo nel dettaglio quale design dell’interazione è stato pensato per ognuno di loro.