UX orientata agli oggetti

Nel giugno del 2012, mentre lavoravo alla CNN.com, mi fu dato il compito di progettare la user experience della serata delle elezioni. Nei cinque mesi seguenti, ho dedicato la mia vita a quella singola serata, ma il successo per me non aveva niente a che fare con chi avrebbe vinto. Ero preoccupata della findability, della visualizzazione dei dati, di un canvas che cambia forma e di come diavolo far funzionare i flyout al mouse-over su un iPhone. Per la prima volta nella storia, CNN.com stava creando un’esperienza responsive e, per la prima volta nella storia, io stavo progettando un’esperienza responsive.

La posta in gioco era alta. La sera delle elezioni è come la domenica del Super Bowl per CNN.com. Se eseguita bene, è una delle serate a maggior rendimento in un ciclo di quattro anni. Per aggiungere altra pressione, avevamo una tempistica stretta, con una deadline che non si sarebbe potuta spostare: il 6 novembre o si fallisce.

Poi appresi che il primo development sprint sarebbe partito dopo quattro giorni. Quattro giorni?!. Il mio project manager mi disse in maniera calma: “Non preoccuparti. I dev hanno solo bisogno di un template per il primo sprint. Mentre stanno creando il primo template, puoi passare al successivo”.

Eh? Come pensavano che avrei potuto progettare un ingranaggio di una macchina senza prima avere una bozza del design della macchina?

Pensare in maniera così miope funzionava bene quando progettavamo pagine su schermi a larghezza fissa: potevamo cavarcela mettendo insieme i pezzi progettati in dipartimenti non comunicanti tra loro. Non sapevo molto del responsive design, ma sapevo che avevamo bisogno di un sistema semplice e pulito, non di pagine messe assieme. E come sanno tutti gli ingegneri e i designer, più ci sono parti in movimento in un sistema, più ci sono occasioni per un disastro.

Quindi, durante quei primi quattro giorni, non ho fatto il wireframe di un solo template disconnesso, ho fatto uno schizzo di un sistema olistico fatto di parti riutilizzabili ed interscambiabili. Ecco come appariva:

Schema dell’esperienza proposta per l’election night che ho presentato per la prima volta al team di CNN.com.

Ho presentato questo schema in una sala conferenze piena di stakeholder che si aspettavano di esaminare un singolo template “finito”. Ho dimostrato di aver ridotto il numero di componenti e template rispetto al design del 2008 e che il nuovo sistema era sufficientemente semplice da entrare in un foglio di carta A4! Grazie al cielo, una massa critica di persone nella stanza ha capito il valore di quello che avevo presentato: meno cose da realizzare.

Lo schema che avevo prodotto nel 2012 era tutto fuorché perfetto, perlopiù perché stavo cercando di fare troppo, troppo presto. Ho fatto una falsa partenza sull’implementazione, mettendo nella bozza i flyout e i grafici a barre. Stavo ancora pensando in maniera desktop-first, preoccupandomi del posizionamento piuttosto che dell’organizzazione in base alle priorità. Avevo inserito in una homepage prematura una copertina dell’esperienza (che adesso avrei dovuto progettare per ultima). Avevo provato a creare una navigazione top-level sempre presente, invece di concentrarmi prima sui moduli di contenuto.

Per quanto imperfetto, lo spirito della bozza e il ragionamento che ci stava dietro avevano lasciato il segno. Non era una sitemap, non mostrava gerarchia. Non era uno storyboard, non abbozzava un flusso dei task. Al contrario, questo diagramma mappava un sistema di cose e ha cambiato il modo in cui faccio UX.

Togliendo l’interazione, la navigazione persistente, l’homepage e il layout, ecco lo schema che avrei creato allora se avessi saputo quello che so adesso, mostrando un sistema con tre oggetti: Stati, Race (per il senato) e Risultati per Stato-Race.

Come presenterei l’esperienza della election night se dovessi progettarla oggi.

Ha funzionato: la nostra election night responsive è stata il Super Bowl Sunday che si auguravano i capi di CNN. Ma ce l’abbiamo fatta per il rotto della cuffia, lavorando fino a tarda sera e nei weekend per essere sicuri che il design funzionasse su una miriade di device. Non sono sicura che ce la saremmo cavata con un design anche solo leggermente più complesso.

Oggi, ho trasformato quell’esperienza in stile “prova del fuoco” in un processo basato sugli oggetti, testato e strutturato. In questo articolo, vi introdurrò alla UX orientata agli oggetti, condividerò il mio processo di mappatura degli oggetti e vi aiuterò a cominciare a farlo voi stessi.

