È un brutto segno se gli utenti inviano segnalazioni di bug per elementi di design?
Significa in genere che l'applicazione sia confusa o poco chiara, o dovrei semplicemente comunicarlo a un errore utente una tantum, a meno che non sia specificato in modo specifico?
(In realtà non ho alcun rapporto di questo tipo.Questa è una domanda puramente ipotetica sull'opportunità o meno che l'esistenza di "bug" di design sia una cosa negativa.)
È un brutto segno? Penso che sia un avvertimento che vale la pena di esaminare, ma penso anche che ciò accada.
Quando le persone mi inviano qualsiasi tipo di feedback, provo a filtrarlo in tre bucket:
I bug si verificano quando qualcosa ovviamente non funziona nel modo in cui tu ti aspetteresti, né il modo in cui l' utente si aspetterebbe. Come, mi ha chiesto il mio nome, ho inserito "Scott", premi invio, e ha detto "Ciao Joe!"
Questo è come "So che non ne abbiamo mai parlato, ma il programma può dedurre dai gesti del mio mouse che sono mancino e spostare il pulsante OK sul lato sinistro dello schermo?" Questo è quando il comportamento corrente corrisponde sia alle aspettative tuo sia a quelle dell'utente , ma vogliono cambiare le aspettative.
Questo è quando tu ti aspetteresti un risultato da uno scenario, ma l'utente si aspetta un risultato diverso. A volte questa diventa una richiesta di funzionalità, se solo non hanno comunicato le loro aspettative, ma hanno pensato che lo facessero. A volte questo diventa un bug se la tua aspettativa è dimostrata sbagliata.
Tuttavia, molte volte hai conoscenze che l'utente non ha. E se dicessero: "Su questo schermo, posso aggiungere un disco per me stesso due volte con lo stesso nome e cognome! Questo è ovviamente un bug!" La tua risposta potrebbe essere: "Ci sono molte persone nel mondo con lo stesso nome e cognome, quindi non richiediamo che questa combinazione sia unica. Abbiamo un'attività di pulizia che viene eseguita di notte e invia un rapporto Possibili duplicati a servizio clienti quando pensa di rilevare un duplicato con un nome e un indirizzo simili e chiede loro di controllarlo manualmente. "
Quindi dovresti leggere ogni segnalazione di bug, ma i sistemi più complessi avranno segnalazioni di bug che sono in realtà solo richieste di funzionalità, o forse una comunicazione errata dei requisiti. Non comprendere la complessità di fondo del mondo reale è probabilmente la più grande fonte di questi problemi.
Questo non è stato toccato nelle risposte precedenti finora, quindi aggiungerò che potrebbe anche essere un segno di una base di utenti ignoranti. Non uso la parola "ignorante" in modo dispregiativo o condiscendente, semplicemente come un modo per esprimere che sono privi di una conoscenza o di un'educazione adeguate nel loro dominio o delle complessità del software stesso.
La maggior parte degli utenti non è consapevole di quanto debba essere complicato il software per soddisfare determinati requisiti. Qualcosa con l'effetto dell'80% di sforzo riguarda solo il 20% delle funzionalità (casi di frange ed eccezioni).
A volte non capiscono perché il software ha intrinsecamente bisogno di comportarsi in un certo modo, molte volte per prevenire una moltitudine di difetti o corruzione dei dati, ecc ...
Questo non è preoccupante in quanto ciò migliora con una documentazione e una comunicazione chiare e concise.
Se hai un utente esperto nel loro campo, potresti avere un grosso problema. Immagina un contabile che trova il tuo software, in base alla progettazione, che non segue le procedure di contabilità generale o un tecnico che scopre di avere una formula errata. Questo non dovrebbe essere troppo difficile da ricercare per vedere se sono corretti. Ridisegnalo e correggilo se necessario, veloce.
È necessario prendere in considerazione un'opinione su una particolare caratteristica dell'interfaccia utente o su un campo che a loro avviso dovrebbe avere un simbolo di valuta o qualche altra formulazione, almeno fino a quando non si ottengono più feedback. La ricerca di questo potrebbe essere un po 'più difficile.
I bug di design della mia esperienza indicano che i casi d'uso non si adattano ai tuoi veri utenti. Prova a leggere sull'utilizzo di utenti reali per i tuoi casi d'uso (basta dare loro i nomi e una descrizione in miniatura fa miracoli sulla qualità dei casi d'uso.)
Quando i principali venditori di sistemi operativi affermano che "questo comportamento è di progettazione", in genere avevano in mente la facilità di implementazione o il vantaggio commerciale. Se non sei tu, prova a scoprire il vero set di abilità e le relazioni con il tuo software. Lo usano tutto il giorno? Per divertimento ? Una volta a settimana perché ha sostituito i moduli TPS?
L'interfaccia utente dovrebbe seguire The Principle of Least Astonishment - segnalazioni di bug ripetute su una funzionalità che funziona come previsto sono un'indicazione che questo principio non è stato rispettato correttamente.
Ci sono due tipi di bug: la funzionalità non corrisponde alle intenzioni del programmatore, o la funzionalità non corrisponde ai requisiti. I programmatori tendono a concentrarsi sul primo a scapito di quest'ultimo. Per dirla semplicemente, se i tuoi utenti stanno segnalando molti "bug di progettazione", i tuoi requisiti non sono quelli che pensi che siano.
Non necessariamente. Potrebbe essere che il bug riportato sia in un uso del software che è appena al di fuori del suo ambito originariamente definito. Si consideri un software che è stato progettato per fare A, B e C (per un esempio banale, disegnare linee, triangoli e rettangoli). Se D è un passo logico successivo (ad esempio pentagoni), l'utente può presumere che dovrebbe farlo anche questo, e che non farlo è un bug. Ma se questo è al di fuori dell'ambito originale, non è un bug. Potrebbe invece trattarsi di una svista (bug) nella progettazione o di un'area grigia nelle specifiche o di un diverso insieme di ipotesi fatte dallo sviluppatore e dall'utente.
(Modifica - aggiunto il mio commento alla risposta per il suggerimento di @Marjan Venema.
Credo che sia un brutto segno soprattutto a causa del fatto che il design non è generico e il requisito degli utenti non è completamente compreso / analizzato.
Vedo due categorie di design, - Design per caso. - Progetta intenzionalmente.
La progettazione per errore causa spesso problemi di questo tipo e non può essere sostenuta.
Vorrei aggiungere alla risposta di maple_shaft sull'ignoranza degli utenti. Devi anche ricordare che al 90% degli utenti interessa solo la la loro esperienza e il modo di usare il sistema. Non si preoccupano degli altri utenti, perché dovrebbero? Il nostro lavoro di designer / sviluppatori è quello di prendere in considerazione tutti i diversi tipi di utenti e creare qualcosa che si adatti a tutti nel miglior modo possibile. La maggior parte delle volte non è possibile rendere una soluzione ottimale per tutti.
Ma ovviamente devi leggere e valutare il feedback dei tuoi utenti! Dopo tutto, sono quelli che usano la tua creazione!
Gli utenti che hanno inviato le richieste di bug non sono stati generalmente consultati sul design, quindi non è sorprendente che vedano le cose come bug che sono state scelte deliberate di progettazione. Per un utente tutto ciò che non funziona come previsto è un bug.
Ho riscontrato che il problema è spesso un segnale che il BA o il PM hanno solo requisiti da parte di manager non utenti effettivi. Ciò che i dirigenti si aspettano dal sistema è spesso molto diverso da quello di cui hanno realmente bisogno le persone che inseriscono i dati. Mi è stato insegnato a raccogliere i dati direttamente dagli utenti effettivi, ma la maggior parte dei BA che ho incontrato ultimamente parla solo con i manager (e in genere con manager relativamente senior).