In questa guida
Hai chiesto ai tester di trovare bug e ti è arrivata una lista di desideri: modalità scura, esportazione, widget, una vista calendario, condivisione. È un buon segno che le persone ci tengano, ma una lista di idee non è un piano. Se costruisci tutto, l'app cresce in ogni direzione e nulla è finito. Prima ordina, poi scegli.
Passo 1: metti ogni voce in una di quattro caselle
| Casella | Domanda | Esempio |
|---|---|---|
| Bug | L'app fa qualcosa di diverso da quello che doveva fare? | Il pulsante Salva non fa nulla |
| Problema di usabilità | Funziona, ma le persone si perdono o rallentano? | Non trovo dove modificare una voce |
| Desiderio | È qualcosa di nuovo che ancora non esiste? | "Aggiungi un'esportazione in CSV" |
| Opinione | È una questione di gusto, senza un compito dietro? | "Preferisco il blu" |
Bug e problemi di usabilità vanno nel normale processo di correzione. Le opinioni finiscono in una nota, a meno che più persone non dicano la stessa cosa. Il resto di questa pagina riguarda i desideri.
Passo 2: trasforma ogni desiderio in un problema
Un desiderio è una soluzione che qualcuno ha inventato. Sotto c'è un compito che la persona non è riuscita a completare. Chiedi: "Che cosa stavi cercando di fare?" Poi scrivi il problema in una frase.
| Desiderio | Problema da risolvere |
|---|---|
| "Aggiungi l'esportazione in CSV" | "Devo portare i miei dati in un foglio di calcolo per il commercialista" |
| "Aggiungi widget" | "Voglio vedere lo stato di oggi senza aprire l'app" |
| "Vista calendario" | "Non riesco a vedere cosa mi aspetta nelle prossime settimane" |
Ora puoi chiederti se esiste una soluzione più piccola o più economica. Una email settimanale può risolvere il problema del calendario più in fretta di una nuova schermata.
Passo 3: conta e raggruppa
- Unisci i problemi simili in un'unica riga.
- Aggiungi un segno per ogni persona indipendente che l'ha segnalato.
- Metti in cima quelli che corrispondono allo scopo principale della tua app.
Dieci idee diverse spesso si riducono a tre problemi. Tratta i problemi come la lista, non le idee.
Passo 4: applica regole semplici
- Serve al compito principale? Se la tua app è un timer, un grafico del budget non fa parte del nucleo.
- Più persone indipendenti segnalano lo stesso problema? Una richiesta è un segnale da tenere d'occhio, tre sono un segnale per agire.
- È economico e sicuro? Le richieste piccole e a basso rischio possono entrare subito; quelle grandi richiedono una decisione.
- Aumenta il carico di manutenzione? Ogni funzionalità va mantenuta, testata e spiegata.
- Si adatta al tuo utente target? Non ogni tester è il tuo utente.
Tutto ciò che non supera la prima regola finisce in una lista "non ora". È una decisione, non un rifiuto.
Passo 5: comunicalo ai tester
Rispondi comunicando la decisione: "Previsto per il prossimo aggiornamento", "Ci stiamo pensando" oppure "Non ora, perché non si adatta al focus". Le persone accettano meglio un "no" che il silenzio. Non promettere date che non puoi rispettare.
Evita che le richieste ti sommergano
- Dai ai tester un compito per il test, così riferiscono su quello e non su tutto.
- Prevedi uno spazio separato per le idee. Un campo per i problemi e uno per i desideri tengono le due cose separate.
- Dì nell'invito a che punto è l'app, per esempio "Adesso mi interessano solo i bug e le parti confuse".
Per una classifica generale per impatto e sforzo, vedi come dare priorità al feedback sull'app.
Correlati
- Panoramica: Problemi nei test delle app e soluzioni
- Come ottenere i log dei crash dal telefono di un tester
- Bug che compaiono solo in una lingua o regione
AppReviewX ti dà feedback privato e strutturato, che aiuta a tenere separati bug, usabilità e desideri. Ogni feedback che scrivi vale un credito. Inizia gratis