Mobile first, content first e objects first#section1

Separate sempre il pensiero delle cose del mondo reale dai documenti che descrivono quelle cose. Risorsa prima di rappresentazione.

Mike Atherton

Mi ci è voluto quasi un anno per riaddestrare me stessa a pensare davvero in maniera mobile first, ma oggi, lo faccio anche quando progetto applicazioni software desktop-only. Per me, mobile first significa semplicemente assegnare priorità in maniera forzata. Significa che penso al layout in un secondo momento. Cominciate con un “design” a singola colonna (noto anche come elenco) e obbligate voi stessi a dare delle priorità al contenuto e alla funzionalità con un ranking sequenziale.

Questo approccio si adatta bene con il concetto di content first: design “content-out” opposto a design “canvas-in”. Dovete sapere quello che direte prima di potergli assegnare una priorità.

A volte, questo significa avere il vero effettivo copy da subito, particolarmente quando state lavorando a un sito con una massa critica di copy evergreen o informativo che può essere organizzato, a cui si possono assegnare priorità, che si può analizzare e aggiornare prima che cominci il lavoro di design.

Ma se state lavorando su un sito che per il 99% è costituito da oggetti istanziati (articoli delle news, prodotti), non c’è modo di creare un piano del copy completo direttamente o addirittura non sarà mai possibile. Invece di dare priorità al vero copy, dovete pensare in termini di oggetti.

Questa è la OOUX: mettere il design degli oggetti prima del design delle azioni procedurali e pensare a un sistema attraverso le lenti degli oggetti del mondo reale nel modello mentale di un utente (prodotti, tutorial, location), non azioni del mondo digitale (cerca, filtra, confronta, check out). Determiniamo le azioni dopo aver prima definito gli oggetti invece che utilizzare il tradizionale processo actions-first che salta direttamente nei flussi, nelle interazioni e nelle features.

La OOUX è potente#section2

Notizia lampo! Questo è il modo in cui lavorano i vostri backend engineers. Negli anni ’80, la comunità del software engineering cominciò a passare dai linguaggi procedurali a quelli orientati agli oggetti, che hanno dei vantaggi come il riutilizzo del codice, l’encapsulation dei dati e un mantenimento più semplice del software. La maggior parte dei programmatori porta in vita i vostri design usando linguaggi orientati agli oggetti come Java, Ruby, Python, C++ o C#.

Gli ingegneri cominciano il loro processo mappando gli oggetti che rientrano nel dominio del problema, cosa che gli UXer dovrebbero fare fin dal primo giorno. Quando osservano i vostri wireframes o prototipi, per prima cosa fanno il reverse-engineer del vostro design, per analizzarne gli oggetti. Pensano: “In che modo l’oggetto x parlerà all’oggetto y? L’oggetto A sarà costituito da molti oggetti B? Che attributi avrà ciascun oggetto? Questa classe di oggetti erediterà da quell’altra classe di oggetti?”

Sul web, sviluppiamo in maniera object-oriented, ma progettiamo ancora in maniera procedurale, concentrandoci su una gerarchia drill-down o su task flow lineari. Ma c’è un’altra opzione. Nel suo libro del 1995, Designing Object Oriented User Interfaces, il designer ed ingegnere Dave Collins sostiene che basare il design sia del front-end sia del back-end su principi orientati agli oggetti “porta coerenza al processo di sviluppo software. L’orientamento agli oggetti rivela corrispondenze strutturali profonde tra gli artefatti di analisi, design ed implementazione”.

Definire oggetti che imitino i modelli mentali dei vostri utenti fornisce un’impalcatura per la comunicazione del team. Vi dà un linguaggio condiviso. Oltre alla coesione del team, il progettare in maniera object-oriented può anche aiutarvi a:

• aderire al modello mentale dei vostri utenti, migliorandone l’esperienza,
• assicurare la semplicità, riducendo qualsiasi complessità accidentale dovuta a elementi di design estranei,
• far crescere e mantenere il vostro prodotto: si può iterare sugli oggetti senza influenzare il resto del sistema e i nuovi oggetti possono essere incorporati in maniera graceful (invece che agganciati alle feature),
• creare API migliori con oggetti portabili e indipendenti,
• ottenere punti brownie dal contenuto strutturato e dal cross-linking di valore.

