{"id":632,"date":"2016-06-27T19:09:12","date_gmt":"2016-06-27T17:09:12","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/object-oriented-ux\/"},"modified":"2016-06-27T19:09:12","modified_gmt":"2016-06-27T17:09:12","slug":"object-oriented-ux","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/object-oriented-ux\/","title":{"rendered":"UX orientata agli oggetti"},"content":{"rendered":"
\n

Nel giugno del 2012, mentre lavoravo alla CNN.com<\/a>, 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<\/em> un’esperienza responsive.<\/p>\n

La posta in gioco era alta. La sera delle elezioni \u00e8 come la domenica del Super Bowl per CNN.com. Se eseguita bene, \u00e8 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.<\/p>\n

Poi appresi che il primo development sprint sarebbe partito dopo quattro giorni. Quattro giorni?!<\/em>. Il mio project manager mi disse in maniera calma: \u201cNon preoccuparti. I dev hanno solo bisogno di un template<\/em> per il primo sprint. Mentre stanno creando il primo template, puoi passare al successivo\u201d.<\/p>\n

Eh? Come pensavano che avrei potuto progettare un ingranaggio di una macchina senza prima avere una bozza del design della macchina?<\/p>\n

Pensare in maniera cos\u00ec 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\u00f9 ci sono parti in movimento in un sistema, pi\u00f9 ci sono occasioni per un disastro.<\/p>\n

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:<\/p>\n

\"Il<\/p>\n

Schema dell’esperienza proposta per l’election night che ho presentato per la prima volta al team di CNN.com.<\/p>\n<\/div>\n

Ho presentato questo schema in una sala conferenze piena di stakeholder che si aspettavano di esaminare un singolo template \u201cfinito\u201d. 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.<\/p>\n

Lo schema che avevo prodotto nel 2012 era tutto fuorch\u00e9 perfetto, perlopi\u00f9 perch\u00e9 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<\/em> piuttosto che dell’organizzazione in base alle priorit\u00e0<\/em>. Avevo inserito in una homepage prematura una copertina dell’esperienza (che adesso avrei dovuto progettare per ultima<\/em>). Avevo provato a creare una navigazione top-level sempre presente, invece di concentrarmi prima sui moduli di contenuto.<\/p>\n

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.<\/p>\n

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<\/a>, Race (per il senato)<\/a> e Risultati per Stato-Race<\/a>.<\/p>\n

\"Uno<\/p>\n

Come presenterei l’esperienza della election night se dovessi progettarla oggi.<\/p>\n<\/div>\n

Ha funzionato: la nostra election night responsive \u00e8 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\u00f9 complesso.<\/p>\n

Oggi, ho trasformato quell’esperienza in stile \u201cprova del fuoco\u201d in un processo basato sugli oggetti, testato e strutturato. In questo articolo, vi introdurr\u00f2 alla UX orientata agli oggetti, condivider\u00f2 il mio processo di mappatura degli oggetti e vi aiuter\u00f2 a cominciare a farlo voi stessi.<\/p>\n<\/div>\n

\n

Mobile first, content first e objects first<\/h2>\n

Separate sempre il pensiero delle cose del mondo reale dai documenti che descrivono quelle cose. Risorsa prima di rappresentazione.<\/p><\/blockquote>\n

Mike Atherton<\/a><\/p>\n

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

Questo approccio si adatta bene con il concetto di content first: design \u201ccontent-out\u201d opposto a design \u201ccanvas-in\u201d<\/a>. Dovete sapere quello che direte prima di potergli assegnare una priorit\u00e0.<\/p>\n

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\u00f2 essere organizzato, a cui si possono assegnare priorit\u00e0, che si pu\u00f2 analizzare e aggiornare prima che cominci il lavoro di design.<\/p>\n

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

Questa \u00e8 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.<\/p>\n<\/div>\n

\n

La OOUX \u00e8 potente<\/h2>\n

Notizia lampo! Questo \u00e8 il modo in cui lavorano i vostri backend engineers. Negli anni ’80, la comunit\u00e0 del software engineering cominci\u00f2 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\u00f9 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#.<\/p>\n

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: \u201cIn che modo l’oggetto x<\/em> parler\u00e0 all’oggetto y<\/em>? L’oggetto A<\/em> sar\u00e0 costituito da molti oggetti B<\/em>? Che attributi avr\u00e0 ciascun oggetto? Questa classe di oggetti erediter\u00e0 da quell’altra classe di oggetti?\u201d<\/p>\n

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’\u00e8 un’altra opzione. Nel suo libro del 1995, Designing Object Oriented User Interfaces<\/a><\/cite>, il designer ed ingegnere Dave Collins sostiene che basare il design sia del front-end sia del back-end su principi orientati agli oggetti \u201cporta coerenza al processo di sviluppo software. L’orientamento agli oggetti rivela corrispondenze strutturali profonde tra gli artefatti di analisi, design ed implementazione\u201d.<\/p>\n

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