Quali principi di progettazione dell'interfaccia utente come la "separazione degli interessi" posso utilizzare per convincere gli sviluppatori che è necessario correggere l'interfaccia utente?[Chiuso]

Question

Chiuso.Questa domanda deve essere più approfondita focalizzata.Al momento non accetta risposte.

---

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un solo problema modificando questo post.

Chiuso 5 anni fa.

Recentemente ho avuto una grande discussione con il team relativa alla progettazione dell'interfaccia utente per il nostro recente progetto software.

Dobbiamo integrare uno speciale sistema di controllo della versione nel nostro prodotto esistente, che è uno strumento di test del software per eseguire test scrivendo e riproducendo script di test.

Il team di progettazione ha realizzato un progetto sul quale non sono d'accordo e lo ritengo contrario alle regole di progettazione di base.

Il problema più grande del design, dal mio punto di vista, è che aggiungono cose speciali per il controllo della versione (come creare una vista, eseguire il check-in/out dello script) nella nostra interfaccia utente esistente (in realtà copiano l'interfaccia utente esistente　e modificatela con un'altra e aggiungono qualcosa su ).Ad esempio, nella nostra finestra di dialogo Apri progetto, copia l'interfaccia utente, quindi aggiungi due pulsanti per attivare una funzione speciale di controllo della versione (come prima dell'apertura dello script.deve avere una vista di controllo della versione che contenga il codice sorgente del progetto).

Ho discusso molto con il team di progettazione sul fatto che mettere insieme cose diverse è una cattiva idea, nel nostro esempio, la funzionalità dello strumento di test del software e la funzionalità dello script di controllo della versione.E ho　spiegato che così facendo verrà fuori un'interfaccia utente duplicata, e ci saranno più situazioni da risolvere, oltre al grosso problema di manutenzione.E preferisco separare i due dall'interfaccia utente, un'interfaccia utente (una finestra di dialogo o una procedura guidata) dovrebbe concentrarsi solo su una delle due cose diverse.

Ho riassunto come principio di progettazione dell'interfaccia utente che "un'interfaccia utente non dovrebbe contenere due cose totalmente diverse".Anche se sostengono questo, vogliono pagare tale sforzo e tutti gli sforzi collaterali (come più interfaccia utente, più situazioni da risolvere per l'interfaccia utente, più sforzi di sviluppo/test/manutenzione rispetto a una progettazione dell'interfaccia utente che separa le due cose diverse), per l'utente per ottenere un software facile da usare e con una buona usabilità.Naturalmente, non sono assolutamente d'accordo con tale affermazione, come può un software non buono sotto ogni altro aspetto essere buono per l'utente?E non c'è nulla da misurare poiché il team di progettazione non ha ancora il progetto completo.

E alla fine non riesco a convincere la squadra.Tutto sembra ancora oggettivo.

Questo mi ha portato a pensare, esiste qualche buona guida/best practice/principio/migliore pratica/principio di progettazione dell'interfaccia utente che copra la nostra situazione (per separare le diverse preoccupazioni, nel dettaglio le esigenze di debug/esecuzione dello script e la necessità di script di controllo della versione, non mettendoli insieme in un'interfaccia utente, una finestra di dialogo o una procedura guidata speciale, ecc.)

Apprezzerei qualsiasi commento e suggerimento relativo all'intero problema, non speciale alla domanda di cui sopra.inoltre risponderò a tutto ciò che non ho espresso bene qui.

Per favore, non chiuderlo :) questo è davvero un GRANDE problema per me come responsabile degli sviluppatori.

Answer 1

Sono d'accordo con @JanNeilson sul fatto che i principi di progettazione non ti aiuteranno a convincere gli sviluppatori a modificare il design dell'interfaccia utente.

Ciò che funziona è test di usabilità. Guardare alcuni utenti rimanere bloccati nel tentativo di utilizzare il software farà dimenare gli sviluppatori e vorrà correggere l'interfaccia utente.D'altra parte, se vedete che gli utenti reali possono utilizzare bene il nuovo software, allora non ci sono problemi e i principi di progettazione non contano.

