6 - Design dell'interazione: Lo spazio del problema

By Luca Oliverio

23/11/2006 17212 lettori

5 minuti

Design dell'interazione. Un'esperienza di progettazione: www.comunitazione.it :-)

Lo spazio del problema

Con l’espressione spazio del problema si intende la concettualizzazione del prodotto che si vuole creare e la definizione dei motivi che sottostanno alle scelte di design concettuale.^[1] Per procedere in questa fase si deve pensare a come l’artefatto supporterà le persone nelle loro attività quotidiane o di lavoro. E’ a questo punto, sempre secondo Preece, che è opportuno chiarire gli obbiettivi di usabilità e di esperienza d’uso.

Lo spazio del problema in Cooper diventa lo scenario in cui muoverci.

Nella sua analisi Cooper indica come primo passo da muovere quello di formulare una precisa descrizione dell’utente e di cosa desidera ottenere.^[2] Naturalmente chiedere all’utente non è la soluzione ideale, poiché essere afflitto da un problema non rende automaticamente in grado di trovare una soluzione. Ragione per cui Cooper propone di creare dei personaggi ipotetici, degli archetipi ipotetici, che anche se fittizi, vengono definiti con notevole rigore e precisione. Più che inventare i personaggi, si propone di analizzare e scoprire gli archetipi delle persone che useranno l’artefatto e per quali scopi.

Per quale motivo usare gli archetipi?

Creare un prodotto che soddisfi un largo pubblico ci spingerebbe a creare un mostro che abbia le potenzialità e le funzioni del computer di oggi, per esempio, ma non è detto che tutti utilizzino gli stessi programmi, così come e soprattutto, non li usino tutti in una volta. Cooper propone sviluppare un’automobile che soddisfi tutti.

È possibile identificare facilmente almeno tre sottogruppi di utenti: la madre di famiglia, il carpentiere e il giovane manager. La madre vorrà un veicolo sicuro, stabile, con molto spazio e larghe portiere per scarrozzare figli, animali domestici, acquisti e altro ancora. Joe, il carpentiere vuole invece un veicolo solido e resistente con trazione integrale e molto spaziosa per contenere scale, assi, sacchi di cemento e attrezzi vari. Seth, il giovane manager, desidera una macchina sportiva con un motore potente, sospensioni rigide, tettuccio rimovibile e spazio per due. La soluzione logica la potete vedere in figura^[3].

Certamente realizzare una macchina che cambi le proprie caratteristiche asseconda di chi inserisce la chiave nella portiera non è una cosa pensabile, ma chiederlo ad un software sì. Se l’ipotesi di accontentare tutti contemporaneamente scarica sulle spalle dell’utente il compito di destreggiarsi tra mille e inutili complicazioni, l’ipotesi di costruire artefatti in grado di adattarsi all’utente potrebbe semplificare l’interazione con l’artefatto dell’utente e impegnare i progettisti in un’analisi approfondita. Infatti Cooper parla di “utente elastico”, intendendo così l’inutile richiesta che viene posta all’utente di flettersi, piegarsi e adattarsi alle necessità del momento^[4]. Quando invece si potrebbe progettare del software che si pieghi, fletta ed adatti alle necessità dell’utente. Ideare prodotti che soddisfino le persone che li usano vuol dire conoscerne gli archetipi ipotetici. A questo punto è necessario conoscere l’obiettivo per ogni archetipo, poiché conoscendo l’obiettivo possiamo capire direttamente quale tipo di design sia più adatto per un certo scopo^[5], a prescindere dalle qualità estetiche.

E’ utile a questo punto distinguere tra compiti e obiettivi. L’obiettivo è la condizione finale mentre un compito è il processo che serve per raggiungerlo. I compiti cambiano col mutare della tecnologia, mentre gli obiettivi rimangono invariati. Per esempio, l’obiettivo di uno studente è scrivere una tesi di laurea, la ricerca bibliografica è un compito per raggiungere l’obiettivo. Così, se posso adoperare l’internet, il mio compito sarà forse semplificato se trovo qualcuno che ha realizzato una tesi sul mio stesso argomento, o ancora di più, posso scaricare su altri l’incombenza di quel compito e realizzare ugualmente il mio obiettivo. Gli obiettivi sono stabili, i compiti invece transeunti. Questa distinzione è utile per ribadire che nella fase di progettazione si deve progettare per gli obiettivi e non solo per le attività da portare avanti, cosa che si nota invece troppo spesso presso i programmatori. Infatti, per raggiungere lo stesso obiettivo ci sono diversi metodi, ma non tutti combaciano con gli obiettivi personali dell’utente.

Per esempio, l’obiettivo di una segretaria è tenere in ordine gli appuntamenti del suo datore di lavoro. Per farlo può adoperare un’agenda cartacea, o un software che le consenta in modo veloce ed efficace di controllare eventuali altri appuntamenti contemporanei e note aggiuntive, nello storico dell’azienda, nei confronti della persona con la quale fissare l’appuntamento. Per raggiungere l’obiettivo la segretaria ha a disposizione diversi strumenti, ma solo lo strumento che le consente di non fare la figura della stupida con il suo datore di lavoro raggiunge anche il suo obiettivo personale.

