Playtesting

De Wikipedia, la enciclopedia libre

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]