it-swarm-eu.dev

Come decidere tra "interfaccia utente coerente" e "interfaccia utente adeguata"?

Attualmente sto lottando con il design della nuova interfaccia utente per un'applicazione piuttosto grande. L'attuale versione del software è composta da ~ 150 moduli e non sono né belli né intuitivi, da cui la riprogettazione.

Nel nuovo design, voglio mantenere le cose coerenti, cioè voglio che quelle forme appaiano e si sentano il più simili possibile. Ma in alcuni casi, non sembra giusto. Ad esempio, il layout che ha senso per la gestione di una tabella di dati master con molti campi e diverse tabelle di dettaglio sembra totalmente gonfio per una tabella più piccola senza tabelle di dettagli. D'altra parte, l'approccio di progettazione semplice più diretto per il tavolino è IMO troppo incompatibile con il layout della parte che gestisce il tavolo più grande.

Come attaccare il problema? Attenersi a un layout? Mitigare la richiesta di coerenza? Cerchi un approccio migliore per tutti?

5
ammoQ

Mi vengono in mente un paio di pensieri:

  • Non mi preoccuperei troppo della coerenza con i moduli legacy, soprattutto se stai implementando i nuovi moduli in un breve periodo di tempo. Presto quelle vecchie forme diventeranno un debole ricordo, né un aiuto né un ostacolo per le prestazioni del nuovo design.

  • Non è poi così male se forme diverse sembrano diverse se quelle differenze di aspetto sono legate a differenze di funzione. Potrebbe esserci un piccolo onere di apprendimento, ma è improbabile che gli utenti siano confusi perché le differenze visive indicano che ci sono differenze funzionali. L'incoerenza è più problematica quando le cose sembrano uguali ma si comportano diversamente, una condizione che chiamo una "contraddizione".

  • D'altra parte, potresti voler considerare di includere alcune delle stesse funzionalità di base in tutte le forme, non per coerenza, ma per flessibilità. Ad esempio, la tua ricerca utente potrebbe indicare che solo 20 dei tuoi moduli hanno bisogno di una funzione Clone per le normali operazioni, ma potresti voler includere comunque un'abilità Clone su tutti i moduli per coprire operazioni eccezionali che la tua ricerca non ha scoperto.

  • Dovresti anche evitare cose che sembrano diverse ma fanno la stessa cosa (ad esempio, se Elimina è un pulsante con l'etichetta di testo su un modulo mentre è un'icona su un altro modulo). Questa è una condizione che io chiamo "irregolarità", che non è così grave come una contraddizione, ma comunque cattiva. È necessario un convincente guadagno di usabilità in altre aree (ad es. Efficienza) per giustificare un'irregolarità.

Hai ragione nel dire che la coerenza non è tutto e dovresti valutare i suoi vantaggi rispetto ad altre considerazioni come l'efficienza di ciascun modulo. Ho dettagli per stimare e mitigare la gravità delle incoerenze per fare tali compromessi su Raggiungere e bilanciare la coerenza nella progettazione dell'interfaccia utente . Discuto la flessibilità in E xpecting the Unexpected .

11
Michael Zuschlag

Comportamento coerente, aspetto adeguato

IMO è necessario chiarire (per noi, o forse per te stesso) cosa deve essere coerente e cosa no.

Comportamento coerente significa: le cose che sembrano uguali dovrebbero comportarsi allo stesso modo.
Aspetto adeguato significa: l'aspetto aiuta l'utente a prevedere la funzionalità.

Con queste definizioni ad hoc di Humble Me, non sono antagonisti.

Ho visto molti tentativi di aspetto coerente per cose funzionalmente diverse. Ora, con un po 'di età, ritengo che un errore in molti casi - almeno quando l'aspetto simile fosse motivato da un'implementazione simile o condivisa.

IMHO, cercare un aspetto simile tra 150 forme (OMG!) Non è nemmeno un buon obiettivo. In che modo i tuoi utenti possono dire cosa stanno facendo?

