Bad Design – Il DevOps e la User Experience

Mouse Apple iMac

Spoiler: Il colpevole è il Designer (ma vale in generale per tutti) che “non ci mette la testa”.

E’ un po’ di tempo che mi capita di ritrovarmi in chiacchierate (virtuali e non) con altri “addetti ai lavori”, il cui tema comune è la bassa professionalità/competenza che si riscontra da qualche anno a questa parte nella media dei programmatori, web designer, sistemisti e via dicendo, che si incontrano nella vita lavorativa quotidiana.

Personalmente ho già espresso la necessità di una buona competenza di base e di una cultura della collaborazione nell’ambito dei gruppi DevOps, in particolare quando attribuivo ad un generale “abbassamento di livello” del rigore ingegneristico di base nell’IT, la molla che ha reso necessario riconciliare i mondi del Dev e l’Ops.

In quest’ambito, ritengo che possa essere interessante concentrarsi su coloro che, in un modo o nell’altro, definiscono il diretto successo di un prodotto disegnandone o realizzandone l’interfaccia utente, realizzando quindi quello che “quelli bravi” ultimamente chiamano User Experience.

Chi ha riconosciuto in soggetto nella foto in testa all’articolo dovrebbe aver capito dove voglio andare a parare.

Oggi parleremo infatti di:

Bad Design

Perché associare un termine così antipatico a un prodotto della nota marca IT “che si occupa di frutta” (come diceva Forrest Gump) che ha da sempre fatto scuola nel campo del Design e dell’Esperienza utente?

Scusatemi, ma per me un mouse che quando si scarica non è fisicamente usabile perché, come si vede in foto, il foro dell’alimentazione è nella sua parte inferiore, è una delle peggiori stupidaggini che potessero fare.

Cosa c’entra il Bad Design con il DevOps? C’entra perché bisogna sempre, sempre, SEMPRE, tenere in mente che il DevOps è una metodologia per gestire il ciclo di vita di un prodotto END TO END, dove la seconda END sta per UTENTE FINALE.

Potete fare tutto con le tecnologie migliori, con le metodologie più all’avanguardia, con il gruppo di lavoro più coeso ed efficace, ma se poi il cliente non usa il prodotto, che avete “DevOpsato” a fare?

Ne segue che già in fase di Design, soprattutto in tempi in cui l’Utente decreta la nascita e la fine di imperi con un “like”, bisogna fare in modo di non “irritarlo”.

Come si fa? Intanto io comincerei con una semplice domanda al nostro Designer, programmatore, grafico di turno:”Ti piace quello che hai fatto? Tu lo useresti?”.

Può sembrare incredibile ma questa domanda a volte fa miracoli, pensate che ha fatto si che il mio falegname sostituisse una maniglia con un pomello in una delle mie porte nell’atrio (dove ci sono solo pomelli, by the way), senza controbattere e senza sovrapprezzo; e se lo fa un falegname, che lavora con “il fisico”, si possono sforzare di farlo anche i cari colleghi del mondo digitale.

Qual’è il punto? Il punto è che a volte basta metterci la testa e un briciolo di amore per il proprio lavoro per far si che qualcosa che risulta macchinoso da usare venga riadattato(per quanto possibile), per renderlo un po’ più comodo.

Parlo di amore per il proprio lavoro perché mi ostino a sperare che, contrariamente a quello che si dice in giro, la maggioranza di chi ha deciso di “buttarsi nell’IT” l’abbia fatto per interesse e passione e quindi prova ancora soddisfazione per un prodotto ben realizzato (come il mio falegname quando mi ha riconsegnato la porta).

Bisogna tenere sempre presente, secondo me, che le interfacce, la UX (anche quella di un mouse) rappresentano, per forza di cose, un filtro tra l’Utente e l’Applicazione, più il filtro è fluido, più l’Utente avrà voglia di usare il prodotto che gli hai affidato, più rappresenta una barriera (o una serie di barriere), più l’Utente eviterà di usarlo e cercherà alternative più vicine alla sua sensibilità (è uno dei motivi per cui i grandi analisti stanno facendo una fortuna con il Bi-modale).

Succede con i prodotti, succede con gli strumenti che un’azienda acquista per poi vedere i propri dipendenti usarne altri, magari Open Source (alzi la mano chi preferisce un qualsiasi prodotto di monitoraggio proprietario a Nagios, persino con la sua interfaccia spartana), succede con i Processi Aziendali calati dall’alto e non costruiti intorno alla vita lavorativa reale.

E non venitemi a dire che gli utenti “vanno educati” perché questo vale in fase di raccolta requisiti, per arginare fenomeni tipo “voglio una ferrari con le ruote di cioccolata ed il vetro in pangrattato”, ma quando un prodotto “esce” DEVE essere USABILE o MUORE.

Purtroppo invece, noto che permane una certa tendenza a lasciare le cose “come sono state pensate all’inizio”, senza fare lo sforzo di andare oltre la fase di disegno iniziale o di trovare la soluzione per superare l’intoppo tecnologico di turno che lascia l’applicazione formalmente funzionante ma macchinosa.

Un esempio “web oriented” di questo potete viverlo ogni volta che dovete fare un tracking sul sito (molto giallo) del corriere collegato al nostro fantastico ente di corrispondenza nazionale, quando, messo il numero di tracking sulla pagina iniziale, venite portati su una pagina intermedia il cui unico scopo è quello di farvi ri-cliccare invio per avere l’agognata informazione.

Per la cronaca, il Bad Design vale anche per “le grandi opere”, come si è accorto chiunque abbia frequentato un convegno nello scatolone di metallo e vetro, progettato da un Archistar (come li chiamano ora)  con il nome di un personaggio di Verdone, che hanno piazzato nel cuore del Quartiere EUR di Roma (rovinando la prospettiva di viale Europa), quando si è accorto di sentire decisamente meglio le voci degli speaker delle sale adiacenti che non quella del relatore della sala in cui si trovava.

Ma qualche pannello di isolamento acustico no?