Tu vuo’ fa’ l’americano (seconda parte)

alberto-sordi-maccarone

Prosegue l’analisi del documento “U.S. Digital Services Playbook” iniziata qui.

Play 6

“C’è un unico responsabile”

Gli americani individualisti credono che la soluzione migliore sia avere una persona con l’autorità di gestire la realizzazione del prodotto e che sia responsabile del successo come del fallimento.

Noi italiani, che abbiamo chiaro il concetto di team e lavoro di squadra, preferiamo quasi sempre:

  • un responsabile, possibilmente di altissimo livello, che si prende il merito dell’eventuale successo;
  • un folto gruppo di responsabili che prendono le decisioni;
  • un numero illimitato di responsabili su cui ricade la colpa dell’eventuale fallimento (la matematica aiuta col noto caso di 1/infinito).

Play 11

“Sicurezza e privacy sono gestite con processi riutilizzabili”

Le questioni di sicurezza e privacy sono spesso risolte in due modi, entrambi poco efficienti.

  • Affrontandole quando il servizio è in fase avanzata di realizzazione o pronto per l’entrata in produzione. In questo caso il danno è duplice: si ha un ritardo nella messa in produzione ed è molto probabile che le questioni di sicurezza e, più spesso, quelle di privacy entrino in conflitto con le regole di business causando una revisione delle specifiche.
  • Prendendole in considerazione nelle fasi di analisi e progettazione, quindi nel momento giusto, ma partendo da una situazione di tabula rasa. In questo caso la parola chiave è “riutilizzabile”. Pare infatti che, soprattutto per la privacy, la cultura dominante sia quella del considerare ogni situazione un caso unico, cosa vera nel decennio scorso ma certamente non oggi.

Play 12

“Misurare per decidere”

In questo schema il suggerimento migliore è certamente quello di (cercare) di misurare il comportamento degli utenti in tempo reale, cioè studiare come questi interagiscono col servizio. E’ un’attività diversa dai test di usabilità che, se fatta in modo aggregato e in ambiente di produzione, può portare a scoprire problemi ignorati dagli stessi utenti.

Play 13

“Open data, open source, open mind”

Si raccomanda di abbracciare il concetto “open” in tutti i suoi aspetti:

  • raccogliere e rispondere al feeback degli utenti;
  • diffondere i dati;
  • realizzare API per consentire a terzi l’interazione diretta col servizio;
  • arrivare a condividere pubblicamente il processo di sviluppo e i relativi progressi.

Anche in questo caso una parola è interessante: “collaborare”.

Se la collaborazione è uno dei parametri di riferimento del successo di un progetto, non solo l’approccio “open” ne diviene la naturale conseguenza ma, soprattutto in Italia, si possono ridurre i problemi che nascono quando le valutazioni e le decisioni sono un “affare” riservato a pochi.

Lo schema dello schema

Interessante è anche il modello utilizzato per presentare gli schemi: un breve paragrafo che definisce il concetto con un’accurata scelta di termini è seguito da una check list che guida la realizzazione e da un elenco di domande di verifica.

Il pattern è di nuovo quello noto: obiettivo + procedura + verifica del risultato.

Una critica

Per qualche misterioso motivo, nel playbook non si trova la consueta pagina con nomi, titoli accademici e collegamenti ai siti personali di chi ha contribuito a realizzarlo.

 

 

 

 

Tu vuo’ fa’ l’americano (prima parte)

playbook

In ogni sport di squadra gli schemi di gioco sono l’elemento fondamentale per raggiungere il successo, ma è guardando una partita di football americano che se ne capisce più facilmente il valore.

Nonostante le squadre della NFL siano affollate di atleti di altissimo livello, a fare la differenza sono la qualità degli schemi di gioco e la fedeltà con cui essi sono applicati da tutti i giocatori.

Gli spettacolari touchdown e sack sintetizzano, traducendolo in immagini, il valore dei complessi schemi di gioco.

La scorsa estate il neonato “U.S. Digital service”, un team di esperti creato dal governo statunitense, ha usato il concetto dello schema di gioco (play) nella stesura della guida per le agenzie governative che devono realizzare servizi web destinati ai cittadini. Naturalmente il documento si chiama “U.S. Digital Services Playbook“.

