GamerCreador
Admin
SUPER VIP
Leyenda
Referente
Mentor
Especialista
Creador
Colaborador
Participante
Explorador
- Desde
- 1 Oct 2019
- Mensajes
- 2,382
- Reacciones
- 2,158
- Honor
- 829
- Creador del tema
- #1
Enseñar el prototipo y preguntar «¿te gusta?» suele dejarte con una respuesta difícil de convertir en cambios. Para sacar algo útil de la prueba, ayuda elegir primero qué quieres averiguar.
Aquí tienes un formato sencillo para una sesión corta. Los tiempos son una propuesta para organizarte, no una duración que garantice buenos resultados.
1. Elige una pregunta que tu versión pueda responder
Por ejemplo: «¿Se entiende cómo abrir la primera puerta sin que yo explique el mecanismo?». Esa pregunta es más manejable que «¿mi juego es divertido?».
Comprueba que la versión arranca, que los controles funcionan y que no hay un fallo conocido que impida llegar a la puerta. Puedes encontrar bugs durante el playtest, pero anótalos aparte de las dudas de diseño: un botón que no responde y una pista que nadie entiende requieren soluciones distintas.
2. Busca participantes que se parezcan al público del juego
Puedes empezar con unas pocas personas para detectar problemas, especialmente si tu tiempo es limitado. Eso no representa a todo el mercado ni permite afirmar qué porcentaje de jugadores tendrá una dificultad. Indica también si ya conocen tu juego: haber visto cómo lo desarrollas cambia lo que saben antes de empezar.
No necesitas recoger nombres reales ni información personal para aprender si se entiende una puerta. Si quieres grabar pantalla, voz o cámara, pide permiso antes, explica para qué usarás la grabación y no la publiques sin autorización.
3. Prepara una sesión que no se convierta en un tutorial tuyo
Si estás probando precisamente el tutorial, no lo expliques por adelantado. Si pruebas un combate avanzado, sí puedes preparar a la persona para que llegue con el conocimiento necesario. Lo importante es que la sesión corresponda a la pregunta que elegiste.
Antes, durante y después: una sesión preparada alrededor de una sola pregunta.
4. Separa lo que ocurrió de lo que crees que significa
Esta ficha es un ejemplo inventado, no el resultado de una prueba real:
La observación no demuestra por sí sola cuál es la causa. Tener dos explicaciones posibles evita arreglar enseguida lo primero que se te ocurre.
Una misma observación admite distintas explicaciones. El siguiente cambio sirve para comprobar una de ellas.
5. Haz pocas preguntas, pero específicas
El Game Design Toolkit de HvA recomienda preparar el cuestionario, ajustarlo al contenido disponible y combinar preguntas abiertas y cerradas. En esta explicación de Platzi sobre playtesting también se aborda cómo observar y preguntar por objetivos, satisfacción y confusión. Las preguntas de arriba son una propuesta propia para el ejemplo de la puerta.
6. Termina con una decisión pequeña
Ordena los hallazgos por su impacto: impedir avanzar, dificultar una decisión importante o añadir una molestia menor. Comprueba primero los bloqueos y cambia una cosa relevante cada vez cuando quieras entender qué produjo la mejora.
Vuelve a probar. Una persona nueva ayuda a comprobar el aprendizaje inicial; alguien que repite puede comentar cómo cambia la experiencia, pero ya conoce parte de la solución. Guarda también lo que funcionó, para no perderlo al corregir otros problemas.
¿Qué parte de tu prototipo te gustaría observar sin tener que explicarla? Puedes compartir la pregunta de tu próximo playtest y comentar qué comportamiento te ayudaría a responderla.
Aquí tienes un formato sencillo para una sesión corta. Los tiempos son una propuesta para organizarte, no una duración que garantice buenos resultados.
1. Elige una pregunta que tu versión pueda responder
Por ejemplo: «¿Se entiende cómo abrir la primera puerta sin que yo explique el mecanismo?». Esa pregunta es más manejable que «¿mi juego es divertido?».
Comprueba que la versión arranca, que los controles funcionan y que no hay un fallo conocido que impida llegar a la puerta. Puedes encontrar bugs durante el playtest, pero anótalos aparte de las dudas de diseño: un botón que no responde y una pista que nadie entiende requieren soluciones distintas.
2. Busca participantes que se parezcan al público del juego
Puedes empezar con unas pocas personas para detectar problemas, especialmente si tu tiempo es limitado. Eso no representa a todo el mercado ni permite afirmar qué porcentaje de jugadores tendrá una dificultad. Indica también si ya conocen tu juego: haber visto cómo lo desarrollas cambia lo que saben antes de empezar.
No necesitas recoger nombres reales ni información personal para aprender si se entiende una puerta. Si quieres grabar pantalla, voz o cámara, pide permiso antes, explica para qué usarás la grabación y no la publiques sin autorización.
3. Prepara una sesión que no se convierta en un tutorial tuyo
- Antes, unos minutos: explica que estás poniendo a prueba el juego y que la persona puede parar cuando quiera. Indica los controles que conocería un jugador real en esa versión.
- Durante, unos diez minutos: observa sin señalar la solución. Si necesitas intervenir porque hay un bloqueo, anota cuándo y qué dijiste.
- Después, unos cinco minutos: pregunta por momentos concretos y escucha la explicación antes de proponer cambios.
Si estás probando precisamente el tutorial, no lo expliques por adelantado. Si pruebas un combate avanzado, sí puedes preparar a la persona para que llegue con el conocimiento necesario. Lo importante es que la sesión corresponda a la pregunta que elegiste.
Antes, durante y después: una sesión preparada alrededor de una sola pregunta.
4. Separa lo que ocurrió de lo que crees que significa
Esta ficha es un ejemplo inventado, no el resultado de una prueba real:
- Versión: prototipo puerta 0.2.
- Momento: después de recoger la llave.
- Observación: pulsa interactuar tres veces frente a la puerta y regresa a la sala anterior.
- Comentario del participante: «Pensaba que esta llave era para otra puerta».
- Interpretación provisional: puede que no se comunique la relación entre llave y cerradura.
- Otra explicación posible: el inventario no confirmó que se recogió la llave.
- Cambio a probar: reforzar la confirmación de recogida antes de añadir más instrucciones.
La observación no demuestra por sí sola cuál es la causa. Tener dos explicaciones posibles evita arreglar enseguida lo primero que se te ocurre.
Una misma observación admite distintas explicaciones. El siguiente cambio sirve para comprobar una de ellas.
5. Haz pocas preguntas, pero específicas
- ¿Qué intentabas conseguir cuando entraste en la primera sala?
- ¿Qué te hizo elegir ese objeto o ese camino?
- ¿En qué momento no supiste qué hacer?
- ¿Qué esperabas que ocurriera al usar la llave?
- ¿Qué parte te gustaría volver a probar, si alguna?
El Game Design Toolkit de HvA recomienda preparar el cuestionario, ajustarlo al contenido disponible y combinar preguntas abiertas y cerradas. En esta explicación de Platzi sobre playtesting también se aborda cómo observar y preguntar por objetivos, satisfacción y confusión. Las preguntas de arriba son una propuesta propia para el ejemplo de la puerta.
6. Termina con una decisión pequeña
Ordena los hallazgos por su impacto: impedir avanzar, dificultar una decisión importante o añadir una molestia menor. Comprueba primero los bloqueos y cambia una cosa relevante cada vez cuando quieras entender qué produjo la mejora.
Vuelve a probar. Una persona nueva ayuda a comprobar el aprendizaje inicial; alguien que repite puede comentar cómo cambia la experiencia, pero ya conoce parte de la solución. Guarda también lo que funcionó, para no perderlo al corregir otros problemas.
¿Qué parte de tu prototipo te gustaría observar sin tener que explicarla? Puedes compartir la pregunta de tu próximo playtest y comentar qué comportamiento te ayudaría a responderla.
