I punti di ingresso multipli sono buoni o cattivi?
Il mio esempio è un'applicazione basata sul web, ma immagino che questo potrebbe andare per qualsiasi cosa: punti di ingresso multipli per la stessa azione, buoni o cattivi?
Il mio esempio:
Aggiunta di un prodotto a un fornitore (fornitore).
Questo potrebbe potenzialmente essere fatto tramite:
- Prodotto -> Fai clic su "Aggiungi prodotto fornitore" (quindi seleziona il fornitore)
- Fornitore -> Fai clic su "Aggiungi prodotto" (quindi seleziona il fornitore)
- Fornitore -> Seleziona il fornitore dall'elenco dei fornitori -> Fai clic su "Visualizza prodotti fornitori" -> Fai clic su "Aggiungi prodotto"
Tutti i punti di ingresso validi, se ne utilizziamo solo uno, hanno ciascuno vantaggi e svantaggi che migliorano l'esperienza o confondono l'utente. C'è qualcosa di sbagliato/confuso nell'avere più punti di accesso alla stessa azione?
Come principio generale di usabilità, si desidera offrire apertura e flessibilità, consentendo agli utenti di fare ciò che vogliono ogni volta che lo desiderano. Ciò sostiene di fornire più punti di ingresso anziché forzare gli utenti a seguire solo un singolo percorso che potrebbero non conoscere o che potrebbero aver dimenticato o che potrebbero non essere coerenti con il loro modo di pensare.
La preoccupazione è che percorsi multipli possano significare menu e architetture informative più complessi che aggiungono disordine, perdono gli utenti e possono potenzialmente creare confusione. Ci sono alcune variabili che possono mitigare questo.
Strutture centrate sull'oggetto
In primo luogo, man mano che le app diventano più complesse, con più attività e percorsi possibili, puoi controllare sia la complessità del menu che dell'architettura adottando una struttura centrata sull'oggetto , piuttosto che una struttura centrata sulle attività simile a una procedura guidata tipica di app web. In una struttura centrata sugli oggetti, ogni pagina rappresenta una o più classi di oggetti per le quali è possibile eseguire tutte le attività che coinvolgono tali classi. In una struttura centrata sulle attività ogni pagina rappresenta una singola attività o un singolo passaggio in un'attività.
Con una struttura centrata sull'oggetto, potresti avere una pagina Prodotti che elenca tutti i prodotti, con il fornitore per ognuno indicato in un campo (su cui l'utente può ordinare). In alternativa, è disponibile una pagina Fornitori in cui sono elencati tutti i fornitori, che include i prodotti per un determinato fornitore in una struttura ad albero o con un dettaglio principale. In entrambi i casi, tutte le informazioni si trovano su una pagina, rendendo il menu e l'architettura più semplici ed eliminando o almeno riducendo la necessità di più punti di accesso.
Duplicazione tra le pagine (rispetto alle pagine)
In secondo luogo, avere comandi duplicati su due pagine diverse non è così problematico come avere comandi duplicati in due posti diversi nella stessa pagina. Con quest'ultimo, gli utenti si chiederanno se i due comandi siano davvero uguali o meno. Al contrario, gli utenti si aspettano spesso che gli stessi comandi vengano visualizzati su pagine diverse (ad es. Nel menu della barra laterale).
A seconda delle attività che è necessario supportare, potrebbe essere necessario disporre di una pagina Prodotti e Fornitori anche se si dispone di una struttura centrata sugli oggetti. Tuttavia, avere una voce di menu Aggiungi prodotto su Prodotti e Fornitori pagine probabilmente va bene. Avere una voce di menu Aggiungi prodotto in Prodotto e fornitore menu probabilmente non lo è.
Etichette e regole coerenti
In terzo luogo, più punti di ingresso comportano la minore complessità se utilizzano le stesse etichette e seguono le stesse regole di base di interazione. Per le strutture centrate sugli oggetti e la maggior parte delle GUI desktop, la regola di base è che se l'utente può vederlo, l'utente può interagire con esso. Se gli utenti visualizzano i prodotti sia nella pagina Prodotti che di fornitori, si aspettano di essere in grado di interagire con essi, anche aggiungendoli. Ciò è analogo alla fornitura di collegamenti al contenuto ogni volta che viene citato in un sito Web.
Etichette coerenti aiuteranno a segnalare agli utenti che è lo stesso comando in un posto diverso, quindi assicurati di chiamarlo costantemente "Aggiungi prodotto", non "Aggiungi prodotto" in un posto e "Inserisci prodotto" in un altro.
Regole semplici e coerenti possono anche semplificare i menu. Se l'app supporta il focus dell'oggetto (necessario per le relazioni master-dettaglio), allora hai solo bisogno di una voce di menu Aggiungi. Se il focus è sui prodotti (su entrambe le pagine), aggiunge un prodotto. Se l'attenzione è rivolta ai fornitori, si aggiunge un fornitore.
In termini di architettura delle informazioni, la navigazione sfaccettata è un approccio legittimo per ottenere un utente per l'attività o la pagina che desidera.
Stai ottimizzando la struttura del sito per adattarla al modello mentale dell'utente.
- Assicurarsi che l'invito all'azione sia chiaro.
- Garantire una convenzione di denominazione coerente per l'invito ad azioni. Questo è importante per garantire la minimizzazione della frustrazione e migliorare l'accessibilità. Cioè Se hai "Aggiungi prodotto" assicurati che tutte le azioni "Aggiungi prodotto" vadano sulla stessa pagina.
Un'altra nota rapida, se si raccolgono informazioni dall'ambiente (come il nome del fornitore) da un punto di ingresso diverso, utilizzare tali informazioni per precompilare il modulo.
HTH
Opaco
In genere, più punti di ingresso possono creare confusione tra gli utenti. Se vedono più modi che possono potenzialmente portarli alla stessa azione, potrebbero non essere chiari sulle differenze che potrebbero esserci tra le due azioni.
Detto questo, tuttavia, la risposta è davvero che dipende. Ogni situazione ha le sue piccole stranezze che devi affrontare. Se hai due basi utenti distinte, con due flussi di business diversi, ha perfettamente senso avere due modi diversi per raggiungere lo stesso posto.
lascerei solo i primi due, sembrano logici in una relazione di prodotto <-> fornitore, il terzo sembra complicato e in qualche modo ridondante al secondo.
- successivamente puoi testare e vedere quale di queste persone usa (sarà solo una) e rimuovere l'altra.
Fornisco sempre diversi modi per raggiungere un obiettivo. Tuttavia, ho una struttura ad esso. Non dovresti confondere l'utente su cosa sia la cosa o usare una terminologia diversa.
Ecco cosa accadrà.
- Gli utenti indovineranno come fare qualcosa
- Se si forniscono più voci, indovineranno una di quelle e avranno ragione. VINCERE. Continueranno quindi a farlo in questo modo.
- In alternativa, se forniscono un modo di fare le cose, indovineranno male, si sentiranno frustrati, confonderanno, confonderanno, confonderanno, alla fine capiranno e continueranno a farlo in quel modo. PERDERE.
Nella mia esperienza, questo è un sì definitivo e al 100%. Non confonde l'utente se si mantiene la coerenza della lingua.
argomento interessante
è stato comune che alcune destinazioni siano raggiungibili tramite> 1 percorsi. Un esempio: un utente deve trovare informazioni su un'attività (ad esempio golf) in un luogo (ad esempio perth).
In questo esempio l'utente può arrivare qui sia:
1) navigazione verso una posizione, quindi selezionando un'attività 2) navigazione verso un'attività, quindi selezionando una posizione
Entrambi gli scenari sono ugualmente probabili, quindi non è possibile non progettare l'architettura delle informazioni attorno ad essa. Il problema con questo tipo di comportamento dell'utente è che i percorsi bredcrumb cadono a pezzi e non funzioneranno se non aggiungi un'altra dimensione ... ma questa è un'altra storia ...