Un proceso UX fuera de la pantalla: El desarrollo de un juego de mesa

Desde hace dos años he estado llevando un proceso UX desarrollando un juego de mesa. 

Me gustan los juegos; entretienen, relajan, divierten; cuentan historias; crean conexiones entre quienes los juegan. Esto es igual en los deportes, en los videojuegos y en los juegos de mesa. De adolescente, me imaginaba en el futuro programando videojuegos (e hice algunos pininos con QBasic).

Mi apretado modus vivendi actual me impide dedicarme al hobby como antes. Sin embargo, un día me topé con Tabletop, el programa de juegos de mesa de Wil Wheaton, y redescubrí una pasión en mí… la de crear mundos, crear reglas y competir con ellas en un ambiente de camaradería. Tras no mucho tiempo, comencé a formular juegos en mi cabeza a la hora de la ducha.

Poco a poco surgió en mi cabeza la imagen del juego que quería. El (auto-)análisis de requerimientos me dio objetivos claros. El juego debía ser:

  • Rápido de jugar: que pudiera jugarse durante la hora de la comida,
  • fácil de entender: de modo que gente no familiarizada con los juegos de mesa pudiera entenderlo sin mucho problema,
  • de acción rápida: que hubiera acción y atención en cada turno,
  • donde el desenlace no fuera fácilmente anticipable, 
  • de producción relativamente barata, de modo que pueda tener un costo relativamente bajo con buenos valores de producción.

Considerando mi realidad, me enfoqué en dos personas:

  • El jugador casual, novicio y con poco tiempo como yo.
  • El jugador empedernido, con suficiente tiempo y que busca una experiencia más plena e inmersiva.

Si bien ya tenía en mi cabeza ideas sobre algunos tipos y patrones de diseño de juegos de mesa, no tenía idea sobre el proceso. Resulta que es un camino que muchos han tomado, sea como hobby o como su profesión. Este artículo me dio una hoja de ruta; notarán que existen gruesos paralelismos con los procesos de UX, de modo que decidí abordarlo como proceso de UX.

Estableciendo los principios de diseño

Comencé, pues, una serie de ciclos de creación de reglas, prototipos y pruebas con jugadores. El primer ciclo dio origen al tema del juego (entiéndase: el look and feel).

collage

Un juego de mesa, al igual que un sistema y un sitio web, es una experiencia formada de diversos factores:

  • Las reglas, que definen tanto el propósito de cada jugador como su conducta, usando las abstracciones definidas en el juego: ¿ganar a los demás o colaborar con los otros?, ¿amasar recursos, administrarlos, intercambiarlos?, ¿a qué poner atención en los turnos de los demás?, etc.
  • La transmisión de información entre actores; los elementos gráficos y físicos (fichas, etc.), lo cual permite que las reglas funcionen y también ayuda también a establecer el tercer punto,
  • la temática del juego – y la ficción que se desarrolla en la mente del jugador, que puede ser muy sólida e importante (en juegos como D&D) o inexistente, en el caso de juegos matemáticos abstractos como el solitario o el comesolo.

Decidí guiarme por la máxima de Sid Meier, legendario autor de videojuegos como Civilization:

Un juego es una serie de decisiones interesantes.

Decidí quedarme con los siguientes patrones de diseño:

  • El modo de juego sería altamente competitivo.
  • El ambiente sería de batalla campal.
  • Los recursos serían limitados y su administración estratégica sería clave para el éxito de un jugador.
  • El resultado de cada acción sería determinado en parte por la estrategia del jugador y en parte por el azar.

De aquí derivó una primer serie de reglas que ponían a los jugadores en un tablero con 19 celdas, o cuartos, hexagonales. Cada jugador tendría una cantidad limitada de “vida”. Tendría que correr entre cuartos para recoger “recursos” representados por cuadritos en el tablero. Los mismos recursos bloquearían los pasajes entre cuartos, creando una dinámica de flujo geográfico.

Dichos recursos, al tomarse, se volverían cartas, usables para atacar a otros jugadores, defenderse u obtener atributos especiales. Los jugadores tendrían siempre hasta 6 cartas, tres de las cuales podrían ocultarse estratégicamente a otros jugadores.