Poi, ecco la mia giustificazione preferita: la OOUX vi permette di creare una navigazione contestuale più importante che mai. In altre parole, aiuta gli utenti a raggiungere il contenuto attraverso il contenuto.

La navigazione persistente potrebbe essere nascosta alla vista sotto un’icona hamburger quando l’utente è su un piccolo schermo, ma anche su un monitor a 17 pollici, la navigazione più bella fissa in cima allo schermo potrebbe essere ignorata. Quando un utente visita un sito per la prima volta, spesso gravita attorno ai grossi oggetti luccicanti, utilizzando la navigazione o la barra di ricerca solo come piano di backup. Come ha intelligentemente riassunto Val Jencks, “Andiamo prima al contenuto sulla pagina. La top navigation è l’uscita di sicurezza.”

Se un utente sta leggendo una ricetta, dove vorrà poter andare dopo? Dovremmo anticipare il modo in cui potrebbero voler esplorare basandosi sulla ricetta che stanno leggendo e non lasciare a loro l’esplorazione di un menu gerarchico o scegliere un termine per la ricerca. E sicuramente non dovremmo lasciarli con qualche “ricetta correlata” e considerare finito il nostro lavoro. Potrebbero voler vedere tutte le ricette che sono state pubblicate da quel cuoco. O magari vorrebbero vedere più ricette che usano la bietola rossa, basandosi su quell’ingrediente?

Se stiamo pensando in maniera object-oriented, sperimenteremo con i modi in cui ciascun oggetto potrebbe essere in relazione con altri oggetti, andando oltre l’ovvio. Magari gli chef hanno degli ingredienti preferiti? Nel design object oriented qua sotto, un utente può continuamente esplorare istanze di questi tre oggetti (ricetta, chef, ingrediente) senza mai raggiungere un vicolo cieco. Il contenuto è la navigazione ed è tutta nel contesto.

In questo modello dell’oggetto le ricette, gli chef e gli ingredienti sono interconnessi, permettendo un’esplorazione continua.

Se questo concetto vi suona famigliare, probabilmente avete letto del content modelling o l’avete messo in pratica. Negli ultimi cinque anni, molti architetti dell’informazione (vedi il lavoro di Mike Atherton) e molti content strategists (si veda il lavoro di Rachel Lovinger) hanno cominciato a concentrarsi su sistemi di tipi di contenuto riutilizzabili e sono stati coinvolti maggiormente nel design dei CMS: l’utente primario è chi crea il contenuto, non solo l’utente finale.

Nel suo libro Content Everywhere, Sara Wachter-Boettcher ci incoraggia a modellare il nostro contenuto prima di buttarci nei wireframe e nell’interaction design:

Il content modeling vi dà una conoscenza sistematica: vi permette di vedere che tipi di contenuto avete, che elementi includono e in che modo operano in maniera standardizzata.

Sfortunatamente, l’arte del content modeling è ancora sconosciuta a molti UX designer: sentiamo “contenuto” e supponiamo che non si applichi a noi. Questo è specialmente vero nel caso degli UXer che hanno a che fare con software as a service o con il product design: le strategie che coinvolgono il contenuto a volte cadono nel vuoto.

Object mapping#section3

L’object mapping, il mio processo che sta dietro alla OOUX, è il content modeling per i designer che non hanno a che fare con il contenuto nel senso comune ma che hanno ancora bisogno di progettare sistemi, e non solo sistemi di implementazione. Sebbene una concisa collezione di template e moduli riutilizzabili sia irrinunciabile, quei design pattern non hanno significato per un utente a meno che siano sostenuti da un sistema di oggetti del mondo reale che si abbinano al modello mentale di quello specifico utente. Concentratevi prima sulla progettazione del sistema di oggetti del mondo reale, poi sulla progettazione di un sistema di implementazione che porti il tutto alla vita. Questo è il fulcro di tutto il mio lavoro di design, perché trasforma gli obiettivi in un sistema eseguibile che soddisfa questi obiettivi.

Tirate fuori i vostri post-it, radunate il vostro team e fate un po’ di spazio sul muro perché adesso vi guiderò attraverso il mio processo.

Step 1: estrarre gli oggetti dagli obiettivi#section4

Uno dei benefici dell’object mapping che preferisco è che fornisce un ponte perfetto tra obiettivi e design. Invece di scrivere a casaccio sulla whiteboard, in stile A Beautiful Mind, l’object mapping fornisce un framework ordinato per spostarsi dalla strategia al design. (Per favore, continuate pure a fare John Nash alla lavagna bianca, ma prima create una object map: darà alla vostra creatività sfrenata un solido punto di appoggio).

