Designer e tecnologie, alcune ipotes
8.1 Progettare intorno alle tecnologie 1 L’algoritmo è il succo del processo
Non importa quanto sia fatta bene la tua interfaccia utente, sarebbe meglio se c’è ne fosse di meno (Cooper, 2007 ²⁰)
Meno interfaccia dovrebbe voler dire meno lavoro per l’utente; e nei tipi di prodotti moderni che stanno venendo progettati ora (lampade smart, smartwatch e molti altri) l’utente non vuole avere delle complesse interfacce. È uno dei motivi per cui si parla così tanto di algoritmi ed intelligenze artificiali, si possono usare per semplificare le interazioni. Ma nello specifico cosa significano per il design? (ed in questo esempio per l’interaction design?)
Prendiamo la Discover Weekly di Spotify. Una volta alla settimana Spotify aggiorna il proprio utente con una dozzina di tracce che il proprio algoritmo pensa possano piacergli. L’opinione che le persone hanno di questa funzione è di essere qualcosa di importante, piacevole e uno dei motivi che le incentiva a continuare a pagare l’abbonamento. Ma quali sono le parti di progettazione? È una semplice playlist, come molte altre. Cosa avrebbe progettato un interaction designer? Probabilmente un mockup con uno screenshot di una playlist generica con scritto sopra mettere qui possibili
canzoni per l’utente. L’ambito è certamente quello dell’interaction
design, visto che il contenuto della playlist viene determinato dal comportamento dell’utente, e il comportamento è il campo del design dell’interazione. Ma in questo caso il lavoro viene effettuato dall’ingegnere che programma l’algoritmo; gli stessi algoritmi però stanno cominciando a cambiare anche tipi interazioni molto più complesse.
8.1.2 Un esempio nel campo dell’interaction design
Immaginiamo di progettare per conto di una compagnia di autobus. L’utente medio ha una richiesta abbastanza semplice, sapere dove si trova il proprio autobus. Come possono gli algoritmi aiutare? Innanzitutto gli algoritmi hanno bisogno di dati; con dati unici si possono creare servizi dal valore unico. Abbiamo le tabelle degli orari, sappiamo dove gli autobus devono essere e quando; ma queste sono informazioni pubbliche. Abbiamo però anche i dati GPS degli autobus; questi si che sono dati unici, li ha solo la compagnia. Si possono quindi mettere in relazione i viaggi effettuati con le tabelle di marcia e capire quali autobus hanno fatto ritardo; interessante ma non utilissimo per la risoluzione della domanda iniziale. Si possono allora aggiungere dati sul meteo locale, sugli ingorghi del traffico, sui giorni di vacanza, sui lavori stradali; trovare correlazioni negli eventi passati e fare previsioni sul futuro. Con i dati giusti si può costruire una applicazione che sarà in grado di dire il tuo autobus farà 10
minuti di ritardo il giorno prima che lasci la stazione.
Ma gli algoritmi non sono magici, qualcuno deve prima scriverli. Se quindi ad un designer viene un idea, deve avere un minimo di conoscenza nell’ambito degli algoritmi per potere comunicare in modo efficiente con un ingegnere su come e se programmarne uno.
8.2.3 Input
Quando si parla di dati ci sono elementi di cui preoccuparsi.
8.2 Comunicare con gli ingegneri
Un processo ingegneristico si può descrivere in questo modo: un set di input (i dati sulle tabelle di marcia degli autobus, sui lavori, sul meteo ecc…), poi un algoritmo ed infine un output; nell’ipotetico esempio preso in analisi sapere un eventuale ritardo.
La qualità per esempio; nell’esempio degli autobus i dati GPS dovrebbero essere abbastanza precisi. Qualche volta però i dati di allenamento potrebbero essere imprecisi e disturbati. Per esempio il GPS potrebbe non aver registrato bene in alcune zone, fornendo dati disturbati. Dati imprecisi possono portare un algoritmo ad un adattamento eccessivo (ovvero effettuare previsioni errate a causa di errori durante l’allenamento). Gli ingegneri vorranno quindi sapere la qualità dei dati in possesso. Se il problema da risolvere è abbastanza complesso ci si affida a molti livelli di dati o si richiedono risposte molto precise, il sistema avrà bisogno di molti dati di allenamento. Un anno di dati? Due anni di dati? Di più? Può essere difficile trovare dati rispetto a periodi lontani. Aggiungere livelli e livelli di dati servirà solo a complicare il processo di sviluppo di algoritmi che richiederà sempre più dati.
Capire i fattori principali è la chiave per raggiungere la soluzione in fretta. Se non si hanno molti dati, o la relazione che si sta cercando di capire è particolarmente complessa essere precisi sarà difficile, ma si può scegliere in quale direzione sbagliare. Alta tolleranza vuole dire sbagliare ma in modo prevedibile. Alta variabilità vuol dire in media non sbagliare ma ogni previsione potrebbe essere terribilmente fuori strada. Se si sta cercando di prevedere se un autobus farà ritardo basandosi su troppi pochi dati è meglio costruire un algoritmo che è più incline a dire che l’autobus sia in orario; in questo modo nessun utente rischia di perdere il proprio autobus. Ma non sarà la perfetta precisione di cui si è alla ricerca, quindi diamo per scontato che i dati in possesso siano in abbondanza. Se i dati nei livelli di ricerca sono complessi senza motivo l’algoritmo potrebbe risultare lento o inaffidabile. Quindi piuttosto che buttare dati sull’algoritmo è sempre una buona idea semplificare il contenuto di ogni data set. C’è bisogno di sapere gli orari precisi della pioggia? O basta sapere se ha piovuto in una certa ora? O in un punto della mattina? C’è bisogno di differenziare pioggia forte e leggera? Tutto queste domande determinano l’ammontare di informazioni presenti sul meteo. Qualche volta dati più semplici portano ad output più precisi.
8.2.1 Output
Come designer bisogna sapere che tipi di output possono essere utili all’utente. È abbastanza prevedere se l’autobus farà ritardo o no? Bisogna dire in ritardo di più di 5 minuti? O dare il numero preciso? Più l’output è dettagliato, più complicata sarà la parte di programmazione quindi è meglio saperlo dall’inizio effettuando sessioni di ricerca sui propri utenti.
Bisogna inoltre anche valutare l’interfaccia con cui mostrare gli output. Provate ad inserire i vostri consigli in un’interfaccia che promette interazione umana con abilità e maniere umane prossime allo zero (come il famoso Clippy di Microsoft Office) e la gente andrà in bestia. Se ci sono grandi possibilità di errore è sempre meglio adottare un approccio più umile e tranquillo. Quando l’app Mail di iOS capisce che si sta scrivendo una lettera a Marco e Giovanni, suggerisce che probabilmente converrebbe inviarla agli altri membri del gruppo. Ed è anche una previsione fattibile, ma sottile e facilmente ignorabile. Uno degli aspetti più importanti delle prossime generazioni di design (nello specifico interaction design) sarà centrato intorno ad i buoni modi maniere di suggerire ed aiutare.
8.2.2 Algoritmi
Da cosa deriva l’algoritmo che fornisce questi output? Quando si sviluppa un servizio si comincia con un algoritmo base e lo si allena a riconoscere situazioni ed a fare previsioni. Come? Fornendogli dei semplici set di input (meteo, lavori ecc…) e degli output già conosciuti (gli orari di arrivo reali degli autobus). L’ingegnere poi regola l’algoritmo per gli input e output. Ci sono molti tipi di algoritmi; scegliere quello più adatto è lavoro dell’ingegnere.
Alla fine del processo di programmazione si dovrebbe avere un algoritmo altamente allenato che fornisce le informazioni richieste in base ad i dati a disposizione. Si può quindi avviare l’algoritmo con dati reali. Probabilmente purtroppo non sarà abbastanza preciso,
soprattutto all’inizio; l’utilizzo di metodi come beta private o feedback loop con gli utenti sono elementi chiave per il miglioramento. Quello che alla fine viene a costruirai è quindi una macchina da previsione. Con l’aumento delle API e degli strumenti probabilmente sempre più designer si cimenteranno nella programmazione di algoritmi in futuro ma il vero valore del progettista sta nel definire quali output mostrare all’utente e come mostrarli.