Al confronto con l’enorme quantità di materiale prodotto prima dal CNIPA e poi dall’Agenzia per l’Italia Digitale, l’impostazione scelta dall’amministrazione Obama può apparire insufficiente al limite del ridicolo.

Considerando però i dieci anni di gestazione e la ventina di milioni di euro serviti a dare alla luce Italia.it o gli esempi di (in)usabilità di vari portali destinati ai cittadini, forse conviene analizzare un po’ meglio la soluzione americana senza archiviare come banalità i tredici schemi di gioco che propone.

Seguendo lo stesso schema del playbook e sorvolando sui suggerimenti più scontati, come l’adozione della metodologia agile, si può iniziare osservando che già nella brevissima introduzione ci sono elementi a cui non siamo abituati:

  • si chiarisce che i cittadini si aspettano di interagire col governo mediante tutti i canali digitali esistenti;
  • si ammette che troppi servizi digitali della pubblica amministrazione non funzionano bene (dopo poche righe è già chiaro che cosa s’intende per “funzionare bene”).

Il pattern è quello sacrosanto: ammettere gli errori + farsene carico + proporre una soluzione.

Play 1

“Individuare le necessità degli utenti del servizio”.

Tralasciamo l’orrendo caso in cui si realizzano servizi senza coinvolgere gli utenti e consideriamo quello in cui sono presi in considerazione tutti gli stakeholder.

Bilanciando gli interessi degli stakeholder per realizzare un prodotto di valore, occorre usare come riferimento le reali necessità degli utenti. Infatti, mentre è sempre possibile arrivare a un compromesso sulla soddisfazione degli altri stakeholder, ogni riduzione di valore per gli utenti danneggia tutti i soggetti interessati, spesso indirettamente e sul lungo periodo.

Play 2

“Considerare l’intera esperienza di utilizzo del servizio, compresi i passaggi che non coinvolgono strumenti digitali”.

Questo è una regola ampiamente disattesa: si progettano sistemi pensati per esistere in un mondo a parte senza influenzare ed essere influenzati dal contesto in cui vivono gli utenti. Un esempio comune è quello delle procedure che, senza una reale necessità, sono pensate per essere completate in un’unica sessione costringendo l’utente a ripetere tutti i passaggi della sequenza nel caso in cui debba temporanemente interromperla (spesso il tocco di classe è non segnalare l’esistenza del bizzarro vincolo).

 Play 5

“Il budget e i contratti sono fondamentali”

La gestione del budget deve essere affidata a persone competenti: questo è uno dei punti cardine per gli statunitensi; in Italia si deve aggiungere che il budget deve esistere non solo per la creazione del servizio ma anche per la sua gestione e manutenzione nel corso degli anni. Reperire le risorse di anno in anno è la strategia migliore per far sparire improvvisamente un servizio, riuscendo così a trasformare un valore per gli utenti in una perdita.

I contratti devono essere precisi e flessibili in modo da agevolare la consegna del prodotto e, soprattutto, la ricerca della miglior soluzione disponibile e delle moderne metodologie di sviluppo. Devono inoltre consentire al committente di apportare modifiche in corso d’opera senza che queste diventino tragedie greche o trattative arabe.

Naturalmente (!) la proprietà di quanto realizzato deve essere del committente. Quest’ultimo punto è interessante soprattutto per le pubbliche amministrazioni; infatti suggerisce che, mentre i servizi e i prodotti indifferenziati, come le connessioni di rete o le apparecchiature, possono essere tranquillamente noleggiati, ciò che è realizzato per soddisfare specifici bisogni del committente dovrebbe rimanere sotto il suo controllo con sicuri vantaggi per la qualità e il gestione dei costi.

(il tour negli USA continuerà in un prossimo post).football-icon

“È la condivisione, bellezza!”

news13
L’accesso di massa a mezzi di comunicazione potenti e veloci pone a chiunque delle responsabilità che una volta potevano ricadere solo su pochi. Per esempio, il rischio di diffamazione era relativamente limitato prima dell’avvento di Internet: ora basta poco perché si possa offendere qualcuno di fronte a migliaia di persone in pochi secondi.