Come esempio, supponiamo che stiate creando un’applicazione che aiuti i brand di ristrutturazione della casa a connettersi su DIYers. Dopo aver fatto le user interviews, un’analisi dei competitors e aver discusso con gli stakeholder, abbiamo il nostro brief:

Dare ai DIYers un punto in cui pubblicare le problematiche di ristrutturazione della casa che stanno affrontando, sollecitando delle soluzioni potenziali da parte delle aziende produttrici (brand). I DIYers ottengono delle soluzioni da esperti per i propri problemi e i brand ottengono visibilità.

• I DIYers possono cercare e navigare tra le problematiche esistenti, commentando le soluzioni proposte.
• I brand possono cercare e navigare tra le problematiche aperte che potrebbero andare bene per i propri prodotti.
• I brand possono creare soluzioni che mostrino uno o più dei loro prodotti.
• I DIYers possono chiudere un problema dopo aver scelto una soluzione e poi creare un follow-up su quanto questa abbia funzionato bene.
• I brand possono creare una libreria di soluzioni che possono essere riutilizzate in varie situazioni.

Per estrarre gli oggetti, praticamente sottolineiamo i nomi.

Sottolineare i nomi nel brief del progetto è il primo passo per mappare gli oggetti.

Riconoscere i nomi è una roba da prima elementare, ma estrarre gli oggetti è un’arte ricercata:

• prestiamo particolare attenzione ai nomi che continuano a saltar fuori, come problematiche e soluzione. Questi saranno oggetti importanti.
• Ignoriamo il nome astratto visibilità perché descrive un concetto che speriamo emergerà dal nostro sistema, ma non è un oggetto tangibile che farà parte del nostro sistema.
• Ignoriamo libreria perché è semplicemente una collezione di altri oggetti (soluzioni). Cercate parole come calendario, catalogo o mappa. Queste sono solitamente delle visualizzazioni fantasiose dell’elenco degli oggetti principali, rispettivamente evento, prodotto o luogo. Per esempio, la maggior parte dei sistemi che hanno a che fare con dei luoghi avranno una sola visualizzazione della mappa (eventualmente filtrabile). La mappa è un meccanismo di design, non un oggetto di per sé.
• Deduciamo un oggetto dalle due azioni “commentare” e “follow up”, quindi, abbiamo bisogno di qualche tipo di oggetto commento.
• Notiamo che un oggetto problematica ha bisogno di più stati: pubblicata, in corso, chiusa e chiusa con feedback.

Con questo esercizio di 10 o 15 minuti, abbiamo i principali blocchi costituent del nostro sistema. Scriviamo ogni oggetto su un post-it blu.

Scriviamo ogni oggetto sul suo post-it per visualizzare i blocchi costituenti del nostro sistema.

Poi, dobbiamo definire di cosa sono fatti gli oggetti.

Step 2: definire il contenuto principale degli oggetti#section5

Il content modeling richiede che comprendiate contemporaneamente i vostri obietti al livello più alto e che conosciate fin nei minimi dettagli gli attributi del vostro contenuto.

—Sara Wachter-Boettcher, Content Everywhere

Più o meno. Abbiamo appena determinato i macro-blocchi base del nostro sistema e adesso dobbiamo determinarne, per ciascuno, gli elementi granulari. Questa attività è spesso riservata per il design dettagliato dell’ultimo minuto, ma definire gli elementi mentre si è nel mezzo dei post-it è liberatorio: quando a breve comincerete a fare bozze, potrete concentrarvi sugli aspetti più creativi. Inoltre, avere delle conversazioni all’inizio su cosa costituisca ciascun oggetto, vi può aiutare ad evitare, più in là nel gioco, momenti in cui un elemento importante (o estraneo) è stato tralasciato e il cambiamento deve essere fatto su svariati documenti di design.

Ancora più importante, potete fare conversazioni con il team come “I DIYers dovrebbero essere in grado di aggiungere il proprio budget a una problematica?” prima che i non-designers osservino i wireframes o i layout. Questo vi aiuta a mantenere focalizzate le conversazioni piuttosto che bloccarvi su qualcosa come l’icona per il budget.

A questo punto del processo, io separo due tipi di elementi: il contenuto centrale e i metadati. Il contenuto centrale, come il testo e le immagini, va sui post-it gialli. I metadati, qualsiasi dato su cui l’utente può agire con ordinamento o filtraggio, va sui post-it rossi.

