it-swarm-eu.dev

Come si comunica la gravità dei bug di progettazione? Hai dei modi standardizzati per farlo?

Quando si affrontano e si valutano i bug relativi all'usabilità, trovo spesso che devo ricorrere a fare uno spettacolo o descrivere in modo elaborato e drammatico il dolore dell'utente per un problema. Mentre sono sicuro che dovrò sempre fare un po 'di questo, vorrei che ci fosse un modo più standardizzato di comunicare quanto sia grave/si sente un problema. Ho letto di persone su Mozilla che identificano i bug con cui si rompono l'euristica, che penso sia un'ottima idea, ma non aiuta molto con la gravità. Qualcuno ha buone idee o processi là fuori?

Un esempio potrebbe essere, un bug può sembrare a un designer, oh mio dio, non dovremmo mai rilasciarlo in questa condizione, ma a uno sviluppatore che lo ha programmato il comportamento può sembrare ovvio, quindi non sembra affatto grave.

8
Becky

User Focus ha un buon articolo sull'argomento dando la priorità ai problemi di usabilità .

Sono d'accordo con il sentimento del post di apertura. Se lavori in un ambiente di ingegneria o con un sistema complesso di grandi dimensioni, avere una metodologia e un processo di reporting coerenti e comprensibili è di vitale importanza. Parte del motivo per cui è importante è prendere sul serio e l'altra parte è praticare una buona comunicazione e integrarsi in modo significativo con gli altri team e processi con cui stai lavorando.

Portare a casa il fatto che qualcosa di veramente veramente è un problema ed è un grande dolore per gli utenti, quindi integrare la tua segnalazione con video clip dell'interazione può fare miracoli per spostare le opinioni.

7
Splog

Dopo aver lottato con questo problema per un paio d'anni e aver finito per creare un prodotto con un'usabilità relativamente scarsa, ho risolto questo problema in un modo diverso.

Ci sono due fonti (almeno dove lavoro) al problema: 1) "The Business" non pianificherà mai/stabilirà la priorità dei problemi di usabilità come a) preferirebbe avere nuove funzionalità/correzioni di bug eb) non avere un modo reale di concepire o quantificare il costo della scarsa usabilità (dopo tutto sono esperti di dominio, non esperti di software).

2) Gli sviluppatori (tradizionali) non pianificheranno/assegneranno mai la priorità ai problemi di usabilità poiché a) spesso non riescono a vedere l'entità/il costo del problema eb) sono spesso meno fiduciosi nello sviluppo del front-end ec) la loro attenzione viene costantemente rubata per questioni che sono più importanti per il lavoro di uno sviluppatore.

Di conseguenza, l'usabilità ne risente.

Come tale, IMO, è essenzialmente necessario un canale di sviluppo separato per affrontare l'usabilità. È quasi lo stesso del debito tecnico (che vorrei anche sostenere venga "risolto" in questo modo). Crea un nuovo canale di sviluppo, che sia piccolo come dedicare un paio di punti agili per iterazione (o un paio di giorni per due settimane di rilascio, qualunque cosa) a, in un mondo ideale, assumere un ingegnere front-end con la sua priorità -elenco. Questo nuovo canale di sviluppo sfugge costantemente e costantemente a problemi di usabilità e ai problemi di usabilità non viene più assegnata priorità rispetto a problemi di non usabilità ma piuttosto l'uno rispetto all'altro.

Ora, per entrambi il pubblico del mio primo paragrafo, se vai via e passi un paio di giorni a raccogliere alcuni riassunti di ricerca, risultati di casi studio, citazioni di guru riconosciuti ecc., Dovresti essere in grado di costruire un argomento che convincerà le persone . Ma chi ha il tempo di dedicare 4 ore alla ricerca e alla costruzione di argomenti per dare una priorità sufficiente a un lavoro di 1 ora? Ma se ottieni un argomento insieme (citando alcuni esempi di scarsa usabilità nella tua app) non a supporto della giustificazione della priorità di un singolo problema ma piuttosto della giustificazione di un canale separato di sviluppo, il payoff improvvisamente vale molto di più lo sforzo.

Sono un normale sviluppatore C # .Net, con un crescente interesse per l'usabilità. Quello che ho fatto è stato formulare un argomento sull'importanza di esaminare i problemi di usabilità, sono andato al mio CTO con una proposta e ora sto dedicando una percentuale del mio tempo a problemi di usabilità. Il mio team ha perso alcune risorse di sviluppo di base (stiamo assumendo, quindi è stato un argomento più facile da fare comunque) ma ora un po 'di usabilità verrà finalmente esaminata.

A lungo termine, penso che parte del mio nuovo lavoro sia quello di educare gli altri sviluppatori in modo da non rilasciare funzionalità che mostrino scarsa fruibilità. Amplifica gli effetti, per così dire.

In bocca al lupo!

7
Mark Gibaud

Gli elementi visivi, in particolare le dimostrazioni, sono quelli che ho visto avere il maggiore impatto.

Questo avveniva in un ambiente Agile in cui il team di UX stava inviando storie al portafoglio ordini del prodotto e facendole votare durante le riunioni di stima.

Gli elementi visivi funzionavano sempre in termini di riferimenti agli screenshot, ma il migliore era mostrare effettivamente il problema in azione e descrivere il motivo per cui era un problema.

Se non ti trovi in ​​un ambiente Agile, devi comunque tenere riunioni di sviluppo in cui è possibile sollevare problemi: sii pronto a mostrare ciò che è rotto e a discutere sul perché lo consideri "rotto".

(A proposito, per chi non ha familiarità con Agile, quando vuoi che qualcosa funzioni, lo scrivi e lo invii al grande elenco di "ciò su cui dobbiamo lavorare." L'elenco viene rivisto settimanalmente e discusso da sviluppo, UX, QA , gestione del prodotto e principali parti interessate).

1
gef05

Vengono in mente gli indicatori standard, possibilmente combinati con una sfumatura di colore che va dal giallo all'arancione al rosso.

Si potrebbero usare altre analogie: icona di una coccinella, una pentola per stoviglie, un bicchiere, una persona, in varie fasi di "rottura". Vale a dire: un cerotto da qualche parte, una crepa (o un "sorriso" rugoso), un pezzo rotto (spento), ... completamente frantumato/schiacciato

Fai solo attenzione quando usi analogie animali/umane che non diventano troppo grafiche.

1
Marjan Venema

L'usabilità non sta programmando.

Sarebbe fuorviante creare un sistema così graduale.

Se pensi davvero che qualcosa sia così imperfetto che in qualche modo rompa il sistema (come un pulsante mancante per portarti al passaggio successivo), risolvilo.

Altrimenti è solo un problema di usabilità e non importa quanto sia importante per noi professionisti non trovarli vicino a metriche vicine quando il codice non funziona.

Nella programmazione quando pensa che non funzionano non funzionano periodo. Per farlo funzionare dovrai ripararlo.

Nell'usabilità è possibile cavarsela molto di più prima che il sistema si rompa.

0
ThomPete