In particolare, riprendere e diffondere, anche in perfetta buona fede, una notizia o in generale un messaggio senza rendersi conto delle possibili conseguenze può costituire un problema legale (o quanto meno “morale”) a cui non si è preparati; ci si può inoltre esporre a “figuracce” a livello nazionale, non tanto di fronte ad amici quanto a perfetti sconosciuti. In alcuni casi la falsità è evidente, in altri molto meno.

Un buon inizio è quello di prendere l’abitudine di verificare la notizia prima di condividerla: a volte basta davvero poco per evitare di far circolare la voce di un’inesistente nuova legge o di una clamorosa quanto assurda scoperta scientifica.

Prendiamo per esempio questo caso: vediamo su Facebook che il nostro caro amico Mario Rossi ha condiviso, insieme ad altre tremila persone, un post pubblicato da un certo Luigi Verdi che recita: “Nessun giornale ne parla! Con la legge 3756 del 3 gennaio 2014 il Parlamento ha proibito la libera circolazione dei cittadini! Ditelo a tutti!”.

Possiamo scandalizzarci, condividere a nostra volta la scandalosa notizia aggiungendo un commento di imprecazioni contro uno Stato di polizia e quindi scendere in piazza per manifestare a favore dei diritti dell’uomo. Oppure, più ragionevolmente, possiamo tirare un profondo respiro e riflettere prima di agire.

Prima di tutto dobbiamo tenere presente che c’è una certa differenza tra “verosimile”, “probabile” e “reale”: il fatto che una cosa possa potenzialmente, per quanto improbabilmente,  accadere non comporta che sia effettivamente accaduta.

Poi vediamo da chi arriva la notizia: possiamo considerarlo una fonte affidabile? E perché? Ricordiamoci anche che la condivisione da parte di conoscenti in molti casi non è di per sé una garanzia. Anche il fatto che la notizia sia stata presa da un quotidiano non la rende necessariamente vera; inoltre, parrà strano ma non sono pochi i casi in cui una notizia inventata per ridere da un giornale satirico abbia fatto il giro del mondo come vera.

Possiamo verificare la notizia? In molti casi sì; in alcuni potremmo addirittura avere accesso alla fonte originale. Se si tratta di una legge del Parlamento possiamo addirittura vedere il sito ufficiale e magari scoprire che è alquanto difficile che al 3 gennaio sia stata approvata la legge numero 3756. In generale non dovremmo affidarci a un unico punto di vista, ma scoprire su un motore di ricerca che ci sono migliaia di siti Internet che riportano la stessa notizia non necessariamente la rende vera, anzi: potremmo renderci conto che ci sono persone che si sono preoccupate più della rapida diffusione di una notizia sconcertante che della sua verifica.

Esistono siti Web che si occupano del cosiddetto fact checking, ovvero della verifica delle notizie, riportando metodi e fonti della ricerca. Alcuni sono specializzati nello svelare le bufale o nello scoprire che bufale non sono.

Attenzione anche alle presunte citazioni di personaggi o testi: la Rete pullula di frasi che Gandhi non ha mai pronunciato; diffondere una sua falsa citazione sulla pace mondiale non arreca un danno alla sua causa, ma contribuisce a produrre una diversa realtà. Il piccolo principe di Antoine de Saint-Exupéry avrebbe un testo ben diverso, pur mantenendo magari lo stesso messaggio, se ricomposto attraverso le presunte citazioni che possiamo trovare su Internet.

Come si segnala un problema agli sviluppatori?

“Mi si è rotta Internet”

bug-fixSegnalare al meglio un problema riscontrato in un software è una di quelle piccole cose che migliorano di molto la vita di utenti e sviluppatori (oltre a ridurre i mal di testa dei commerciali).

Poiché è raro che il problema di un software si risolva senza l’intervento di utilizzatori e produttori, un difetto mal segnalato difficilmente viene risolto e, prima o poi, incrina il rapporto di fiducia tra cliente e fornitore.

Il concetto cardine è che il responsabile della correzione deve poter constatare di persona l’esistenza del problema.

