Cosa fai quando un utente richiede una funzione che non implementerai?

Cosa fai quando un utente richiede una funzionalità complessa che potresti implementare, ma non lo farai perché 1) aggiunge complessità non necessaria agli altri utenti 2) non lo farai come opzione perché non vuoi che il tuo pannello delle impostazioni sia complicato.

Ho scritto un'app iOS e ci sono alcuni utenti che mi hanno chiesto alcune funzionalità complesse che non posso fare per i motivi sopra. Il più delle volte ho appena risposto loro che "Lo prenderemo in considerazione". Spiegare loro che sono nella minoranza che desidera questa funzionalità non aiuterà neanche. Quindi, cosa fai nel caso in questo modo?

Penso che tu stia facendo la cosa giusta. Non puoi piacere a tutti, e non dovresti! Sii educato e professionale, ma non devi fare tutto ciò che ti viene chiesto.

Devi scendere a un compromesso. L'utente (il motivo per cui esiste l'app) afferma che non soddisfa uno dei suoi bisogni.

Esiste una differenza tra soddisfare le esigenze dell'utente e consentire all'utente finale di progettare la propria applicazione. Incontra l'utente e chiedi molto "Perché?" domande fino a quando non si arriva al nocciolo dell'attività che la persona sta cercando di eseguire e non può eseguire, o che è troppo ingombrante per eseguire nell'interfaccia utente corrente. Prendi quelle note e prendi in giro alcuni approcci alternativi con cui PUOI convivere e presentali all'utente.

Soprattutto: ricorda che l'app non esiste per semplificarti la vita come programmatore. L'app è lì per servire l'utente.

Se leggi il blog di Seth Godins ( http://sethgodin.typepad.com/ ) vedrai lo stesso messaggio che viene ripetutamente:

1. Spedisci qualcosa (e ascolta il feedback)
2. Non cercare di soddisfare tutte le persone per tutto il tempo.

Ho avuto un problema simile a te con un prodotto che vendo. Ho ricevuto ogni tipo di richiesta per ogni tipo di funzionalità. L'applicazione è diventata più complessa di quanto volessi davvero. Ogni opzione aggiunge complessità, qualcosa che volevo evitare. E ora ho più complessità di quanto vorrei.

In questo modo piace più utenti. E allontana gli utenti che lo trovano troppo difficile da configurare.

Avere una configurazione semplice / avanzata è una via d'uscita. Fino a un certo punto. Rende il tuo sviluppo più complesso, però.

In tutti i casi in cui ricevo una richiesta, rispondo sempre educatamente. A volte mi rifiuto completamente, anche se questo è raro. E dove lo faccio, spiego perché, di solito sarebbe in risposta a una richiesta che richiederebbe il rinnovamento dell'intera interfaccia utente, un'impresa così massiccia che non ci andrei. In tal caso spiego i miei motivi, ma ringrazio l'utente per la richiesta.

In TUTTI i casi, compresi quelli che rifiuto immediatamente, li registro nel database delle caratteristiche e difetti per essere preso in considerazione per la prossima versione. Questo concede un po 'più di tempo per pensarci su, e forse verrà in seguito con un'alternativa che non è esattamente ciò che è stato richiesto, ma potrebbe aggiungere un valore.

Se una richiesta di funzionalità è stata considerata, annotata e alla fine (al momento dello sviluppo) viene presa la decisione di ucciderla, la chiudo. Altrimenti vengono lasciati aperti per la riconsiderazione più tardi.

Questo non è un approccio perfetto, ma alla fine come autore del software hai determinati principi di progettazione che devi rispettare o abbandonare. La scelta di ciascun approccio deve essere attentamente considerata.

Penso che dovresti essere onesto con i tuoi utenti. Non dire loro, "Lo prenderemo in considerazione", se hai già deciso che non lo farai. Ciò porterà gli utenti a credere che la funzionalità arriverà un giorno e rimarrà delusa perché non arriva mai.

A lungo termine, ciò ti gioverà di più, credo.

Vorrei solo ringraziarli per il suggerimento, ma direi che non è sulla tua road map in questo momento. Le persone capiranno soprattutto che hai risorse limitate.

Di solito faccio tre cose quando mi trovo in una situazione del genere:

1. Penso due volte se l'idea dell'utente potrebbe essere una buona idea dopo tutto. Ho imparato a non fidarmi del mio primo istinto. A volte l'utente ha ragione e io ho torto.
2. Spiega all'utente perché non puoi includere quella funzione.
3. Spiega all'utente come può ottenere ciò di cui ha bisogno con il software che possiede

Penso che l'ultimo punto sia molto importante. La maggior parte degli utenti non desidera implementare esattamente il proprio suggerimento. Hanno solo bisogno di una soluzione a un problema e suggeriscono la soluzione più semplice possibile a cui possono pensare. Forse puoi trovare una soluzione migliore che puoi implementare.

Per ciascuno dei nostri prodotti, abbiamo un "elenco di idee per le versioni future". Quindi quello che diciamo ai nostri utenti è "inseriremo il tuo suggerimento in quell'elenco" - e questo è onesto, lo facciamo davvero.

L'elenco non ha priorità, ma selezioniamo regolarmente le cose e le usiamo per alimentare il nostro arretrato. Non li prendiamo "in ordine", ma cerchiamo di identificare quali idee danno il "maggior rapporto qualità-prezzo" - il massimo beneficio per il maggior numero possibile dei nostri utenti, per un ragionevole sforzo di sviluppo.

È probabile che le richieste di funzionalità contro l'integrità concettuale del prodotto rimangano lì per sempre. Ma a volte capita che almeno alcune delle idee sepolte in quelle richieste di funzionalità possano essere realizzate, forse non esattamente nel modo in cui la persona che l'ha suggerito stava pensando, ma in un modo che si adatta meglio all'architettura del prodotto.

Quindi il mio suggerimento qui è: non dire semplicemente "Lo prenderemo in considerazione". e dimentica l'idea non appena finisci la telefonata. Invece, disponi di uno strumento in cui memorizzi idee e richieste di funzionalità, magari in un tracker di problemi, forse in un Wiki, forse in un foglio di calcolo, qualunque cosa si adatti meglio alle tue esigenze.