Adicionalmente, establecí un objetivo adicional: encontrar tres cartas específicas que, al acumularlas, darían la victoria. La otra manera de ganar era simplemente eliminar al resto de los participantes, atacándolos y resistiendo sus ataques.

En este momento no tenía idea de cuánto podría durar una sesión de juego, pero sabía que mi meta era que una sesión durara entre 30 minutos y una hora, con hasta 6 jugadores.

La primera prueba con usuarios

Ensamblé, pues, un prototipo de baja resolución e hice una primer prueba con usuarios, aprovechando un evento en mi empresa.

Prototipo de baja resolución

Esta prueba (comparable a un test de usabilidad) fue, necesariamente, una en la que yo participé como moderador y explicando reglas. Al final, pregunté a los participantes su opinión y recolecté sugerencias de mejora, en una mini-dinámica de diseño participativo.

Resultó que la dinámica del juego era interesante y daba pie a decisiones constantes. La temática del juego llamó la atención incluso de los no jugadores. Sin embargo, había muchos factores en contra:

  • Las reglas no eran rápidas de explicar ni de entender.
  • Había demasiados componentes, de modo que el estado del juego era difícil de seguir en cualquier momento.
  • El diseño visual del juego era contraintuitivo: al iniciar el turno de un jugador, no era evidente qué es lo que se debía hacer. Aún más: el juego incluía dados y un tablero, de modo que el instinto inicial de los jugadores (acostumbrados a juegos como Monopoly, por ejemplo) era tirar el dado y mover su ficha. Esto, sin embargo, no era siquiera una acción válida.
  • La sesión de juego fue muy tardada: en 30 minutos, seis jugadores lograron terminar tres turnos cada uno.
  • Y, por supuesto, las reglas mismas no habían sido probadas, estaban en constante flujo y necesitaron cambios y correcciones en el instante en que eran jugadas.

Sin embargo, de esta primera primera prueba, el resultado más alentador fue que los jugadores se divirtieron y se emocionaron. Esto me indicó que el diseño iba por el camino correcto.

Estableciendo un proceso cíclico

El siguiente paso fue integrar los aprendizajes para modificar reglas y dinámicas. Recluté a algunos de mis compañeros de trabajo para ir probándolas; para esto, organicé reuniones donde también cenábamos, ya fuera en casa de alguno de nosotros o en un restaurante (recordemos que el investigador debe recompensar a sus participantes).

IMG_3812

Gracias a esto pude comenzar a generar nuevas reglas y prototipos en ciclos, cuya duración variaba entre una semana y varias. Nuevas ideas fueron probadas, implementadas, cambiadas, desechadas y vueltas a probar.

El principal objetivo de estos ciclos era reducir la complejidad del juego sin detrimento de los factores que lo hacían interesante. Gracias a esto, el juego fue cambiando de forma y poco a poco fue llegando a sus objetivos iniciales.

IMG_20150611_210138895

A la mitad de este periodo invertí en componentes para crear un prototipo de mediana definición. Al tener un grupo estable de testing, mi participación en las pruebas fue haciéndose más externa, recorriendo así la gradiente que Jared Spool define. Ya podía dejar que el panfleto de reglas escritas explicara cómo jugar, efectivamente acercando la dinámica del test play a la de un estudio de campo.

Todo fue muy bien hasta que sucedió lo que suele pasar en estas empresas meramente creativas: me estanqué.

Saliendo del pozo creativo

El profesional de UX tiene un arsenal de medios para la consecución de sus objetivos. En un proceso de UX formal, el investigador generalmente procurará ir cambiando de sujetos de prueba, usará diferentes tipos de pruebas, etc. y tiene objetivos de negocio claros. Se pueden emplear métodos como las lluvias de ideas para “salir de la caja”. Esto permite que el proceso avance.

A mí me costó salir de esta caja. El principal causante quizás fue no utilizar dichas técnicas o no involucrar a una mayor variedad de personas en el proceso creativo.

Dejar pasar el tiempo y obtener nuevas ideas fue lo que me permitió volver a abordar el problema inicial y deshacerme de algunos de los paradigmas iniciales. Dejé de lado el tablero y muchas de las fichas. Inicié, pues, una “nueva rama” de diseño, donde el juego se rige principalmente por sus cartas.