Ci sono solo due modi perché ciò avvenga ed entrambi coinvolgono attivamente l’utente.

  1. L’utente utilizza il prodotto insieme allo sviluppatore mostrandogli il difetto. E’ la soluzione migliore ma, come tutte le cose belle, non facilmente ottenibile.
  2. Molto più comune è lo scenario in cui l’utente deve spiegare allo sviluppatore che cosa gli ha complicato la giornata. Questo è il caso che cercheremo di approfondire.

I suggerimenti seguenti si applicano sia ai piccoli difetti dell’intefaccia utente che al comportamento del prodotto in relazione alle regole di business(*).

  1. Verificare che la versione del prodotto in uso sia la più aggiornata.
  2. Se il prodotto è utilizzato attraverso una connessione Internet verificare che l’accesso alla Rete sia disponibile (una buona occasione per fare un giretto su Facebook).
  3. Descrivere l’obiettivo che si vuole raggiungere:
    “Vorrei visualizzare le vendite dell’ultimo mese per la sede di Milano”.
  4. Indicare con precisione i passaggi che si fanno per raggiungere l’obiettivo:
    “Dal menù Report faccio clic sulla voce Vendite per intervallo di date.
    Scelgo Milano da menù a discesa.
    Inserisco la data 01/01/2014 nel campo Data inizio.
    Inserisco la data 31/01/2014 nel campo Data fine.
    Faccio clic sul pulsante Visualizza vendite”.
  5. Illustrare il risultato atteso:
    “Dovrei ottenere l’anteprima di stampa del report con i dati di vendita e
    indicato nell’intestazione la città di Milano e il periodo di riferimento che ho inserito”.
  6. Riportare il risultato ottenuto:
    “I dati sulle vendite e il nome della città sono corretti ma il periodo riportato nell’intestazione è sbagliato: la data di fine indicata è 30/01/2014 invece di 31/01/2014″.
  7. Nel caso in cui il problema sia così grave da bloccare il funzionamento del software, molto probabilmente il programma smetterà di funzionare esalando l’ultimo respiro sotto forma di un incomprensibile messaggio di errore. Occorre superare il ribrezzo e tentare di registrare tale messaggio copiandolo in un documento di testo con la funzione copia/incolla (Ctrl+C/Ctrl+V), catturando una scherma premendo il tasto Stamp o annotandolo su un post-it.
    Nei casi peggiori il programma può semplicemente smettere di funzionare chiudendosi irrispettosamente. In tal caso è fondamentale annotare l’ora del decesso che si rivelerà molto utile per la diagnosi del problema.
  8. Infine, provare a riprodurre l’errore almeno un paio di volte, dato che:
    “Tutto quello che accade una volta potrebbe non accadere mai più, ma quanto accade due volte accadrà certamente una terza”.
    Paulo Coelho – L’alchimista
(*) Sono quelle regole che definiscono e controllano la struttura, il funzionamento e la strategia di un’organizzazione.

Lo zen e l’arte della gestione della posta elettronica

Ecco alcuni suggerimenti per migliorare il vostro rapporto con la posta elettronica ed evitare gli esaurimenti nervosi.

Cercate di essere sintetici, esaustivi e non ambigui: un’opera d’arte può anche essere interpretata ma una lettera deve comunicare informazioni. Includete le informazioni necessarie e solo quelle.

Includete come destinatari solo le persone interessate. Voi che cosa pensate quando vi arriva un messaggio che non vi riguarda?

Differenziate tra i destinatari diretti, da cui tipicamente vorreste anche una risposta, e quelli “per conoscenza” (usate gli appositi campi).

Inserite sempre l’oggetto del messaggio: aiuterete il vostro destinatario (e voi stessi) a capire subito di che cosa si tratta. Usate di conseguenza un oggetto significativo (“leggi qui” non lo è).

Un messaggio gestito non andrebbe più ricercato: leggete il testo, ricavatene le informazioni che vi servono, salvate eventuali allegati utili, rispondete se richiesto e poi archiviate il messaggio. Andarlo a ripescare successivamente può significare perdere molto tempo.

La normalità dovrebbe essere una casella di posta in arrivo vuota: cumuli di messaggi abbandonati significano lavoro ancora da fare o, peggio, lavoro già fatto ma indistinguibile da quello ancora da fare.

