Playtesting

proceso de prueba en el diseño de juegos

El playtesting es un método o proceso mediante el cual se busca identificar como los usuarios interactúan y juegan con un juego. Estos pueden ser videojuegos, juegos de mesa o juegos de rol. Comúnmente es realizado durante diferentes fases del desarrollo del producto aunque puede ser realizado después de haberlo finalizado y comercializado con la intención de mejorarlo.

Propósito

editar

Las sesiones pueden ser realizadas para determinar diferentes problemas que básicamente pertenecen a dos grupos: como hace sentir al jugador y como éste interactúa o reacciona ante determinadas situaciones. Además, se pueden identificar o recolectar datos de errores o glitch del juego que serán comunicados al departamento de QA.

Estructura

editar

Permite dos tipos de investigación, de la pregunta a la respuesta y de la respuesta a la pregunta. Esto es, se puede realizar la sesión para recolectar datos y comprobar una hipótesis previamente establecida o simplemente se puede dejar jugar a los participantes para observar que pasa y extraer preguntas.

Ventajas

editar

Es un método muy efectivo para responder el "qué" y el "por qué" de preguntas previamente planteadas que con otros métodos serían muy difíciles de comprobar. Además, se combina a la perfección con otros métodos de análisis de datos sobre juegos tales como la entrevista.

Desventajas

editar

Los resultados pueden ser alterados de forma no intencionada por el moderador o por el formato. Además, consume mucho tiempo y es lento de analizar. Otro factor a tener en cuenta es que no puede responder con facilidad la cantidad de veces que algo ocurre.

Participantes

editar

Tipo de participantes

editar

Determinar qué o quiénes serán los que participen es clave para el éxito de la sesión de playtesting. En cada caso será mejor utilizar unos u otros.

Target player

editar

Buscar jugadores iguales que aquellos a los que va dirigido el producto y por lo tanto el futuro público potencial. Aun así hay que tener en cuenta que aquellos jugadores que ya conocen el producto o similares de antemano pueden aportar desviaciones y distorsionar los resultados.

Círculo cercano

editar

Aquellos cercanos al desarrollo: amigos, equipo de desarrollo, familia, etc. Su percepción puede ser diferente a la del público general por tener algún tipo de vínculo con el producto pero es más barato y más rápido de conseguir.

Todo el mundo

editar

Evaluar cada respuesta según el parecido al target. Es conveniente terminar cuando los comentarios empiezan a repetirse.

Número de participantes

editar

El número de participantes aconsejable variará según el tipo de problema que se quiera observar con la sesión.

Problemas de usabilidad

editar

Según Nielsen se necesitan unos 5 usuarios. Otros autores como Faulkner afirman que para el 82% de los problemas usabilidad se necesitan alrededor de 10 usuarios.

Para problemas de experiencia de usuario

editar

Mientras el presupuesto y el tiempo lo permita es conveniente seguir haciendo playtesting. Aun así, es razonable parar cuando se esté recibiendo todo el rato los mismos datos.

Recompensa a los participantes

editar

Cada participante suele recibir una recompensa por su tiempo y esfuerzo. Esta puede variar según la empresa que realiza las sesiones. Por ejemplo, Halo 3 fue testeado por 600 playtesters.

Donde se realiza

editar

Se puede realizar en muchos lugares y cada uno tiene sus ventajas y sus inconvenientes:

  • En el estudio de desarrollo: es muy cómodo para los desarrolladores pero los participantes pueden sentirse coartados por la situación y el ambiente.
  • En un laboratorio de playtesting: el lugar está completamente adaptado para las sesiones y poder recolectar datos pero a su vez es muy costoso.
  • En algún lugar público o evento: puede ser muy barato y se pueden encontrar muchos voluntarios pero puede ser difícil encontrar a los adecuados.
  • Por internet o de forma remota: el espectro de participantes se abre mucho más pero la calidad de éste más imprevisible.

Desviaciones y interferencias

editar

Existen diferentes situaciones o elementos que pueden distorsionar los resultados obtenidos del experimento.

  • Sampling bias: viene determinado por si la selección de participantes realizando la prueba viene condicionado de antemano(familiares, amigos, parejas, etc.)
  • Experimenter bias: ocurre cuando el moderador interviene de algún modo con el participante.
  • Response bias: ocurre por la necesidad de los participantes de decir o hacer aquello que él cree que se espera que haga.
  • Procedural bias: viene dado por el entorno en el que se desarrolla el playtesting.
  • Presence of others: se da al tener gente cerca durante la prueba, especialmente al moderador o gente involucrada en el proyecto.

Duración

editar

La primera sesión puede durar como mucho unos 30 minutos. Aunque en algunas ocasiones esta se alarga hasta 1 hora. Para juegos de mesa se suele realizar una partida completa. Aun así, se les comunica de antemano a los participantes cuanto durará y estos pueden finalizar cuando quieran.

Análisis de los datos

editar

El playtesting puede complementarse con una entrevista después de la sesión, cuestionarios o la recogida de datos tanto del producto como biométricos. Los datos recolectados deben ser interpretados por expertos en la materia (investigadores de la experiencia de usuario) con tal de poder ser útiles y aplicables al producto. Es importante que aquellos implicados en el desarrollo no participen en el proceso puesto que es más fácil evidenciar errores y ser más crítico con ellos para alguien externo.

Referencias

editar

Bibliografía

editar
  1. Nielsen, Jakob. “Why You Only Need to Test with 5 Users.” Nielsen Norman Group, March 19, 2000. Retrieved October 1, 2015.
  2. Macefield, Ritch. “How to Specify the Participant Group Size for Usability Studies: A Practitioner’s Guide.” Journal of Usability Studies, Vol. 5, No. 1, 2009. Retrieved October 1, 2015.
  3. The First Hour Experience: How the Initial Play Can Engage (or Lose) New Players. Cheung et al. (2014).
  4. Playful Design. Chapter 8. John Ferrara. Classes of problems. p.100.

Enlaces externos

editar