IMG_20160319_141009159

Cambiar a un paradigma de “juego de cartas” implicó regresar a una fase de prototipo de baja resolución. Sin embargo, esta edición está construida utilizando los aprendizajes recogidos durante dos años.

Los test plays más recientes se han logrado terminar en media hora. Los nuevos participantes lo entienden en menos de cinco minutos mediante mera observación y breves explicaciones. El factor diversión sigue presente; las decisiones siguen siendo una combinación de azar y estrategia, y la dinámica del juego es tal que, incluso al final del juego, el desenlace no puede ser claramente predicho, haciendo de éste un buen “juego de espectador”.

En conclusión

Aún estoy consolidando las reglas de esta versión del juego y sus posibles extensiones. Seguirán nuevos prototipos de mayor definición y pruebas con usuarios externos. Luego decidiré si pretenderé comercializarlo o distribuirlo libremente, y de qué manera será.

Sin embargo, ya en este momento me siento satisfecho por haberme demostrado a mí mismo que el proceso de UX funciona en muchos medios y que los resultados son altamente gratificantes, como el proceso mismo.

Rehaciendo flopez.com.mx: La optimización y lo que sigue

Este es el tercer y último post de la serie donde narro los cómos y por qués del último rediseño de flopez.com.mx. Si no los has leído, te invito a que les eches un ojo a los preparativos y a la construcción del sitio usando Middleman.

Calificación de PageSpeed de flopez.com.mx, septiembre de 2015.
Calificación de PageSpeed de flopez.com.mx, septiembre de 2015.

Venciendo a Google Pagespeed

Tener en cuenta la eficiencia desde el inicio del proceso de creación del sitio tuvo un impacto definivo llegado a este punto, cuando subí por primera vez mis archivos al web y pregunté a Google: ¿cuál es mi Pagespeed?

Los puntos más débiles de un sitio en cuanto a la velocidad de carga, que es el enfoque de esta evaluación, suelen ser el tamaño de los recursos (imágenes, CSS, scripts…), su método de carga (sincrónico o asincrónico) y desde dónde se cargan (si desde un CDN confiable o no).

Lo que descubrí en este proceso es que si mantienes la cantidad de recursos externos lo suficientemente baja, el Pagespeed no se verá muy afectado aunque no se sigan todas las recomendaciones.

Pero vayamos paso a paso:

Scripts. El sitio no llama a scripts externos; todo el código está embebido. Esto elimina varios dolores de cabeza.

Imágenes. La página de inicio usa solo cinco imágenes: dos fotografías (la del puente y una foto pequeña para el pie) y tres ilustraciones: el logo del inicio, una pequeña ilustración de cierre al pie y una imagen arriba de la forma de contacto.

Las imágenes fueron optimizadas usando Kraken, que ofrece un excelente servicio gratuito (hay otras alternativas, como el venerable ImageMagick, que no requieren conexión a Internet).

Consideré, para las ilustraciones, usar SVG. Sin embargo, mi logo solo lo tengo rasterizado, y si bien consideré rehacerlo vectorialmente, hice primero pruebas de carga y descubrí que por el momento no sería necesario. Con esto lo decidí: las ilustraciones, pues, son PNG.

Fuentes. Google Fonts ofrece varias maneras de embeber las fuentes. De todas estas, la única que yo recomiendo es, sin embargo, la más complicada: la carga asincrónica mediante Javascript – y el script colocado al final del HTML. Esto evita bloquear la carga de otros recursos, como el CSS y las imágenes, que pueden tener mayor impresión al momento del despliegue inicial de una página.

CSS. Esto consta de dos partes: la fácil/obvia y la truculenta.

La optimización “fácil” (para el CSS y cualquier otro archivo de texto) es la minificación: mediante este proceso se eliminan espacios. En la minificación de Javascript se va un paso más allá y se realizan sustituciones de caracteres, nombres de variables, etc. que suelen tener impactos dramáticos en el tamaño de los archivos. Esto es fácil porque es automático en la gran mayoría de los flujos modernos de creación de sitios web.

La parte “difícil”, específicamente para los estilos, es algo relativamente nuevo. Google pide determinar cuáles estilos son los esenciales para el render “arriba del pliegue” de una página y embeber dichos estilos en el HTML. Autores importantes han hablado del tema e inclusive expresado su inicial desconcierto.