Per l’archiviazione non create mostruose pile di cartelle: dovendo classificare e successivamente cercare qualcosa è più semplice avere pochi faldoni con molti fogli che una miriade di contenitori semivuoti.

Usabilità à la carte

“Quando arriviamo allo scopo, crediamo che la strada sia stata quella giusta.”
Paul Valéry

Uno dei problemi più complessi da affrontare durante la realizzazione di un software è la progettazione dell’interfaccia utente. Si deve infatti creare uno strumento che consenta all’utilizzatore di raggiungere l’obiettivo seguendo un percorso il più possibile naturale.
Quindi, prima di escogitare soluzioni innovative, si dovrebbe considerare il modo istintivo in cui l’utente svolgerebbe l’operazione.
Vediamo un esempio in cui la fantasia del progettista ha chiaramente preso il sopravvento: un menù per scegliere cosa ordinare da bere.

Lattine 33 cl
Coca, Fanta, Sprite, the pesca o limone, Moretti, Heineken    1,00

Bottiglie 33 cl
Tennents, Moretti rossa, Ceres                                2,00
Becks, Heineken                                               3,00

Bottiglie 66 cl
Dreher                                                        4,00
Moretti                                                       5,00
Heineken, Moretti baffo d'oro                                 6,00

Bottiglie 0,5 l
Fanta, Coca, Sprite, the pesca o limone                       7,00

Bottiglie 1,5 l
Fanta, Coca, Sprite, the pesca o limone                       8,00

Il menù ha una struttura abbastanza chiara da cui si capisce che l’ideatore ha immaginato il cliente fare un ragionamento come il seguente:

  1. Decidere il tipo del contenitore: lattina o bottiglia.
  2. Decidere la quantità di bevanda: 33 cl – 66 cl – 0,5 l – 1,5 l.
  3. Decidere il tipo di bevanda: Coca, Fanta, marca di birra, gusto del tè.

Un percorso di scelta più naturale è quasi certamente questo:

  1. Decidere la categoria della bevanda: bibita o birra.
  2. Decidere il tipo di bevanda, preferibilmente da un elenco in ordine alfabetico: Coca, Fanta, marca di birra, gusto del tè.
  3. Se disponibile, scegliere la quantità desiderata.
  4. Se disponibile, scegliere il tipo di contenitore: lattina o bottiglia.

Secondo questo criterio, il menù si può riscrivere così:

Bibite: Coca, Fanta, Sprite, The pesca o limone
    33 cl (lattina)                          1,00
    0,5 l (bottiglia)                        7,00
    1,5 l (bottiglia)                        8,00

Birre
    Becks  33 cl (bottiglia)                 3,00
    Dreher 66 cl (bottiglia)                 4,00
    Heineken
        33 cl (lattina)                      1,00
        33 cl (bottiglia)                    3,00
        66 cl (bottiglia)                    6,00
    Moretti    
        33 cl (lattina)                      1,00
        66 cl (bottiglia)                    5,00
    Moretti rossa 33 cl (bottiglia)          2,00
    Moretti baffo d'oro 66 cl (bottiglia)    6,00
    Tennents 33 cl (bottiglia)               2,00

Dopo una revisione di tale portata, è naturale prenderci una pausa caffè (Lungo o ristretto? Macchiato caldo o freddo? In tazza grande o piccola?).

Come fare una presentazione efficace

Una presentazione a diapositive, realizzata per esempio con PowerPoint, costituisce da sempre un’ottima occasione per attirarsi l’amore incondizionato del pubblico. Vediamo insieme come con pochi e semplici consigli. Seguiteli e otterrete dal vostro pubblico sempiterna stima!

Siate prolissi: la gente adora ascoltare lunghi discorsi ed è per quello che accorre appena sa che c’è una presentazione; possibilmente usate sempre lo stesso tono, senza inflessioni, in modo da cullare il pubblico e facilitare il lavoro di Morfeo.

Presentate molti concetti: non importa se la maggior parte delle persone è in grado di assimilarne solo cinque o sei; voi propinate decine e decine di messaggi, così ci saranno più probabilità che almeno uno entri in quelle zucche vuote.