Quindi, con Bannon e Bødker^[6] consideriamo che non sia utile studiare gli artefatti cognitivi estrapolati dal contesto in cui essi hanno un ruolo. Questo è diverso dalla tradizionale task analysis, che considera utile solo la descrizione di ogni passo compiuto da un utente per una interazione utile con una applicazione. Come abbiamo detto prima, questa è la modalità preferita dai programmatori e le conseguenze sono sotto gli occhi di tutti.

La task analysis si basa sui compiti che gli utenti devono eseguire, e quindi progetta per ogni compito degli strumenti adeguati. Questa procedura rischia di creare strumenti inutili, in quanto i compiti sono solo dei passaggi intermedi per raggiungere l’obiettivo, ma non sempre necessari.

Come gli utenti raggiungono i propri obiettivi?

Ancora una volta facciamo ricorso a Cooper che conia il termine di interfacce elastiche^[7].

Le interfacce sono elastiche se si adattano all’utente che le sta utilizzando presentandogli di volta in volta le funzioni che l’utente avrà bisogno. Si tratta di un’interfaccia che impara dall’uso dell’utente specifico e che diventa sempre di più un maggiordomo digitale^[8].

La migliore metafora che possa concepire per una interfaccia uomo-computer è quella di un maggiordomo inglese bene addestrato. L’agente risponde al telefono, riconosce chi chiama, disturba solo quando è necessario e, nel vostro interesse può anche dire un’innocente bugia. […] le persone che conoscono il maggiordomo hanno parecchi vantaggi su quelle che gli sono del tutto estranee. E questo è quello che ci vuole^[9].

Un artefatto dovrebbe rispondere alle domande degli utenti, permettergli di raggiungere gli obiettivi. Perché Negroponte preconizza un agente che abbia molte delle caratteristiche umane?

Perché in fondo, abbiamo bisogno di artefatti in grado di capire e, possibilmente anticipare le nostre esigenze.

Quando pensiamo alla tecnologia del futuro stiamo guardando oggetti che sappiano anticiparci, seguirci e soprattutto obbedirci. Un artefatto che segua le regole dell’interaction design deve rispondere alle nostre domande, eseguire i nostri ordini, anticipare i nostri desideri.

Facciamo un esempio: nei nostri telefonini esistono rubriche sempre più complesse, in grado di memorizzare dati interessanti, fax, telefono, mansione, ruolo ricoperto all’interno dell’azienda ecc… Se seguisse però delle regole di interaction design, al nostro telefonino dovrebbe bastare che noi indicassimo il nome della società, il nostro contatto personale, il suo recapito personale, e poi dovrebbe essere l’artefatto a trovare il numero di fax, l’indirizzo, il cap e gli altri dati mancanti, magari utilizzando e sfruttando i servizi digitale disponibili on line come le pagine gialle. Questo sarebbe un maggiordomo, in grado di recuperare le informazioni che stiamo cercando.

Facciamo un altro esempio: un Agenzia di comunicazione, nel periodo che intercorre da settembre a novembre solitamente sta cercando i gadget che le aziende vorranno regalare ai propri clienti. Un artefatto ben costruito dovrebbe accedere alla rete, recuperare i fornitori di gadget, selezionarli in base ad alcuni parametri, e quindi restituircene una lista; darci dei suggerimenti facendo delle inferenze del tipo: se il cliente A lavora con il mercato B, i suoi clienti di fascia C potrebbero volere questo oggetto.

Qualcuno potrebbe obiettare che così finirebbe la creatività dell’Azienda; altri potrebbero obiettare che il sistema non può essere talmente intelligente.

Ai primi possiamo rispondere che dalla nostra segretaria ci aspetteremmo almeno questo tipo di intelligenza, ai secondi invece, potremmo rispondere che il sistema potrebbe apprendere dalle nostre ricerche precedenti.

Per un artefatto non dovrebbe essere complicato correlare una nostra ricerca ad un certo cliente, per tanti motivi:

a) abbiamo da poco aperto la cartella che riguardava il cliente in questione, e quindi il sistema è aggiornato;

b) stiamo effettuando ricerche su un settore merceologico o mercato particolare, che il nostro sistema potrebbe riconoscere se solo fosse stato attento alle nostre ricerche precedenti;

c) non stiamo chiedendo l’impossibile, ma solo che la tecnologia impari a riconoscere chi la usa e impari a eseguire degli ordini.

Quando dicevamo che un artefatto non deve essere invadente e quindi farci sentire inadeguati, non escludevamo la possibilità che un artefatto imparasse le nostre azioni e quindi, ci suggerisse delle soluzioni; stavamo semplicemente dicendo che un artefatto non deve porre delle domande inutili che forniscano un’informazione pari a zero, come ha giustamente evidenziato^[10].

I sistemi interattivi non dovrebbero essere disumanizzanti, ma quando ciò accade, è necessario ridiscutere le nostre metodologie di progettazione per rimettere l’uomo al centro del processo di progettazione. Il primo e più radicale cambiamento che possiamo promuovere è portare a termine la fase di design prima di iniziare qualsiasi forma di programmazione, il secondo è affidare il design a professionisti ben addestrati.

E’ utile ribadire che la progettazione di un qualsiasi artefatto deve partire dagli utenti.