The pain with no name

Venticinque anni di sviluppo e design per il web e facciamo ancora collettivamente schifo in architettura dell’informazione.

Ci insegnano ad essere innovativi, creativi, agile ed iterativi, ma dove e quando ci insegnano come rendere chiare le cose complesse? Secondo me, la cosa più importante che possiamo fare per rendere il mondo un posto più chiaro è insegnare alle persone in che modo pensare criticamente riguardo a struttura e linguaggio.

Dobbiamo insegnare che le decisioni di architettura dell’informazione (IA) sono importanti così come il “look and feel” del technology stack che scegliamo. Dobbiamo insegnare l’importanza di semantica e significato. Dobbiamo insegnare a guardare oltre il modo in cui il resto del web è strutturato e a considerare invece in che modo il proprio angolino di web possa essere strutturato per supportare i propri fini univoci.

Il web era nato per essere un sito di costruzione democratizzato ed è diventato un posto che la maggior parte della gente visita più volte al giorno.

Anche il ruolo della IA è di democratizzazione. Gli strumenti e le risorse che usiamo per strutturare, progettare e sviluppare il web stanno diventando più semplici da usare, perciò abbiamo bisogno di conoscere l’impatto che le nostre scelte strutturali e linguistiche hanno sull’integrità, l’efficacia e l’accessibilità dei posti che creiamo.

Le scelte che facciamo sulla struttura e sul linguaggio perché il tutto abbia senso è l’essenza della IA. È una responsabilità distribuita irregolarmente tra job title che spaziano da user experience design, interaction design, content strategy, instructional design, environmental wayfinding e database architecture. È anche praticata ampiamente al di fuori del settore tecnologico e del design da persone come insegnanti, business owners, policy maker e altri che fanno sì che le cose abbiano senso per le altre persone.

Un dato di fatto: molte persone che praticano l’architettura dell’informazione non hanno mai sentito questo termine prima d’ora. Io credo che questo sia il motivo per cui non stiamo migliorando collettivamente in questa importante professione.

Senza un’etichetta, una nomenclatura comune, la IA può sembrare una montagna insormontabile. Supponiamo che stiate lavorando a come sistemare ed etichettare le parti del vostro sito web di marketing e contemporaneamente migliorando la categorizzazione del vostro catalogo prodotti online. Per aiutarvi con questi task, cosa usate come parole chiave per trovare la vostra strada?

“Come organizzare un sito web?”

“Quali sono le best practices per un catalogo e-commerce?“

“Come scegliere le categorie per i cataloghi prodotti?“

È come cercare su Google i sintomi di una malattia di cui soffrite: è una strada lunga, difficile e frustrante da percorrere. Senza conoscere le parole “architettura dell’informazione“ è molto probabile che troverete solo i modi in cui altri hanno già risolto specifici problemi.

Non fraintendetemi, questo primo step va bene, ma senza capire le basi concettuali dell’IA, è più probabile che si finisca con il propagare dei pattern che si vedono sulle parti del web di cui si fa esperienza. Questo trend fa sì che troppa parte del web appaia e funzioni alla stessa maniera, come se tutti lavorassero da un unico piano e l’intero mondo stia lentamente diventando una grande sotto-divisione di periferia.

Nel 2013, mi stavo preparando per intervistare Lou Rosenfeld sul palco del World Information Architecture Day a New York City. Mentre facevo i compiti per l’intervista, ho avuto l’opportunità di parlare con Peter Morville sulla crescita dell’IA come un field of practice. Mi disse che prima che il termine “architettura dell’informazione” diventasse popolare, le persone facevano riferimento a qualcosa chiamato “the pain with no name”.

Gli utenti non riuscivano a trovare cose. I siti non potevano fare spazio a nuovo contenuto. Non era un problema tecnologico, non era un problema di graphic design: era un problema di architettura dell’informazione.

Peter Morville, A Brief History of Information Architecture

La formulazione “the pain with no name” è potente perché cattura in maniera appropriata l’ansia che comporta il prendere decisioni strutturali e linguistiche. È un lavoro incasinato, doloroso, da mal di testa, che richiede dedizione alla chiarezza e alla coerenza.

Questi problemi non sono morti con la nascita del web 2.0. Ogni singola persona che lavora oggi sul web ha avuto a che fare con una situazione in cui si è presentato il “pain with no name”, lasciando sul suo cammino disinformazione e mal informazione. Per esempio:

“Il nostro team marketing ha un linguaggio diverso dal team tecnologico.”

“I nostri utenti non comprendono il linguaggio del nostro business.”

“Il modo in cui questo è etichettato o classificato è di far sì che gli utenti non lo trovino o non lo capiscano.”

“Abbiamo diverse etichette per la stessa cosa e ce le troviamo tra i piedi quando discutiamo sulle cose.”

Questi problemi persistono in ogni progetto: disaccordi sul linguaggio e sulla struttura spesso rimangono irrisolti a causa della mancanza di una chiara ownership. Dal momento che appartengono e sono influenzati da tutto dalla business strategy allo sviluppo tecnico, è difficile inserire queste conversazioni in un diagramma di Gantt o in un project plan. Le discussioni di IA sembrano saltar fuori nel corso di un progetto come nel gioco della talpa.

Quando ho lavorato in un team di un’agenzia, era piuttosto comune che i copywriters volessero la responsabilità di trovare le etichette finali per ogni sistema di navigazione che proponevo. Vedevano correttamente queste etichette come importanti asset del brand, ma era anche piuttosto comune che cercassimo di imparare attraverso i test e i report statistici che questi “branded labels” non avevano il comportamento atteso dagli utenti. Riunione dopo riunione, facevamo fatica e litigavamo sul fatto che i label che proponevo, sebbene più centrati dei loro, fossero sterili, noiosi o non “on brand”. A volte vincevo queste discussioni, ma solitamente ero sopraffatta dalla preferenza del team creativo per etichette concise, carine, metaforiche o irriverenti che “si abbinavano meglio al brand”.