Scrivete fitto e con caratteri piccoli: se quelli seduti in fondo alla sala non vedono, peggio per loro; la prossima volta si siederanno in prima fila. Se scrivete abbastanza piccolo, non vedranno nemmeno quelli in prima fila, che sicuramente erano quelli che si erano seduti in fondo la volta precedente.

Coerentemente con quanto sopra, fate più diapositive possibile: accumulatene almeno un centinaio. Potrete così movimentare la presentazione continuando a premere il tasto per passare alla diapositiva successiva. Il migliore effetto si ottiene quando il pubblico rimane ipnotizzato dall’effetto quasi stroboscopico del continuo cambio di schermata. Per prudenza, assicuratevi prima che non siano presenti epilettici.

Siate criptici, confusi e nebulosi: lasciate molti sottintesi, usate sigle e abbreviazioni sconosciute; se spiegate tutto, togliete quell’aura di mistero e magia che conferisce fascino alla vostra opera d’arte. Il pubblico non deve capire ma rimanere perplesso: solo così lo porterete davvero a riflettere. Verificherete voi stessi di aver raggiunto l’obiettivo sentendo la gente all’uscita chiedersi “Ma che cavolo voleva dire?”.

Le presentazioni vanno lette, non spiegate: assicuratevi che l’intero testo del vostro discorso sia presente sulle diapositive; il vostro prezioso apporto è la lettura: leggetele tutte! Per gli spettatori sarà come avere un audiolibro. Qualcuno potrebbe osservare che, se vi limitate a leggere il testo, la vostra presenza (e la loro) sia inutile; non badategli, è tutta invidia. Comunque gli invidiosi alla seconda presentazione non si palesano più.

Utilizzate molti colori e differenti font: la gente adora vedere scritte arcobaleno e chiedersi il significato dei diversi colori e caratteri, come se fosse un gioco di cui trovare la soluzione; ancora meglio se alcune combinazioni si leggono a fatica. Se poi la sala è immersa nel buio, niente di meglio di un bello sfondo bianco per abbagliare il pubblico.

Usate più che potete animazioni e suoni: è bello parlare mentre il pubblico osserva a bocca aperta le diapositive scorrere con effetti mirabolanti, piovendo dal cielo, roteando a spirale, saltellare a destra e a sinistra con accompagnamento di trilli di campanelle ed esplosioni. Tutti resteranno colpiti dalla vostra abilità e vi chiameranno “mago”.

Inserite immagini e clipart che vengono fornite dal programma di presentazione, possibilmente quelle che avete visto usare più spesso da altri, senza cercarne di nuove o originali; se tutti le usano ci sarà pure un motivo; in più, risparmierete tempo e servirà a far capire ai vostri fan che siete uno di loro.

Fate lunghi elenchi puntati nella stessa diapositiva: ogni elenco deve contenere almeno una decina di voci. Alla terza voce magari alcuni avranno già dimenticato a che cosa si riferiva l’elenco, ma voi tirate dritto.

Non seguite un ordine fisso: la migliore impressione si ottiene correndo avanti e indietro per le diapositive come un topolino in un labirinto, magari dicendo “mi sembra di averlo scritto nella prima, anzi, no, nella 5, ah, ecco, la 7, proprio come vi stavo dicendo nella 2” ecc.

Mostratevi impacciati, nervosi e indecisi: il pubblico si commuoverà; tenete le mani in tasca e fissate le vostre scarpe mentre mormorate come se stesse parlando tra voi; se riuscite anche a balbettare e a sudare saranno tutti con voi. In alternativa, cercate almeno di schiarirvi spesso la voce e di iniziare ogni frase con “Eeehhh, ehm, ah, dunque” e di finirla con “Ok? Ci siamo capiti, no? Chiaro, vero?”.

Procuratevi un puntatore laser e usatelo compulsivamente anche quando non avete alcunché da indicare: il pubblico si divertirà a fissare quel puntino rosso che si muove nervosamente sullo schermo come i mirini delle forze speciali su un branco di terroristi. Quando non state indicando qualcosa, agitatelo in direzione della platea: fa tanto concerto rock e potrete al contempo curare diverse malattie dell’occhio.

