En esta guía
Les pediste a los testers que encontraran bugs y te llegó una lista de deseos: modo oscuro, exportar, widgets, una vista de calendario, compartir. Es buena señal que a la gente le importe, pero una lista de ideas no es un plan. Si lo construyes todo, la app crece en todas direcciones y nada queda terminado. Primero ordena, luego elige.
Paso 1: mete cada punto en una de cuatro cajas
| Caja | Pregunta | Ejemplo |
|---|---|---|
| Bug | ¿La app hace algo distinto de lo que debería? | El botón Guardar no hace nada |
| Problema de uso | ¿Funciona, pero la gente se pierde o va lenta? | No encuentran dónde editar una entrada |
| Deseo | ¿Es algo nuevo que todavía no existe? | "Añadir exportación a CSV" |
| Opinión | ¿Es gusto, sin una tarea detrás? | "Prefiero el azul" |
Los bugs y los problemas de uso van a tu proceso normal de corrección. Las opiniones van a una nota, salvo que varias personas digan lo mismo. El resto de esta página trata de los deseos.
Paso 2: convierte cada deseo en un problema
Un deseo es una solución que alguien inventó. Debajo hay una tarea que no pudo terminar. Pregunta: "¿Qué intentabas hacer?" Luego escribe el problema en una frase.
| Deseo | Problema a resolver |
|---|---|
| "Exportar a CSV" | "Necesito pasar mis datos a una hoja de cálculo para mi contable" |
| "Widgets" | "Quiero ver cómo va hoy sin abrir la app" |
| "Vista de calendario" | "No veo lo que viene en las próximas semanas" |
Ahora puedes preguntarte si existe una solución más pequeña o más barata. Un correo semanal puede resolver el problema del calendario más rápido que una pantalla nueva.
Paso 3: cuenta y agrupa
- Une los problemas parecidos en una sola línea.
- Añade una marca por cada persona independiente que lo haya pedido.
- Pon arriba los que encajan con el propósito principal de tu app.
Diez ideas distintas suelen reducirse a tres problemas. Trata los problemas como la lista, no las ideas.
Paso 4: aplica reglas sencillas
- ¿Sirve a la tarea principal? Si tu app es un temporizador, un gráfico de presupuesto no forma parte del núcleo.
- ¿Varias personas independientes piden lo mismo? Una petición es una señal para vigilar; tres son una señal para actuar.
- ¿Es barato y seguro? Los cambios pequeños y de bajo riesgo pueden entrar pronto; los grandes necesitan una decisión.
- ¿Añade mantenimiento? Cada función hay que mantenerla, probarla y explicarla.
- ¿Encaja con tu usuario objetivo? No todos los testers son tus usuarios.
Lo que no cumpla la primera regla va a una lista de "ahora no". Es una decisión, no un rechazo.
Paso 5: avisa a los testers
Responde con lo que decidiste: "Previsto para la próxima actualización", "Lo estamos pensando" o "Ahora no, porque no encaja con el enfoque". La gente acepta mejor un "no" que el silencio. No prometas fechas que no puedas cumplir.
Evita que las peticiones se desborden
- Dales a los testers una tarea para la prueba, para que informen sobre eso y no sobre todo.
- Ofrece un lugar aparte para las ideas. Un campo para problemas y otro para deseos mantiene separadas las dos cosas.
- Di en la invitación en qué etapa está la app, por ejemplo "Ahora solo quiero saber de bugs y de las partes confusas".
Para un ranking general por impacto y esfuerzo, mira cómo priorizar el feedback de la app.
Relacionado
- Visión general: Problemas de pruebas de apps y cómo solucionarlos
- Cómo obtener los logs de fallos del teléfono de un tester
- Bugs que solo aparecen en un idioma o región
AppReviewX te da feedback privado y estructurado, lo que ayuda a mantener separados los bugs, los problemas de uso y los deseos. Cada feedback que escribes te da un crédito. Empieza gratis