Las limitaciones como motor de creación: case study de Evadista

Jorge Fuente
5 min readMay 9, 2021

Desde hace varios años he centrado mis pet projects en el desarrollo de juegos. Me permiten crecer como profesional, experimentar con nuevas metodologías y técnicas y, sinceramente, suponen el reto más divertido que un diseñador de producto se puede encontrar.

Pese a que se trataba de proyectos enormemente satisfactorios desde el punto de vista personal, al cabo de unos cuantos lanzamientos me di cuenta de que el enfoque de Mínimo Producto Viable simplemente no funciona a la hora de realizar un juego. Los usuarios tienen unas expectativas muy elevadas con un producto de este tipo, por lo que es necesario realizar una inversión de tiempo y esfuerzo enorme prácticamente a ciegas.

Este hecho me llevó a la reflexión de que mi siguiente proyecto fragmentaría al máximo el esfuerzo, con una entrega de valor constante que generase engagement en los usuarios. Y de ahí surgió Evadista.

Un proyecto basado en limitaciones

Si no conoces Evadista, es una newsletter que lleva incorporado un sistema de juego interno. Esta idea, que he bautizado como gameletter, fue surgiendo poco a poco mientras reflexionaba sobre mis limitaciones:

- Limitaciones en la entrega de valor. Quería generar engagement en base a una entrega de valor regular. Un juego puede generar adopción de dos formas: mediante la emergencia (que el sistema genere circunstancias novedosas) o la progresión (que se realicen avances narrativos). Me decanté por la segunda opción, por ser mucho más cortoplacista y permitirme iterar sobre el producto en cada entrega.

- Limitaciones en el tiempo. No dispongo de demasiado tiempo para realizar cada entrega. Tengo un trabajo a jornada completa y una vida familiar y social, así que no podía permitirme consumir más de 6–8 horas semanales en el proyecto.

- Limitaciones técnicas. Mis propias habilidades técnicas también fueron un condicionante. Me considero técnicamente competente en HTML+CSS, pero en Javascript no produzco más que spaghetti code. Las características de un sistema de mailing me venían como anillo al dedo.

Teniendo en cuenta estas constricciones y el momento de salud que viven actualmente las newsletters me decidí a experimentar con el formato.

La primera versión del mailing se parecía más bien a un serial detectivesco, en el cual se presentaba un caso que debían resolver los usuarios en base a determinadas pistas de la narración. Esta primera versión no siguió adelante porque ofrecía un nivel de jugabilidad muy bajo y la redacción de cada caso ya consumía de por sí todo el tiempo disponible.

La primera versión de Evadista, basada en historias de detectives de los años 40

Precisamente con la finalidad de optimizar el tiempo empleado en la creación de cada entrega decidí reducir el componente narrativo a su mínima expresión y hacer que el propio juego fuese el que contase su historia en cada ocasión. Y el formato de las escape rooms era perfecto para ello.

Las limitaciones técnicas

Desde las primeras versiones del juego me di cuenta de un hecho incontestable: el mailing es, probablemente, el medio digital más restrictivo que existe desde el punto de vista técnico. Las compatibilidades entre navegadores, sistemas operativos y clientes de correo son tan grandes que resultan casi imposibles de trazar -Can I email se convirtió en una de mis webs de referencia-, así que decidí concentrar todo el riesgo en una única regla:

input:checked + table {display: table!important;}

Esta regla regula todo el funcionamiento e interactividad de Evadista, ocultando o mostrando componentes en función de la selección de radio buttons y checkboxes. El resto de estilado y composición de los juegos es totalmente seguro, pero en esta única línea se concentran varios condicionantes que cruzan incompatibilidades con los sistemas de correo.

En primer lugar, se trata de una instrucción que no se puede colocar inline. Requiere la gestión de un header html en el mail, lo que no resulta compatible con varios sistemas de correo.

Y, en segundo lugar, supone el manejo de pseudoclases (:checked) y selectores (+), lo que tampoco es siempre compatible.

Por este motivo, diseñé un sistema de fallbacks que se activaban según una u otra condición fallase. Para aquellos usuarios que no admitían el uso de header creé una “trampa” que mostraba una imagen con CTA, dirigiendo a la versión web del juego. Para comprobar la compatibilidad con los selectores y/o pseudoclases dispuse un test de compatibilidad en el encabezado de cada mail.

Fallback para usuarios que no admiten gestión de html header (como gmail.com)

Las limitaciones prácticas

Otra limitación con la que tuve que lidiar fue con la del tiempo disponible para cada juego. Inicialmente con una periodicidad semanal, pronto tuve que resignarme a producir un juego cada dos semanas.

Para poder mantener este ritmo, sistematicé completamente la creación de cada entrega.

Por un lado, creé una plantilla de diagramas de dependencias, que regulaba el número de objetos y puzzles incorporados dentro de cada juego. La estandarización de contenidos me permite acortar los plazos de diseño y mantener una longitud constante del tiempo de juego.

Diagrama de dependencias de Evadista #006

Por otro lado, generé un sistema de componentes html con distintas funcionalidades: desde mostrar mensajes a desencadenar acciones en otro punto del juego o plantear las distintas respuestas a un puzzle. En este punto, resulta relevante que, al estar basado en un sistema de selección de inputs, la relación entre acción y reacción siempre es 1:1. Es decir, que cuando pulsas un botón o interactúas con el escenario solamente puedes modificar el estado de un componente. Esta limitación impone serias restricciones en la manifestación de feedback de acciones, pero los usuarios se han mostrado sorprendente adaptables a esta circunstancia.

Finalmente, generé una plantilla de montaje en GIMP, en la que coloco los distintos elementos del escenario sobre una retícula de interacción de 8x8 módulos. Resulta curioso que, en un proyecto de este tipo, mi mayor inversión en tiempo y esfuerzo es la selección y procesamiento de las imágenes que componen los escenarios.

Conclusiones

Evadista no es un pelotazo. No ha escalado agresivamente en número de subscriptores ni se ha viralizado. Llevamos dos meses y hemos progresado desde los 118 receptores de la primera entrega a los 162 de la séptima, todo en base a crecimiento orgánico. La tasa de apertura se mantiene en torno al 50%-60% semana tras semana.

Pero, pese a estas cifras tan modestas, creo que está siendo un éxito porque está generando engagement. Me consta que abrir Evadista los domingos se ha convertido en un hábito para mis usuarios. Uno de ellos incluso hace sesiones de streaming resolviendo el juego en su canal de Twitch por cada entrega. Y esa era mi visión cuando creé el proyecto, la de un pasatiempo tranquilo para las mañanas de domingo.

--

--