Intenté primero con soluciones automatizadas para determinar qué CSS es crítico, pero no resultaron ser lo que yo esperaba. Terminé, pues, por analizar manualmente el contenido de mi Sass y separarlo en dos archivos: “critical.scss” y “non-critical.scss”, de manera que ambos se compilan en un solo archivo para desarrollo local, pero al subir el sitio solo lo no crítico es cargado externamente; el resto está embebido.

El criterio que usé para separar lo crítico de lo no crítico fue:

  • Todos los estilos del encabezado son críticos. Esto es porque siempre estarían “arriba del pliegue”, por más pequeño que sea un dispositivo.
  • Los colores y la estructura base son críticos, a tal grado que puedan construir una experiencia básica de usuario. A este punto, de mobile first, digamos que me quedo con mobile only.

Por otro lado:

  • Las fuentes especiales son no críticas.
  • Todos los media queries son no críticos.
  • El contenido del pie de página es no crítico.
  • Los contenidos que no es probable que se carguen arriba del pliegue la mayor parte del tiempo son no críticos. Esto incluye, por ejemplo, la forma de contacto.

Gracias a todo lo mencionado, a la fecha el sitio logra 95/100 y 100/100 en móvil, así como 97/100 en desktop, de calificaciones en PageSpeed Insights.

Lo que no he logrado: la mejor configuración del caché del servidor. (Debo hablar con mi proveedor de esto.)

Los pendientes

Aún quiero hacer algunas cosas antes de considerar esta misión terminada:

  • Optimizar mi proceso de desarrollo local. La desventaja de trabajar en Windows en una era en la que el desarrollo front-end se hace sobre todo en Mac: muchas herramientas no están optimizadas para mi configuración local. Así, hay detallitos qué arreglar, como las recargas dinámicas (LiveReload) que no funcionan adecuadamente.
  • Mejorar la forma de contacto. Tanto en su diseño, para mejorar las conversiones, como en su back-end, donde estoy usando un script que no me da los mejores resultados.
  • Mejorar el portafolio. Por alguna razón tuve problemas con la compilación del archivo. También mejoraré la experiencia de usuario en general.
  • Introducir secciones nuevas (de las cuales no adelanto nada :D)
  • Integrar gráficamente este blog al resto del sitio.

Así pues, el proceso continúa, pues el aprendizaje no puede detenerse.

Tanto que hacer y tan poco tiempo.

Me atoré de nuevo.

Tener demasiados intereses conduce a tener demasiados proyectos. Además, soy de esas personas que se entusiasman más al iniciar algo que al continuarlo o terminarlo.

Con el paso de los años he aprendido a administrarme a mí mismo. Menos proyectos, más administración. Todo funciona hasta cierto punto y luego, se cae y hay que rehacerlo cuando el ambiente cambia.

Lo que esto significa para mi sitio y mi blog es que han pasado casi dos meses de (re)hacer el compromiso de actualizarlos semanalmente. No he hecho esto. Otros proyectos han capturado algo de ese tiempo.

Lo cual está bien para algunos proyectos, pero no para otros. Especialmente lo que tiene que ver con aprendizaje: la frecuencia y la densidad son importantes.

Así que decidí tal vez rehacer el sitio de nuevo. Y otra vez. Y otra. Tal vez así es como debe hacerse. Desde An Event Apart Austin (que estuvo muy chilo por cierto) he querido experimentar con varias cosas y tecnologías nuevas, como explorar el potencial de los SVGs. Tampoco me satisface para nada mi configuración de build actual, y quiero explorar herramientas como Grunt Gulp.

Y pues eso es. Hoy es un día libre, un día que – gracias a las circunstancias – puedo tomar para mí. Tengo proyectos para hoy (quiero hacer un buen pozole, limpiar un poco…), pero, sobre todo, estos días me permiten darme cuenta de qué puedo hacer mejor en adelante.

¿Qué hay de ti? ¿Te has atorado alguna vez en tu progreso personal? ¿Qué haces para mantenerte en el buen camino? Si te late, cuéntame en @sgenius. Me encantaría saber lo que tienes que decir.