Navigazione aziendale: metodologie di progettazione per la collaborazione con gli stakeholder

Progettare (o riprogettare) un sistema di navigazione aziendale non è un compito preso alla leggera. Le applicazioni aziendali servono un gran numero di utenti, ospitano un'ampia gamma di persone e contengono un volume significativo di contenuti e funzionalità. Alcune applicazioni aziendali hanno anche più prodotti desktop e mobili basati sul Web che devono integrarsi perfettamente per un'esperienza utente più piacevole.

Sebbene questo possa sembrare un compito scoraggiante o addirittura impossibile gestito al meglio da un grande team di "esperti", un architetto dell'informazione o un designer dell'esperienza utente solista può affrontare da solo una revisione del design dell'esperienza utente di un'applicazione aziendale, purché segua una metodologia efficace per la collaborazione delle parti interessate.

"Quando mangi un elefante, prendi un morso alla volta." - Creighton Williams Abrams Jr.

Informazioni sui sistemi di progettazione della navigazione aziendale

Le principali differenze tra le applicazioni aziendali ei più piccoli sistemi basati sul Web sono l'enorme volume di contenuti e la varietà di funzionalità. Laddove i sistemi più piccoli possono effettivamente fare affidamento su un sistema di navigazione relativamente piatto (vale a dire, meno clic per accedere a tutto il contenuto), l'architettura delle applicazioni aziendali spesso richiede menu a più livelli e meccanismi di orientamento accuratamente posizionati. Più complesso è il sistema di navigazione, più importante è che il sistema stesso sia facile da usare, ben organizzato e in linea con il modello mentale dell'utente.

L'obiettivo finale può essere chiaro, ma se esistesse un design "perfetto" per un sistema di navigazione aziendale, ogni impresa lo avrebbe adottato. Senza un sistema perfezionato, c'è molto spazio per il miglioramento, la creatività e l'innovazione. Rivela anche il fatto che ogni azienda è diversa, con casi d'uso e requisiti diversi per la navigazione attraverso un'applicazione complessa.

La navigazione è semplicemente "Wayfinding"

Fondamentalmente, la navigazione è "orientamento". Le navi marittime possono navigare in un vasto oceano aperto usando le stelle; i viaggiatori di terra possono trovare la loro destinazione con l'aiuto di punti di riferimento; e gli utenti delle applicazioni aziendali raggiungono i loro obiettivi finali facendo affidamento su vari indicatori digitali.

Ad esempio, nell'universo digitale, la navigazione dipende dalla selezione e dal posizionamento di parole chiave, etichette, colore, iconografia, oggetti di invito all'azione e altri indicatori sullo schermo. Quando il contenuto è mal organizzato, le funzionalità sono etichettate in modo non intuitivo, le parole chiave sono selezionate a caso o le icone sono ottuse o non convenzionali, gli utenti potrebbero sentirsi frustrati o persi... e potrebbero semplicemente andarsene.

Metodologia per la collaborazione nella progettazione della navigazione

Gli ambienti aziendali sono intrinsecamente complessi e richiedono una grande quantità di organizzazione per funzionare in modo efficace. Nessuna singola persona può conoscere o comprendere intuitivamente l'intero ambito di un'applicazione aziendale o le aspettative uniche e variegate della sua base di utenti. Ci sono molte opinioni su quali risultati siano essenziali per una determinata metodologia di progettazione. Indipendentemente da ciò che viene creato alla fine, qualsiasi metodologia dovrebbe iniziare con la collaborazione degli stakeholder.

1. Riunione di avvio delle parti interessate

Qualsiasi progetto su larga scala dovrebbe iniziare con una riunione di avvio delle parti interessate. Fondamentalmente, questo è un grande incontro con tutti gli attori chiave presenti (da remoto o in loco) per avviare il progetto. In genere, una riunione di avvio degli stakeholder ha un unico facilitatore che introduce gli obiettivi del progetto, identifica tutti i ruoli degli stakeholder e rimanda ai lead del progetto (se appropriato) per un contesto aggiuntivo, in modo che la collaborazione possa iniziare.