Nel caso peggiore, la label che avevo proposto aveva senso per 9 utenti su 10 in un test di usabilità dei wireframes. Lo stesso contenuto è stato testato di nuovo dopo lo sviluppo, ma adesso era nascosto dietro a una label carina e in linea con il brand che aveva senso per 0 utenti su 10. In fin dei conti, il cliente è stato convinto dal team creativo che il test di laboratorio mostrava dei bias in questa direzione. Una volta che abbiamo avuto le statistiche di un paio di mesi del sito live, abbiamo visto che in realtà il problema era vero. È stata la prima volta che ho visto lo 0% degli utenti cliccare su una voce della navigazione.

Sette anni più tardi, quella label è ancora sul sito e ancora adesso nessun utente ci ha cliccato. Il cliente non è stato in grado di dare una priorità al budget perché la si sistemasse dal momento che dovevano pagare per del lavoro basato su delle campagne (molto del quale è ironicamente nascosto dietro quella label carina ma che confonde). Questa è stata la prima volta che ho capito completamente quanta parte del mio lavoro consista nell’insegnare agli altri a prendere in considerazione l’IA e non solo ad ascoltare le mie raccomandazioni in merito.

Temo che ci siamo persi in una guerra di suddivisione delle responsabilità. La chiarezza è la vittima di queste battaglie. Non importa chi se ne esce con la label o chi decide come si deve sistemare qualcosa. Quello che importa è che qualcuno ci pensi e decida il modo di procedere che difenda chiarezza ed intenzione.

Il web è troppo nuovo – diamine, il software design è troppo nuovo — perché possiamo dire che c’è una risposta chiara e semplice quando progettiamo. Ogni volta che facciamo qualcosa, ci stiamo lanciando da un aeroplano e tutta la ricerca del mondo è solo l’attento impacchettamento del nostro paracadute. Avvertiremo ancora l’atterraggio.

Christina Wodkte, Fear of Design (2002)

C’è più informazione che mai che gira vorticosamente per il mondo. Ci sono più canali attraverso i quali diffondere il contenuto. Non c’è mai stato un bisogno pressante per il pensiero critico sulla struttura per assicurare che le cose abbiano senso. Tuttavia, credo che il “pain with no name” stia sperimentando un secondo ritorno.

In troppi casi, i programmi di istruzione in design e tecnologia hanno smesso di insegnare o addirittura parlare di IA. I professionisti nell’industria del web hanno smesso di insegnare ai propri clienti la sua importanza. Alcune ragioni per cui si fa così includono “la navigazione è morta”, “il web è bottom up non top down” e “la ricerca ha detronizzato la struttura”, ma tutte quest inquadrano la IA com un pattern o un moda passeggera che è uscita con i controlli ad albero usati come navigazione.

Questi pregiudizi devono essere gestiti se vogliamo poter controllare la realtà di un imminente “tsunami dell’informazione” che si sta avvicinando alle nostre spiagge. Il bisogno di chiarezza non sarà mai fuori moda né lo sarà l’importanza del linguaggio e della struttura. Avremo sempre bisogno di avere discussioni semantiche e strutturali per portare a termine del lavoro fatto bene.

Ho lavorato con troppi business che hanno ereditato le “lacksonomies” che sono emerse dal senso che c’è solo un modo per organizzare un sito di e-commerce, una mobile app o un sito di marketing. Dimentichiamo che la maggior parte delle interfacce là fuori è composta più da esperimenti che da pattern provati. In altre parole, siate cauti quando copiate dagli altri.

Molte persone credono che un grande brand o uno popolare abbiano “probabilmente” testato le proprie decisioni architetturali, quando in realtà spesso non è così. La verità è che non sappiamo mai se stiamo guardando qualcosa che rientra in un test A/B o che è stato riprogettato dietro le quinte perché non funziona come dovrebbe.

Come possiamo essere sicuri che i pattern che stiamo copiando siano ben fondati?

La verità è che non possiamo. Qualcosa che funziona per Amazon potrebbe non funzionare per il nostro business. Qualcosa che Google ha fatto potrebbe essere una decisione terribile applicata al nostro contesto. Una volta avevo un cliente che voleva i suoi prodotti strutturati come iTunes, perché Apple è davvero grandiosa con il design.

Cambiare requisiti significa cambiare IA e questo implica che l’intero processo a valle dovrà essere sistemato.

Keith LaFerriere, Educating the Client on IA

Solo voi potete aiutare il mondo a dare un nome a questo problema.

Quando si sta discutendo di una decisione strutturale o linguistica, chiamatela architettura dell’informazione. Date alla gente l’etichetta che sta cercando per descrivere il dolore e l’ansia che prova. Se c’è una discussione semantica da fare, fatela e assicuratevi che quelli con cui state discutendo conoscano l’impatto di lasciare queste cose irrisolte.

Insegnate agli altri le ramificazioni del decision-making della IA. Avvertite i vostri colleghi e clienti che l’IA non è una fase o un processo che si può impostare una volta per poi dimenticarsene. È una discussione continua che può avere un impatto in ogni fase del lavoro.

Condividete le vostre difficoltà di IA con colleghi e pari così che la nostra community possa crescere con le esperienze collettive. Se volete un luogo dove condividere ed imparare di più sulla conversazione globale che avviene attorno all’architettura dell’informazione, cercate una location del World IA Day vicino a voi.