Il test di usabilità può essere un processo formale in cui porti i clienti in un laboratorio, chiedi loro di eseguire attività specifiche con il tuo software e registri video dell'utente e dello schermo.

Importante: Assicurati di dire agli utenti di prova che non li stai testando;che stai chiedendo loro di aiutarti a testare il software.Spiega che non ti offenderai se a loro non piacerà il software.Vuoi reazioni oneste.Chiedi loro periodicamente di dire cosa pensano, ad es.a "pensare ad alta voce" mentre capiscono cosa fare.Non rispondere alle loro domande pratiche a meno che non si blocchino completamente.

Il test di usabilità può anche essere un processo informale in cui chiedi ad alcuni colleghi casuali di provarlo.L'ho fatto nella mensa, mostrando ad alcuni colleghi una nuova interfaccia utente e chiedendo cosa pensano che significhino (rappresentino) alcune nuove icone.

Prendi appunti durante o subito dopo ogni test.Puoi chiedere agli sviluppatori di guardare il video registrato in seguito (modificare le parti in attesa in modo che gli sviluppatori possano guardarlo tutto) o guardare il video da un'altra stanza durante il test.Oppure, senza il video, puoi portare uno sviluppatore alla volta nella stanza per guardarlo, ma chiedigli di stare con le mani in mano.Lo sviluppatore non deve rispondere alle domande dell'utente senza prima dire "Mi dispiace di aver creato un'interfaccia utente così scadente".

Se il tuo software non è pronto per questo test, puoi eseguire test di usabilità con un modello cartaceo.

Esiste un intero campo dedicato ai test di usabilità.Ci sono esperti ben addestrati.Puoi coinvolgere consulenti esperti per farlo o informarti e provarlo tu stesso.

Una ricerca sul web rivela molti articoli e libri.Ecco un ottimo articolo per cominciare:http://alistapart.com/article/usability-testing-demystified

Il primo paragrafo da Wikipedia sui test di usabilità dice:

Test di usabilità è una tecnica utilizzata nella progettazione di interazione centrata sull'utente per valutare un prodotto testandolo sugli utenti.Questo può essere visto come una pratica di usabilità insostituibile, Poiché fornisce un input diretto su come gli utenti reali utilizzano il sistema.Ciò è in contrasto con i metodi di ispezione dell'usabilità in cui gli esperti utilizzano metodi diversi per valutare un'interfaccia utente senza coinvolgere gli utenti.

Ho aggiunto il corsivo.In altre parole, tu non è possibile ottenere una buona usabilità senza test di usabilità. Al contrario, far valutare un’interfaccia utente da esperti utilizzando principi ed esperienza può aiutare ma non è essenziale.

Answer 2

Tocchi diversi aspetti in questa domanda;Mi concentrerò sulla gestione del UX.

Invece di discutere di generalità come la "separazione degli interessi", esamino problemi specifici con un particolare design dell'interfaccia utente, sia dal punto di vista UX che da nozioni più astratte o generali.Per fare ciò, avrai bisogno di un modello di interfaccia utente.E prima del modello dell'interfaccia utente, avrai bisogno di una serie di descrizioni di base dell'intento dell'interfaccia utente che guiderà i modelli dell'interfaccia utente.Una volta che hai i modelli dell'interfaccia utente, puoi parlare dei casi d'uso dell'interfaccia utente ed evidenziare il motivo per cui un problema di UX è preoccupante a causa di separazione degli interessi o altri principi specifici.

Nella mia esperienza, è inefficace discutere le generalità perché chi lo capisce non ha bisogno di ascoltarlo e chi non lo capisce ha bisogno del modello per avere un contesto sufficiente per capire.

Se sei preoccupato per le risorse necessarie per costruire il modello dell'interfaccia utente, potresti prendere in considerazione l'idea di tempizzare lo sforzo, ad esempio "prenditi 3 ore per mettere insieme un modello dell'interfaccia utente su carta e rivediamolo".