Più grande è il team, più importante è tenere una riunione ufficiale di avvio delle parti interessate. Proprio come la cerimonia di apertura delle Olimpiadi, questo punto di partenza in qualche modo cerimoniale per un progetto chiarisce a tutte le parti interessate che "i giochi sono iniziati".

In qualità di designer, è meglio ottenere l'elenco delle parti interessate e dei loro ruoli come riferimento quando si pianificano sessioni e interviste di progettazione della navigazione. Tutti in questo elenco sono importanti e preziosi per il lavoro che deve essere svolto.

2. Brainstorming sul cielo blu

Con tutte le parti interessate identificate e coinvolte, trova il tempo per incontrarti in gruppi più piccoli o programmare interviste individuali per condurre sessioni di brainstorming e ideazione. Aprendo la porta per sognare un futuro "cielo blu", le persone hanno meno probabilità di filtrare le proprie idee o opinioni e l'innovazione ha la possibilità di spiegare le ali.

In molti casi, ostacoli storici o limitazioni infondate possono persistere nella mente degli stakeholder ma non esistono più nella realtà (a causa, ad esempio, di nuove tecnologie, cambiamenti nel mercato, cambiamenti nei ricavi generati dall'applicazione aziendale o altri fattori) . Quando le parti interessate condividono le preoccupazioni su queste barriere, prova a chiedere "perché" prima di accettarle così come sono. Potrebbero esserci opportunità nascoste qui.

Per avviare questo processo di brainstorming, inizia con alcune domande:

1. Se dovessi fare un salto in avanti di 5 o 10 anni nel futuro senza limitazioni o blocchi stradali, cosa vorresti vedere nel design futuro?
2. Hai avuto qualche idea, indipendentemente da quanto sia facile o complicata, ma non hai l'opportunità di realizzarle?
3. Se tu fossi l'amministratore delegato di questa azienda, cosa faresti in questa situazione?
4. Vedi qualche esigenza nel mercato che potrebbe essere soddisfatta da questa applicazione?

Può sembrare che questo approccio possa aprire un "barattolo di vermi", ma finché tutti sono chiari sullo scenario del "cielo blu", possono succedere grandi cose. Provaci!

3. Punti dolenti e identificazione del problema

Quando gli utenti provano dolore o frustrazione nel navigare attraverso un sistema aziendale su larga scala per trovare contenuti o funzionalità che dovrebbero essere più facilmente accessibili, è più probabile che quegli utenti si arrendano e (a volte) trovino un'alternativa. Tale alternativa potrebbe essere con un concorrente.

Sii realistico e aggressivo nell'identificare i punti deboli e i problemi degli utenti. Molte parti interessate hanno accesso diretto al feedback degli utenti attraverso sondaggi, sessioni di formazione e altre forme di comunicazione. Sfrutta questa conoscenza per ottenere una migliore comprensione di come l'attuale sistema di navigazione aziendale sta fallendo.

Queste domande possono far girare la palla con l'identificazione di punti dolenti e problemi:

1. Di cosa si lamentano di più gli utenti?
2. Utilizzi servizi (come analisi del traffico web o monitoraggio dei clic) che tengono traccia del comportamento degli utenti nel sistema?
3. Ci sono aree del sistema aziendale che vengono utilizzate raramente e non puoi spiegare perché?
4. Se potessi cambiare qualcosa su questa applicazione, quale sarebbe?

L'analisi dei punti in cui gli utenti hanno problemi giocherà un ruolo importante nell'identificazione delle lacune nel design attuale. Cattura questi punti per l'uso in questa metodologia.

4. Diagramma di affinità

Come designer, le "note adesive" possono essere il tuo migliore amico. Ma se troppe parti interessate non si trovano nello stesso ufficio o tu sei l'unica risorsa remota, le note adesive di carta vengono utilizzate invano. Trovare un approccio efficace per la collaborazione online è fondamentale. Esiste un'ampia varietà di strumenti di collaborazione online che possono essere utilizzati per acquisire tutti gli input dalle fasi Blue Sky Brainstorming e Pain Points e Identificazione dei problemi.

Dopo aver acquisito una quantità significativa di input, il passaggio successivo consiste nell'organizzare tale input in gruppi di affinità. Il diagramma di affinità è un esercizio collaborativo che offre a tutte le parti interessate la possibilità di trovare relazioni o caratteristiche condivise tra idee individuali o tipi di contenuto. Questo esercizio consente a un designer di riunire tutte le idee del "cielo blu" ei "punti deboli e problemi".

Ad esempio, potrebbe essere utile raggruppare i contenuti dei processi e delle procedure in una libreria, o gli eventi di attualità e gli aggiornamenti degni di nota in un quotidiano online consolidato. Incoraggiare le parti interessate a essere creative su come formulare i gruppi di affinità.

Nelle sessioni di diagrammi di affinità con gli stakeholder, poni domande come queste:

1. Quali caratteristiche o contenuti sembrano appartenere insieme?
2. Gli utenti stanno cercando di intraprendere determinate azioni che sarebbero più facili se si verificassero in sequenza?
3. Esistono funzionalità ridondanti che potrebbero essere facilmente unite o semplificate?
4. C'è qualche opportunità per abbinare le idee del cielo blu con punti deboli o problemi esistenti?

Incoraggiare le parti interessate a pensare a scenari specifici che portano gli utenti a una determinata funzionalità all'interno del sistema. L'uso di scenari di vita reale mette le cose in prospettiva e rende più facile per le parti interessate essere empatiche nei confronti dell'esperienza dell'utente.

5. Riorganizzazione logica

Dopo aver completato l'esercizio del diagramma di affinità, è importante fare un passo indietro e guardare il sistema in modo olistico. C'è spesso un ordine logico di operazioni che un utente può seguire all'interno di un dato ambiente complesso. Valutare attentamente se esistono opportunità per fornire un servizio che non è attualmente disponibile (innovazione) o per incoraggiare un utente ad espandere la propria utilità del sistema di navigazione aziendale (scoperta) fornendo indicatori di orientamento.

Per acquisire questa organizzazione logica o ordine delle operazioni, un progettista può creare un diagramma di flusso o, in scenari più complessi, una mappa del percorso dell'utente, a partire dal flusso di lavoro principale, per poi estendersi ad altri contenuti o funzionalità.

Le domande che potrebbero incoraggiare i tuoi stakeholder includono:

1. Ora che l'utente è "qui", cos'altro può fare?
2. Qual è la prossima attività logica per l'utente in questo scenario?
3. Stiamo perdendo qualche opportunità per risolvere il problema dell'utente da questo vantaggio?
4. Ci sono funzionalità o contenuti che esistono altrove che potrebbero essere utili in questo scenario?

Dopo aver avviato la conversazione su questo argomento, collaborare con le parti interessate per riorganizzare i gruppi di affinità di conseguenza.

6. Gerarchia

All'interno di un gruppo di affinità più ampio o tra singoli gruppi di affinità, ci saranno probabilmente relazioni o dipendenze. Collaborare con le parti interessate per identificare tali relazioni o dipendenze, quindi organizzarle in gerarchie. Una gerarchia è semplicemente un modo elegante per descrivere come un contenuto o una funzionalità appartenga a un gruppo di contenuti o funzionalità simili. Ad esempio, un singolo articolo di notizie appartiene a un argomento e l'argomento appartiene a una sezione dedicata alle notizie.

Avvertimento!

A questo punto del processo di progettazione, le parti interessate potrebbero voler utilizzare l'organizzazione dipartimentale aziendale esistente come linea di base per la gerarchia del sistema aziendale. Sebbene sia facile imitare l'organizzazione dipartimentale aziendale (che è in genere dove si trova la proprietà dei contenuti e delle funzionalità), questo può essere un grosso errore!

Agli utenti non interessa chi possiede il contenuto. Inoltre, poiché alle grandi imprese piace riorganizzarsi frequentemente, il sistema di progettazione della navigazione aziendale che si allinea con l'organizzazione dipartimentale non sarà più valido non appena si verifica la prima "riorganizzazione".

Sfrutta la metodologia presentata finora e respingi questo approccio pericoloso. Queste domande possono aiutare a facilitare una conversazione con le parti interessate:

1. In che modo questi gruppi di affinità sono correlati e perché sono correlati?
2. Ci sono delle dipendenze tra i gruppi di affinità che dobbiamo riconoscere?
3. Gli utenti saranno in grado di completare un'attività senza dover passare a un'altra area del sistema?
4. Esistono gerarchie convenzionali familiari agli utenti di altri settori o modelli di servizio che possono essere utilizzati come riferimento?

A questo punto del processo di progettazione, ci sono molti modi per verificare se l'approccio sta funzionando. Considera diversi metodi di test utente e ricerca utente per confermare la tua gerarchia o per identificare aree problematiche che richiedono maggiore attenzione.

7. Nomenclatura e parametri

Con un modello completo della futura architettura delle applicazioni aziendali, nota anche come architettura dell'informazione, è ora di selezionare le parole chiave (nomenclatura) e impostare i parametri (definizioni).

La nomenclatura, o etichettatura, è un elemento importante della progettazione della navigazione per tre ragioni principali: (a) la nomenclatura è direttamente correlata alla SEO (ottimizzazione dei motori di ricerca) in quanto i motori di ricerca cercano principalmente i contenuti per parole chiave; (b) l'uso della terminologia appropriata come meccanismo di orientamento aiuterà gli utenti a trovare ciò che cercano fungendo da "punto di riferimento" digitale; e (c) le etichette intelligenti possono portare gli utenti a un'area del sistema che potrebbe non essere facilmente accessibile da una pagina di destinazione principale o da una home page. La reperibilità è guidata da meccanismi di orientamento, come le etichette. Se un'etichetta è fuorviante o non intuitiva, l'utente potrebbe non preoccuparsi di fare clic su di essa.

Con tutta la nomenclatura (etichette) identificata nel modello di architettura dell'informazione, collaborare con le parti interessate per definire i parametri (definizioni) per ciascuna area etichettata nel modello. Ciò garantirà che il contenuto e le funzionalità appartengano a un'area particolare. Inoltre, questo esercizio crea linee guida a lungo termine per costruire l'architettura dell'applicazione aziendale che sopravviverà all'attuale processo di progettazione.

Per quanto riguarda la nomenclatura e i parametri, ecco alcune domande da porre alle parti interessate che guideranno la conversazione:

1. Cosa cercano gli utenti più spesso quando visitano?
2. Ci sono contenuti o funzionalità difficili da trovare? Perché sono difficili da trovare?
3. Ci sono termini o gergo del settore che potrebbero non essere familiari ad alcuni utenti, rendendo più difficile per loro trovare ciò che stanno cercando?
4. Come possiamo scegliere etichette convenzionali o mainstream?

Come accennato in precedenza, esistono molti metodi diversi che possono essere utilizzati per testare la nomenclatura, come l'ordinamento delle carte, il test A/B e l'UX orientato agli oggetti (OOUX). Quando si ha a che fare con un sistema aziendale altamente tecnico con tonnellate di gergo industriale, prendere in considerazione la creazione di un vocabolario controllato o di un glossario interno al sistema come riferimento per l'utente.

8. Integrazione con il processo di progettazione dell'esperienza utente

Con un quadro completo della futura architettura dell'informazione, è giunto il momento di applicare i risultati di questa metodologia al processo di progettazione dell'esperienza utente complessiva.

Sebbene possano esserci aree del sistema di navigazione aziendale appena coniato che non esistono quando il progetto di design è in corso, tali aree possono essere "disabilitate" o nascoste fino a quando il contenuto o le funzionalità non sono pronti per essere rilasciati. Quindi, dopo che il progettista è andato avanti, le parti interessate possono continuare a costruire il sistema verso i loro sogni di "cielo blu".

"Se lo costruisci, [loro] verranno". - Campo dei sogni, 1989.

La linea di fondo

La progettazione di un sistema di navigazione aziendale non è un compito facile. Tuttavia, sfruttare la conoscenza delle parti interessate renderà questo sforzo gestibile.

Mettendo da parte la complessità dei progetti di design su larga scala, l'obiettivo è sempre quello di tenere a mente l'utente. Con un approccio pratico alla ricerca degli utenti e ponendo domande intelligenti alle persone che hanno un contatto diretto con l'utente, anche un designer remoto, da solo o freelance può gestire grandi problemi di progettazione. Non lasciarti intimidire: fai le cose un passo alla volta.