Esempio:

alt text

Riesci a individuare la differenza? Molto coerente, ma una ricetta per il disastro.

In questo esempio, i dettagli come la selezione del destinatario, la selezione di prodotti e importi ecc. Dovrebbero comportarsi allo stesso modo: questa è coerenza. Aspetto, OTOH dovrebbe essere significativamente diverso.


In pratica, vedo due possibili problemi:

Preferenze sviluppatore: l'approccio "taglia unica" si riduce più facilmente con gli sviluppatori. Invece di implementare 150 moduli, implementano un motore di generazione di moduli che si configura principalmente da metadati del database. (Ci piace solo risolvere i meta-problemi e odiamo il lavoro ripetitivo. Anche questo è l'approccio più efficiente se il risultato è ciò di cui l'utente ha bisogno.)

Percezione dell'utente: la sostituzione di una UX esistente è diversa dall'introduzione di una nuova UX. Per gli utenti non tecnici, i moduli sono l'applicazione - non conoscono la logica aziendale e i backend, conoscono solo elenchi, campi e pulsanti.
Ciò significa che se si modifica completamente l'interfaccia utente, è possibile che si verifichino molti attriti quando viene implementata la soluzione, semplicemente perché gli utenti vedono un'applicazione sconosciuta, mentre l'IT pensa che siano gli stessi dati, quindi solo una piccola formazione è necessario.
Il che mi porta alla parte della mia risposta che detesto dire: fai attenzione a ciò che butti. Un'interfaccia utente efficiente ed elegante può essere molto più soggetta a errori di una brutta ma familiare.

[modifica] Come sottolinea Michael Zuschlag, non preoccuparti di prepararti al lancio.

5
peterchen

Mantiene coerente il flusso di gruppi di elementi .

Oltre agli elementi visibili, un'altra cosa da rendere coerenti è il flusso di dati e l'ordine delle schede quando un utente sta attivamente aggiungendo informazioni al modulo. Una regola da seguire sarebbe quella di seguire coerentemente lo stesso ordine di flusso per gruppi di dati come indirizzo (composto da cose come via, città, codice postale, paese, ecc.), Nome (saluto, primo, medio, ultimo) o prodotto voce (nome, breve descrizione, descrizione lunga, colore, peso, numero di disegni inclusi, ecc.).

Ad esempio: un blocco di indirizzi conterrà normalmente gli stessi campi: via, città, codice postale, paese. Ha senso mettere sempre gli stessi elementi nello stesso ordine relativo (non via, città, paese, codice postale in una forma e via, città, codice postale, paese in un'altra). E sebbene alcuni moduli di indirizzo possano differire leggermente (campo numero apt su questo, nessun campo paese su quello), la creazione di un flusso coerente semplifica notevolmente l'errore nell'inserimento dei dati.

Gli utenti esperti, in particolare quelli che toccano il tipo, inizieranno a utilizzare il pulsante tab per migliorare rapidamente la loro efficienza. Le principali interruzioni del flusso di schede o costringendo l'utente a spostare il mouse e facendo clic manualmente (sussulto!) Per cambiare lo stato attivo guideranno gli utenti frequenti del sistema.

Inoltre, potresti non implementarli per il Web, ma l'idea di base è ancora valida: Raggruppamento di elementi del modulo oppure Impostazione esplicita delle schede ha il vantaggio di essere più accessibile.

1
Peach

cosa ne pensi cosa pensano gli utenti delle tue modifiche? Hai svolto indagini sui problemi di alcuni utenti? Penso che tu abbia almeno due opere parallele:

  • riprogettazione dell'interfaccia utente a uno stile (creare un prototipo, che utilizza controlli generali per tutti i moduli)
  • usabilità, risoluzione dei problemi di coerenza (fare analisi più dettagliate per ogni gruppo di utenti)

Fortuna.

0
igor