Osservate le reazioni del pubblico: se notate che alcuni se ne vanno, altri dormono e i rimanenti vi fissano con aria sconcertata, è fatta!

Preghiera

Preghiera da usare prima di recarsi a una riunione con un cliente per discutere i dettagli di un software da sviluppare.

Ti prego <nome della divinità del caso>:

  • fa’ che le procedure che gli utenti seguono siano effettivamente quelle che gli utenti devono seguire;
  • similmente, fa’ che, una volta stabilite le procedure in maniera definitiva, nessuno dica “in realtà non facciamo così, non sappiamo di preciso come facciamo, forse facciamo così, boh”;
  • fa’ che nessuno chieda “ma quanto mi costa” prima di aver detto che cosa vuole;
  • conseguentemente, fa’ che sappia che cosa vuole;
  • fa’ che io possa parlare con gli utenti finali o con un loro campione rappresentativo;
  • fa’ che nessuno voglia estrarre dei dati che nessuno inserisce;
  • fa’ che ci sia un solo soggetto che può prendere decisioni e non dieci diversi;
  • se il punto precedente fosse irrealizzabile, fa’ che il cellulare abbia abbastanza batteria da permettermi di giocare on line fino a quando i dieci suddetti non si saranno accordati o fino a quando non ne sarà rimasto uno solo;
  • fa’ che nessuno usi espressioni altisonanti ma prive di qualsivoglia significato, specialmente in inglese, perché è una lingua che conosco molto bene;
  • quando ciò comunque accadrà, fa’ almeno che io riesca a trattenere le risate o quanto meno l’istinto omicida;
  • fa’ che nessuno dica “ma questo lo sa fare anche mio nipote con Word, ci mette cinque minuti”;
  • fa’ che non ci sia quello che non c’entra un tubo ma che c’è sempre comunque e che dice la sua con ineguagliabile incompetenza;
  • dato che ci sarà comunque, fa’ che qualcuno gli dica “fuori di qui!”;
  • fa’ che nessuno dica “credevo che il software fosse gratis”.

Se ti è piaciuto questo post, potrebbe interessarti anche Il cliente ideale.

Minority Interface

La storia del cinema di fantascienza è ricca di scene in cui vengono mostrate interfacce utente più o meno avveniristiche. Queste interfacce ci appaiono spesso geniali e ci fanno desiderare di averle disponibili. In realtà si tratta quasi sempre di una pessima idea.

Le interfacce utente che compaiono nei film sono fatte per sembrare belle, affascinanti e spettacolari sullo schermo, ma raramente sono applicabili nella vita reale, non tanto per la mancanza della tecnologia necessaria per realizzarle quando per la quasi totale mancanza di praticità.

Jurassic Park

Nonostante il personaggio di turno si dimostri capace di usare perfettamente l’interfaccia, anche senza averla mai vista, questa è spesso estremamente complessa. Il sistema di gestione del Jurassic Park è accessibile mediante comandi testuali e un’interfaccia in computer graphics: un sistema alquanto scomodo per accedere una luce; eppure la piccola Lex non incontra alcuna difficoltà a usarlo senza bisogno di formazione specifica (“è un sistema Unix” dice, “lo conosco”, che è un po’ come dire che se conosci il codice della strada sai guidare qualunque veicolo).

Minority Report

Il gigantesco schermo verticale, curvo e semitrasparente di Minority Report costringe il povero Tom Cruise a gesticolare nell’aria come un ossesso; osservarlo è sicuramente divertente ma lavorare al computer tenendo tutto il tempo sollevate le braccia pare più un’attività da palestra che da ufficio.

Blade Runner

La scena in cui il cacciatore di Replicanti interpretato da Harrison Ford studia una foto mediante una macchina ingranditrice in Blade Runner  è affascinante e ricca di tensione; tuttavia, concepire comandi vocali che comprendono coordinate per ascissa e ordinata e fattori di ingrandimento semplicemente per vedere meglio il particolare di un’immagine è pretendere un po’ troppo dal povero utente.

Con o senza filtro?

“Il talento sta nelle scelte.”
Robert De Niro

Esempio di form di ricerca

