Archivio mensile:Aprile 2008

Modelli mentali

Pubblicato il da

Mental Models è il primo titolo pubblicato da Rosenfeld Media, la casa editrice fondata da Louis Rosenfeld, coautore di uno dei testi di riferimento per l’architettura dell’informazione, Information Architecture for the World Wide Web. A scrivere Mental Models è stata Indi Young di Adaptive Path.

Un modello mentale è la rappresentazione della descrizione, da parte di uno o più individui, del funzionamento di un processo della vita reale. 

Un esempio può aiutare a fare chiarezza. Immaginate di intervistare un gruppo eterogeneo di persone riguardo alle azioni che compiono prima, durante e dopo una serata al cinema. Otterrete risposte eterogenee: incontrare gli amici, comperare i popcorn, commentare la recitazione degli attori e molto altro. Raggruppate successivamente queste azioni in caratteristiche, associando un maggior peso a quelle più ricorrenti, così da realizzare un diagramma, un modello mentale per l’appunto.

I modelli mentali sono poi usati per la creazione di servizi e prodotti (non necessariamente online) basati anche sul modello mentale. 

Rispetto all’utilizzo dei personaggi e degli scenari (frutto di invenzione), i modelli mentali hanno il pregio di rappresentare il pensiero di persone in carne e ossa, a patto naturalmente che siate riusciti a individuare un vero campione rappresentativo.  

Un intero testo per parlare di quello che sembra un facile esercizio di interviste e composizione? Sì, perché non si tratta di un facile esercizio. Svariate sono le difficoltà da affrontare, come per esempio individuare il giusto campione di utenti da intervistare, ma soprattutto analizzare le trascrizioni delle interviste, evidenziare le azioni significative e raccoglierle in un modello mentale (per capire le dimensioni che può raggiungere una modello mentale è utile questo esempio pubblicato nel sito del testo).

Mental Models è un testo senza dubbio specialistico, ma può rivelarsi una risorsa preziosa per chi si occupa di project management, proprio per la parte riguardante il processo di intervista. Indi Young vi aiuterà a migliorare la gestione e direzione dei colloqui con clienti evitando i passi falsi, primo fra tutti quello di cercare di mettere in bocca al proprio interlocutore quello che si vorrebbe farsi sentire dire, piuttosto che quello che vorrebbe dire. Il titolo del capitolo in cui parla di questo, “Do Not Lead”, la dice lunga.

Il sito di supporto del libro mette a disposizione del ricco materiale, tra cui due appendici, i template per la creazione di un modello mentale, un’ottima bibliografia e, su Flickr, tutte le illustrazioni del testo.

Attualmente il testo è in vendita un po’ ovunque a 36 dollari; inserendo il codice FOFUCI10 dal sito di Rosenfeld Media avrete diritto a uno sconto del 10%.

Pattern e ricerca

Pubblicato il da

Di pattern nel design web ho già parlato in altre occasioni. I pattern sono soluzioni a problematiche ricorrenti, raggruppati in categorie per facilitare la consultazione.

Peter Morville ha raccolto un buon numero di pattern relativi alle ricerche e ai risultati, attingendo da siti più o meno famosi, e li ha pubblicati nel proprio account Flickr, commentando ogni schermata.

Un lavoro certosino che offre una dettagliata panoramica dello stato dell’arte a disposizione di chi si occupa della progettazione e sviluppo di ricerche.

E’ sempre comodo avere qualche riferimento a cui ritornare in caso di necessità. Qualche anno fa ho avuto modo di parlare di The Design of Sites, un manuale che non posso dire di lasciare per più di qualche giorno sullo scaffale.

Semplificare il web project management

Pubblicato il da

Il web project management è una disciplina complessa, un po’ perché molti sono i compiti del web project manager, ma soprattutto perché il web project manager interviene per facilitare il lavoro degli altri, per ridurre gli attriti, per decidere la strada da seguire a seguito di problemi importanti.

Avere qualche indicazione su come semplificare il web project management non può che essere di aiuto. Alcune le ho trovate leggendo Project Management Made Easy, un intervento pubblicato qualche mese fa nel blog di Blue Flavor (se siete web project manager è uno dei pochi blog a cui vale la pena di iscriversi). Scorrendolo la prima volta ho però sorriso. “Un poco ovvio” – mi sono detto – “questi sono argomenti che non è necessario ricordare a un web project manager”. Ho aggiunto comunque l’intervento nel mio del.icio.us per una futura occasione.

Da allora ho avuto modo di ricredermi sulla banalità degli argomenti, sopravvalutati da molti, e ho deciso di riportare qui uno stringato riassunto dell’intervento, integrandolo con la mia esperienza.

Se vuoi ridurre la complessità del tuo lavoro di web project manager:

  • assicurati che tutti sappiano quali sono gli obiettivi del progetto
  • verifica che ogni componente del gruppo conosca quale è il suo specifico ruolo in questo progetto
  • tieni traccia dei tempi e dei costi
  • impara a comunicare

Quasi tutti i punti hanno a che fare con la comunicazione, e non è una coincidenza. La complessità nel web project management si riduce solo spendendo tutto il tempo necessario con i propri colleghi e con i clienti, così da anticipare i problemi prima che sia difficile intervenire. Ho paura quando ci si butta a capofitto a sviluppare un progetto senza che sia stata prodotta neppure un briciolo di documentazione o che sia stato stabilito come il progetto va suddiviso tra i diversi componenti del gruppo.

Non sto dicendo che prima di iniziare un progetto devono essere prodotte tonnellate di pagine di specifiche; non mi rifiuto di procedere con uno sviluppo senza trascrizioni di interviste con il cliente, analisi dei requisiti e analisi funzionali. Molto spesso, soprattutto per i progetti di media complessità, basta probabilmente un wireframe opportunamente commentato, che però ha fatto capolino al cliente (dove qualcuno lo ha illustrato) ed è poi tornato con le opportune correzioni in azienda.

Non dimenticate poi che non tutti i componenti del gruppo di lavoro con cui lavorate hanno messo piede dal cliente o nelle sale riunioni, per cui non è sufficiente limitarsi a spiegargli la loro parte di lavoro. Dovete coinvolgerli sull’intero progetto, anche se poi si troveranno a lavorare in una minima parte. A meno che non vogliate, ovviamente, che vengano commessi errori non appena le specifiche sono ambigue (il che succede sempre) o che vogliate rinunciare all’apporto che ogni membro del gruppo può dare anche al lavoro degli altri. Centellinare le informazioni porta anche a dipendere da ogni membro del gruppo, evento traumatico quando poi qualcuno va a lavorare da un’altra parte (come ho avuto modo di dire in Quando finisce un amore).

Non so voi, ma io odio essere disturbato ogni due minuti perché chi lavora con me non ha tutti gli elementi per procedere o perché il cliente non si ricorda quanto avevamo stabilito. Se è così anche per voi provate a mettere in pratica qualcuno di questi punti. Lavorerete meglio.