Gli elementi granulari di ciascuno dei nostri oggetti sono mappati con i tradizionali post-it.

Se il vostro team non è sicuro di un potenziale pezzo di contenuto, scrivetelo comunque e aggiungetegli semplicemente un punto interrogativo. Andate avanti e tornateci in seguito.

Step 3: annidate gli oggetti per il cross-linking#section6

E adesso il sistema prende vita. Fate una serie di esperimenti di pensiero per ciascun oggetto. Cominciate con un oggetto, considerate i modi in cui ciascuno degli altri oggetti può “annidarsi” al suo interno. Man mano che annidate gli oggetti, state definendo le relazioni tra essi e, implicitamente, anche la navigazione contestuale. Usando i post-it blu, sperimentate in che modo ogni oggetto potrebbe inserirsi dentro agli altri oggetti fratelli.

Completiamo il modello aggiungendo dei post-it che mostrano in che modo altri oggetti di contenuto possano “inserirsi” all’interno di ciascun oggetto.

Per esempio, ecco in che modo potrebbe andare questa conversazione riguardante l’oggetto sfida:

• DIYer: “Facile, il DIYer è l’autore della problematica.”
• Soluzione: “Questo è l’oggetto annidato principale in una problematica. Dobbiamo mostrare tutte le soluzioni pubblicate per questa problematica.”
• Brand: “Eh, non direte sul serio? Il brand farà parte dei moduli della soluzione (come autore della soluzione), ma probabilmente non sarà direttamente inserito in una problematica.”
• Prodotto: “Di nuovo, parte di una soluzione, non annidato. Huh. A meno che i DIYers possano pubblicare i prodotti che hanno già in casa?”
• Commento: “Hmmm. Probabilmente relegato alla soluzione… Dobbiamo tenere tutti i commenti nella soluzione? O i brand e i DIYers dovrebbero magari poter pubblicare domande direttamente nella problematica? Dobbiamo esplorare meglio questa cosa.”

Notate che non tutto è chiaro. Alcune cose, come la discussione sui commenti, potrebbero essere risolti meglio durante la fase di sketching, ma esplorerete intenzionalmente un problema di design identificato, invece che un problema che vi coglie di sorpresa.

Step 4: ranking forzato#section7#section7

Ugh. Questo è lo step più diabolicamente difficile. Nei passi precedenti, è molto importante che scriviate ogni elemento ed oggetto annidato su un post-it separato. Perché? Perché adesso andremo a riordinare gli elementi, dai più importanti ai meno importanti.

Il nostro modello dell’oggetto, riordinato in base a quanto è importante ciascun elemento.

Questo elenco ordinato non fornisce necessariamente una rappresentazione diretta di cosa si troverà in cima o in fondo allo schermo. Nel design, la priorità può manifestarsi come dimensione o colore. Il contenuto a bassa priorità potrebbe essere piazzato in alto sullo schermo, ma in un pannello “collapsed” (evvai, progressive disclosure!). Quindi, rassicurate il vostro team che stiamo semplicemente assegnando delle priorità, non facendo design.

Mentre assegnate le priorità, immaginatevi quali elementi saranno più importanti per i vostri utenti: quali pezzi sono informazioni “must have” e quali “nice to have”? Quando considerate i metadati, pensate ai più importanti meccanismi di ordinamento e filtraggio. Se l’ordinamento di default sarà per “popolarità”, allora il “numero di DIYers che hanno messo like a questo” sarà di priorità alta.

Nuova base e nuovo framework#section8

Ora avete un sistema basato sugli oggetti derivante direttamente dai vostri obiettivi, ma tenete a mente che, sebbene questa attività fornisca una base per progettare un sistema di implementazione, interazioni e navigazione persistente, non scolpisce alcuna decisione nella pietra. È una prima bozza! Man mano che iterate, verranno introdotti ed eliminati nuovi oggetti ed elementi e verranno loro assegnate nuove priorità. La vostra object map fornirà un framework per una conversazione e una collaborazione continua: con il vostro cliente, con il vostro team di design e con i vostri developer.

OOUX non è un nuovo processo end-to-end: è un nuovo ingrediente da aggiungere al vostro processo attuale. Aggiunge chiarezza, semplicità e coesione al modo in cui progettate e ai prodotti che rilasciate nel mondo.

Illustrazioni: {carlok}