Quella visualizzata nell’immagine è la maschera di ricerca di un software personalizzato progettato alcuni anni fa. L’archivio in cui si voleva fare la ricerca era un tipico archivio contratti.

Con un po’ di analisi e un paio di versioni si ottenne un sistema con 10 filtri, inclusa la possibilità di cercare per intervalli di date.

Dopo qualche tempo si notò che le descrizioni dei contratti inserite dagli operatori avevano la seguente forma.

2014 - Rossi - Abbonamento al servizio XYZ

Consultando gli operatori, che inizialmente non erano stati coinvolti nella scelta dei criteri di ricerca, si scoprì che aggiungevano metodicamente alla descrizione del contratto l’anno d’inizio e il cognome del contraente. Lo facevano perché era “il modo più semplice per trovare un contratto”.

Cos’era successo?

  • Nella quasi totalità dei casi, i parametri di ricerca usati erano l’anno d’inizio contratto, il cognome del contraente e la descrizione.
  • Gli operatori avevano scoperto che la funzione di ricerca trovava anche le sottostringhe di testo presenti nella descrizione.

In sostanza ciò che serviva a soddisfare la maggior parte delle ricerche era cercare sottostringhe di testo nella descrizione del contratto e nel cognome del contraente e la corrispondenza esatta nell’anno di inizio contratto.

Un’idea semplice e funzionale:

RicercaGoogle

In realtà, quando si tratta di costruire strumenti software su misura, uno degli obiettivi è semplificare le attività quotidiane senza perdere flessibilità.

La soluzione istintiva è quella vista nel nostro esempio: aggiungere filtri su filtri. Così facendo si generano problemi derivanti dalla complessità della funzione di ricerca:

  • aumentano i costi di realizzazione e manutenzione del software;
  • un difetto nell’implementazione, oltre a essere difficile da individure, può produrre risultati errati;
  • un’interfaccia utente complessa induce nell’operatore il dubbio di commettere errori (“non ho trovato quello che cerco perché non è nell’archivio o perché ho sbagliato uno dei dieci parametri?”).

Una soluzione migliore consiste nello comporre la funzione di ricerca in due strumenti da utilizzare in contesti diversi.

Ricerca libera

Fornendo un’unica stringa di testo, gli elementi dell’archivio sono selezionati in base al contenuto di tutti i campi che si ritengono significativi; questi campi devono essere chiari all’utente.

Funziona molto bene in due casi tra loro opposti e molto frequenti:

  • si conosce una chiave di ricerca univoca, come il numero di contratto, che consente di trovare rapidamente quanto cercato (rapidità e precisione);
  • si conosce solo parte di un’informazione non univoca, come il cognome del contraente, che è associata a quanto cercato e consente di ottenere un ristretto numero di risultati da esplorare “a vista” (completezza della ricerca).

Viste utente

La vista utente è una finestra sui dati che ha una corrispondenza diretta col modo in cui gli operatori vedono il contenuto dell’archivio durante lo svolgimento delle loro mansioni. E’ importante considerare gli operatori come classe di utenza senza affidarsi al giudizio di un solo individuo.

Per essere tale, una vista utente deve avere caratteristiche precise:

  • rappresentare concetti che prescindono dall’esistenza di un sistema di gestione informatizzato come le “fatture pagate/non pagate” o i “contratti scaduti”;
  • non richiedere la definizione di parametri di ricerca granulari, come “il numero contratto” o “l’intervallo di date”, ma proporne di semplici quali “le fatture pagate nell’ultimo mese” o “i contratti scaduti” (ovviamente a oggi);
  • avere al massimo tre parametri definibili dall’utente; l’ideale sarebbe non averne affatto ma spesso un parametro è intrinseco nel modello di lavoro (es. “fatture pagate/non pagate”);
  • utilizzare ordinamenti predefiniti che siano evidenti osservando il risultato della ricerca quali “ordine alfabetico per contraente” o “prima le fatture scadute da più tempo”;
  • essere parte irrinunciabile della specifica funzionalità che si sta realizzando e non prevista per un possibile uso futuro.

Infine, dopo aver creato le viste utente, occorre resistere alla tentazione di unirle per ottenere funzioni di ricerca più “potenti”.