Abrir el problema
Investigación de escritorio sobre el público de e-Sports, el perfil del huésped actual y qué hacen ya otros operadores de hospitalidad en el espacio.
Trabajo / Prueba técnica
The Palace Company · Prueba técnica
Doce horas para decidir si un negocio nuevo tenía sentido
Palace Resorts evaluaba una experiencia de e-Sports dentro de sus propiedades. El encargo no era diseñar pantallas bonitas: era llegar de un enunciado ambiguo a un concepto que alguien pudiera aprobar o rechazar con argumentos, y hacerlo antes de que se acabara el reloj.
12:00horas totales, de principio a entrega
Reto y restricción
Evaluar la viabilidad de un desarrollo de nicho —el e-Sports Experience— para un operador hotelero cuyo público habitual no es el jugador competitivo. La pregunta real era si existía un usuario, no si se podía construir.
Restricción: doce horas. Eso convierte la priorización en la habilidad evaluada, no un detalle del proceso.
Método
Doble diamante. Lo elegí precisamente porque obliga a abrir antes de cerrar dos veces, y con el reloj corriendo la tentación es saltar directo a la solución. Las dos aperturas son el seguro contra diseñar lo primero que se te ocurre.
Mi participación
Todo el ejercicio, en solitario. Investigación de escritorio, definición del problema, ideación, concepto, UI kit y presentación. Sin equipo y sin acceso a usuarios, que es parte de la restricción.
Entregables
Definición del problema y del usuario, propuesta de concepto, pantallas clave y un UI kit con los componentes necesarios para construirlas. Todo en Figma.
Qué demuestra
Cómo trabajo cuando no hay tiempo para el proceso completo: qué recorto, qué defiendo y cómo dejo por escrito lo que quedó fuera para que la siguiente persona no tenga que adivinar.
Proceso
Cuatro fases, dos aperturas
El doble diamante existe para evitar dos errores opuestos: enamorarse del primer problema y enamorarse de la primera solución.
Cerrar en una apuesta
De todo lo encontrado, una sola definición de usuario y una sola pregunta a resolver. Sin esto, las siguientes ocho horas se dispersan.
Abrir soluciones
Exploración rápida de conceptos y estructuras posibles. Bocetos baratos, descartes rápidos, sin comprometerse con ninguno todavía.
Cerrar en algo construible
Pantallas clave, UI kit con componentes reutilizables y el argumento de por qué esta propuesta y no las otras.
Cómo administré las doce horas
Reparto aproximado. Lo importante no son los minutos exactos, sino que la mitad del tiempo se fue en entender y decidir, no en dibujar.
Descubrir: investigación de escritorio y referentes
Definir: usuario, problema y criterio de éxito
Desarrollar: bocetos y exploración de conceptos
Entregar: pantallas clave en alta fidelidad
UI kit: componentes, estados y tokens
Armado de la presentación y el argumento
Descubrir y definir
La pregunta no era cómo, era para quién
Un resort de playa y una audiencia de e-Sports no se solapan solas. El riesgo del proyecto no estaba en la tecnología sino en la premisa: si el huésped que ya viene no juega, y el jugador que juega no viene, la experiencia no tiene a quién servir.
Así que las primeras horas se fueron en delimitar un usuario real en lugar de asumirlo. De ahí salió la definición del problema que sostuvo todo lo demás.
Mapa de referentes
y hallazgos de escritorio
y hallazgos de escritorio
Definición de usuario
y enunciado del problema
y enunciado del problema
Desarrollar
Conceptos baratos antes que pantallas caras
Boceto rápido para explorar varias direcciones y descartar sin costo. Con doce horas encima, cada hora invertida en alta fidelidad temprana es una hora que no puedes recuperar si el concepto estaba mal.
Bocetos de
exploración
exploración
Estructura
de navegación
de navegación
Concepto
seleccionado
seleccionado
Entregar
Un UI kit, no una carpeta de pantallas
La diferencia entre entregar seis pantallas y entregar un UI kit es que lo segundo se puede construir sin volver a preguntarme nada. Componentes con anatomía, estados y tokens, para que las pantallas sean una consecuencia del sistema y no seis archivos sueltos.
UI kit:
componentes base
componentes base
Tokens de color
y tipografía
y tipografía
Estados
e interacción
e interacción
Pantallas finales
del concepto
del concepto
Versión móvil
Alcance
Lo que dejé fuera a propósito
Una prueba de doce horas se evalúa tanto por lo que entregas como por lo que decides no entregar. Estas fueron las omisiones deliberadas, cada una declarada en la presentación en vez de escondida.
- Investigación con usuarios reales. No había acceso ni tiempo. Todo lo que se afirma sobre el usuario está marcado como hipótesis, no como hallazgo.
- Modelo de negocio y costos. Fuera de alcance para un ejercicio de producto, y habría sido inventar cifras.
- Flujos secundarios y estados de error. Prioricé el recorrido principal completo por encima de cubrir todos los casos a medias.
- Validación técnica de la infraestructura. Un concepto de este tipo depende de red y equipo en sitio; lo señalé como el siguiente riesgo a resolver.
Declarar los huecos es parte del entregable. Un concepto que aparenta estar completo cuando no lo está es más peligroso que uno con las lagunas marcadas.
Qué haría distinto
- Poner el reloj a la vista desde la hora cero. Fijé el reparto de tiempo sobre la marcha; con un presupuesto escrito al inicio habría protegido mejor la fase de definición, que es la que siempre se come el diseño.
- Cerrar el concepto con una hoja de una sola página. Usuario, problema, apuesta y criterio de éxito en un solo lugar antes de abrir Figma. Habría acelerado la presentación final.
- Reservar treinta minutos para accesibilidad. Contraste y tamaños táctiles son baratos en el UI kit y carísimos después de construido.