Alguien abre tu build por primera vez. El personaje aparece frente a un pedestal y una puerta cerrada. La persona camina hacia la puerta, prueba un botón y vuelve al punto de partida. Entonces pregunta: «¿Qué tengo que hacer?».
Tú sabes que debe recoger el cristal y usarlo para abrir la puerta. Llevas días trabajando con esa regla. Para quien acaba de entrar, la relación entre esos elementos todavía está por descubrir.
Esa diferencia es un buen punto de partida para evaluar la UX en videojuegos: observar qué información tiene realmente el jugador cuando intenta actuar. En este artículo voy a recorrer siete decisiones que revisaría durante la primera experiencia y una forma de probarlas sin convertir al desarrollador en el tutorial.
Esta revisión aborda el onboarding dentro de la primera experiencia del jugador, o FTUX (First-Time User Experience).
Los 60 segundos son una ventana de observación. Un juego de exploración puede necesitar un ritmo distinto al de uno de acción. Aquí nos sirven para acotar la revisión: cómo empieza alguien a jugar, qué entiende de la respuesta y qué encuentra que le interese hacer después.
1. Qué observar durante el primer minuto
Antes de añadir instrucciones, comprobaría si el jugador puede reconocer una primera acción relacionada con el objetivo. Después miraría qué hace con la respuesta que recibe.
En Faro, el prototipo ilustrativo de mi charla, esto significa acercarse al cristal, recogerlo y reconocer que ahora puede usarlo en la puerta. El ejemplo permite seguir la misma mecánica mientras cambiamos las señales que la acompañan.
Me interesa registrar el recorrido, incluidas las dudas. ¿Se acerca a un objeto que parece interactivo pero no lo es? ¿Prueba distintas teclas? ¿Recoge el cristal y sigue buscándolo porque no percibió el cambio?
Una pausa, por sí sola, no demuestra confusión. Puede estar mirando el escenario o decidiendo qué explorar. Conviene observar qué ocurre después y preguntarle qué esperaba, en lugar de interpretar cada segundo sin movimiento como un fallo.
Completar el tutorial tampoco demuestra comprensión. Una persona puede seguir una flecha y pulsar el botón indicado sin entender para qué sirve la acción. Una comprobación más útil es observar si aplica la misma regla en una situación equivalente cuando la indicación ya no está.
Y queda una pregunta adicional: ¿qué le ofrece el juego después de esa primera acción? Abrir una puerta puede comunicar progreso y revelar algo que quiera explorar. Un inicio comprensible todavía necesita poner al alcance una parte interesante de la experiencia. Eso también hay que probarlo.
2. Siete decisiones que ayudan a empezar
Estas preguntas sirven para localizar problemas. El ajuste depende del género, del dispositivo y de la incertidumbre que quieras conservar como parte del juego.
Objetivo: ¿qué intento conseguir ahora?
Qué observar. El jugador recorre el escenario o interactúa con objetos sin encontrar una acción que le permita avanzar.
Por qué puede generar confusión. La premisa del juego está clara para el equipo, pero la primera tarea depende de información que solo aparece en la descripción de la página o en una explicación externa.
Qué cambiaría. Conectaría una acción concreta con su consecuencia. En Faro: «Recoge el cristal para abrir la puerta». Según la experiencia, esa relación también puede aparecer en la forma del receptáculo, la composición del escenario o una reacción del mundo.
Cómo lo comprobaría. Observaría qué intenta primero alguien que no conoce la build y qué pista utiliza. Si descubrir la relación es parte del puzzle, comprobaría que puede experimentar y aprender de la respuesta sin que yo le revele la solución.
Controles: ¿cómo puedo ejecutar esa acción?
Qué observar. La persona encuentra el objeto correcto, pero prueba botones o busca fuera del juego cómo usarlo.
Por qué puede generar confusión. Reconocer un objeto interactivo no explica necesariamente el input. Una tecla mostrada para otro dispositivo añade otra duda.
Qué cambiaría. Mostraría botón y verbo cerca de la interacción: «E · Recoger cristal». El prompt aparecería cuando la acción esté disponible. También dejaría una forma de consultar los controles y revisaría el recorrido de abrir un menú, navegarlo y volver al juego.
Cómo lo comprobaría. Probaría cada dispositivo anunciado en la build real, incluyendo la salida de los menús. En plataformas como UEFN, comprobaría qué señales admite cada superficie antes de dar por implementable un comportamiento del diseño.
Feedback: ¿qué acaba de pasar?
Qué observar. El jugador pulsa varias veces, revisa el inventario o intenta recoger de nuevo un objeto que ya obtuvo.
Por qué puede generar confusión. Puede haber recibido una animación sin reconocer el cambio de estado. También puede existir un fallo técnico o una demora. La repetición del input no basta para elegir una explicación.
Qué cambiaría. Haría reconocible el resultado. En Faro, el cristal desaparece, el contador pasa de 0/1 a 1/1 y el objetivo se actualiza. Si una acción tarda, distinguiría que el juego recibió el input de que ya completó la acción.
Cómo lo comprobaría. Miraría si reconoce el nuevo estado y actúa en consecuencia. También reduciría los efectos para comprobar que la información sigue disponible. Desarrollo esta distinción en mi nota sobre feedback y confirmación de acciones.
Jerarquía visual: ¿qué es lo importante aquí?
Qué observar. Una oferta, una notificación o un indicador secundario captura la atención mientras la tarea actual pasa desapercibida.
Por qué puede generar confusión. Las señales compiten sin una prioridad relacionada con lo que el jugador necesita decidir en ese momento.
Qué cambiaría. Revisaría qué información sostiene la primera acción y qué puede aparecer después o consultarse a demanda. En Faro, la tienda y la racha pueden esperar. En otro juego, un mapa o un recurso pueden ser imprescindibles desde el inicio.
Cómo lo comprobaría. Observaría si encuentra la información que necesita mientras juega, también bajo presión. No retiraría un elemento solo porque la captura se ve más limpia. Esa diferencia es el centro de mi análisis sobre claridad del HUD.
Aprendizaje: ¿qué regla necesito en este momento?
Qué observar. La persona cierra una pantalla de instrucciones y, al llegar al objeto, ya no recuerda cómo interactuar.
Por qué puede generar confusión. La explicación llegó antes de que hubiera una oportunidad de usarla, o presentó demasiadas reglas juntas.
Qué cambiaría. Daría contexto y una oportunidad segura de practicar cada regla nueva. En Faro, la secuencia es moverse, recoger y usar. Mantendría ayuda consultable para quien la necesite y una salida adecuada para quien ya conoce los controles.
Cómo lo comprobaría. Después de la primera práctica, observaría una situación equivalente con menos ayuda. Si la persona solo avanza mientras la instrucción le dicta cada paso, todavía falta comprobar qué aprendió.
Recuperación: ¿qué pasó y cómo vuelvo a intentar?
Qué observar. La puerta no abre y el jugador repite la acción, abandona la zona o supone que encontró un bug.
Por qué puede generar confusión. «No disponible» no distingue entre falta de un recurso, estar fuera de rango o un fallo del juego.
Qué cambiaría. Comunicaría la condición que falta y una salida útil. En Faro: «Falta un cristal. Recógelo en el pedestal». Si descubrir esa condición es el reto, graduaría la ayuda para conservar la posibilidad de resolverlo. También revisaría cómo reintentar después de fallar.
Cómo lo comprobaría. Probaría deliberadamente una acción sin cumplir sus requisitos y observaría si la persona puede continuar. Un recorrido que solo prueba los casos de éxito deja estas situaciones fuera de la revisión.
Accesibilidad: ¿puedo percibir y ejecutar lo esencial?
Qué observar. Una señal deja de funcionar sin audio, un estado solo se diferencia por color o una acción resulta difícil de ejecutar con los controles disponibles.
Por qué puede generar confusión o exclusión. El diseño depende de una capacidad, un dispositivo o unas condiciones que no todos comparten.
Qué cambiaría. Ofrecería alternativas para las señales esenciales, revisaría la legibilidad a la escala final y el control sobre efectos e inputs. Por ejemplo, combinar color con forma y texto, o proporcionar alternativas a mantener o pulsar repetidamente un botón cuando corresponda.
Cómo lo comprobaría. Haría revisiones con el audio desactivado, distintos dispositivos y la pantalla de destino. Una simulación sin color ayuda a detectar dependencias, pero no sustituye pruebas con personas con distintas necesidades. Las Xbox Accessibility Guidelines permiten profundizar en estas barreras.
3. Un ejemplo real: Slow Mode en Steal an Egg
En la adaptación de Steal an Egg de Roblox a Fortnite/UEFN, trabajé en UX/UI y su implementación. La transición de táctil a consola y PC obligaba a reconsiderar dónde vivían las acciones y cuántos pasos necesitaba cada una.
Uno de los problemas aparecía al comprar mucha velocidad: cruzar el mapa era rápido, pero recorrer las tiendas físicas se volvía difícil. Slow Mode permitía desplazarse más despacio.
El cambio de contexto
En Roblox, el ajuste estaba disponible como un interruptor en el HUD. En nuestra versión de Fortnite pasó a Settings. La función seguía existiendo, pero acceder a ella requería navegar por un menú.
En los playtests internos observamos un patrón: lo activaban dentro de la safe zone, donde estaban las tiendas, y lo desactivaban al salir para recuperar velocidad. El recorrido podía requerir unas ocho pulsaciones para cambiar el ajuste, y había que repetirlo en la siguiente transición.
Es una observación de esas pruebas internas. No es un tiempo promedio ni un dato sobre toda la población de jugadores.
La decisión
Añadimos un tercer estado junto a Off y On: Safe zone only. El jugador puede elegir que el juego aplique Slow Mode en la zona correspondiente y recupere la velocidad fuera de ella.
Captura del gameplay incluido en la presentación: Slow Mode ofrece tres estados y explica el comportamiento de «Safe zone only».
Qué resultado puedo mostrar
La interfaz implementada y el clip público de Settings permiten comprobar que existe la tercera opción y cómo se comunica. La regla de diseño evita pedir un cambio manual en cada transición cuando el jugador elige ese modo. Para verificar su ejecución hay que comprobar ambos límites de zona, además de los estados On y Off.
No medimos una mejora de retención ni una reducción porcentual de errores. El caso documenta una conducta observada en pruebas internas y la respuesta de diseño que implementamos.
Además, este problema aparecía después de progresar, no necesariamente durante los primeros 60 segundos. Lo incluyo porque muestra un límite de esa primera revisión: una experiencia que funciona al comenzar puede introducir fricción cuando cambian las capacidades del personaje. El primer minuto es el inicio de la evaluación.
4. Cómo hacer un playtest del primer minuto sin explicar el juego
Busca a alguien que no conozca la build y tenga un perfil relevante para la experiencia. Si evalúas un juego para personas familiarizadas con Fortnite, registra esa familiaridad. Si buscas llegar a principiantes, incluye a principiantes.
Para observar el descubrimiento inicial, una consigna puede ser:
«Abre el juego y empieza como lo harías normalmente. Estamos revisando la build. Si te quedas detenido, puedes decirlo o parar cuando quieras».
Evitaría empezar con «recoge el cristal y abre la puerta» si quiero comprobar si el juego comunica precisamente ese objetivo. Para evaluar otra tarea, sí puedo dar un objetivo concreto, cuidando que la consigna no revele el recorrido que quiero observar.
Un formato ligero de diez minutos
| Tiempo | Qué hacer |
|---|---|
| 1 minuto | Explicar la sesión y acordar cualquier registro de pantalla o audio. |
| 1 minuto | Dejar que abra la build y explore sin anticipar la solución. |
| 4 minutos | Observar el juego y registrar acciones, bloqueos y ayudas. |
| 2 minutos | Preguntar qué esperaba que ocurriera y dónde dudó. |
| 2 minutos | Elegir un cambio y definir cómo volver a probarlo. |
Durante la entrada mantendría las manos lejos del teclado. En una interacción rápida, dejaría las preguntas para después. En tareas que lo permitan, pedir pensar en voz alta puede aportar contexto, teniendo presente que la conversación también puede influir en la conducta.
Intervendría si la persona lo pide, muestra malestar o un problema técnico impide continuar. Si hace falta ayudar para revisar una parte posterior, registraría cuándo y qué información le di. A partir de ahí ya conoce una pista que la build no le había comunicado por sí sola.
Una ayuda es algo que investigar. Puede revelar una barrera de interfaz, una instrucción inadecuada o una necesidad de apoyo. El contexto decide qué significa.
Observación e interpretación
Esta tabla es hipotética, no recoge resultados de Steal an Egg:
| Observación | Hipótesis | Cambio que probaría |
|---|---|---|
| Pulsó la tecla de interacción tres veces después de recoger el objeto. | La confirmación pasó desapercibida. | Mostrar el nuevo estado cerca de la interacción y observar otro primer intento. |
| Llegó a la puerta sin el cristal y volvió a pulsar varias veces. | La condición para abrirla era poco clara. | Comunicar el requisito que falta y comprobar qué hace después. |
«No entendió» comprime demasiado. Registrar la conducta y preguntar qué esperaba ayuda a precisar el problema antes de elegir la solución.
Si quiero volver a comprobar descubrimiento, buscaría otra persona que no haya visto la versión anterior. Quien ya la probó puede recordar la regla, aunque la señal siga siendo débil. Una prueba breve permite encontrar problemas posibles; no demuestra por sí sola una mejora de retención.
5. Qué corregir primero
Con poco tiempo, empezaría por lo que impide jugar: un menú del que no se puede salir, una acción esencial que no se puede ejecutar o una instrucción que resulta ilegible en el dispositivo anunciado.
Después revisaría las dudas que aparecen repetidamente: no reconocer el objetivo, insistir en una acción ya completada o perder el siguiente paso. La recurrencia es una pista para investigar, no una explicación automática de la causa.
Dejaría para después una animación adicional de celebración si el jugador todavía no reconoce que obtuvo la recompensa. Primero comprobaría que el estado se comunica. Luego evaluaría cómo reforzar la sensación de recibirla.
Antes de integrar cada cambio, reservaría tiempo para probarlo en la build de entrega. Una corrección también puede alterar otro input, tapar información o dejar de funcionar en gamepad.
Checklist y recursos
Durante el primer minuto, comprueba si el jugador:
- ◆Reconoce una acción inicial relacionada con el objetivo.
- ◆Encuentra el input y puede ejecutarlo.
- ◆Reconoce el resultado y el cambio de estado.
- ◆Encuentra la información importante para ese momento.
- ◆Puede practicar la regla nueva y aplicarla después.
- ◆Entiende cómo continuar o reintentar ante un bloqueo.
- ◆Puede percibir y operar lo esencial con alternativas pertinentes.
Registra qué ocurrió y qué ayuda hizo falta. Marca «no aplica» cuando corresponda. Evitaría convertir la lista en una puntuación de aprobado: una sola barrera puede impedir llegar al resto del juego.
Puedes descargar el checklist en PDF, usar la versión web o consultar la presentación «60 segundos para que quieran seguir jugando».
Para profundizar en las restricciones de plataforma, dejé una nota sobre diseño de UX dentro de Fortnite/UEFN.
Antes de tu próximo playtest, anota una cosa que hoy solo se entiende porque tú la explicas. Observa qué ocurre cuando otra persona intenta jugar sin esa explicación.
Referencias para ampliar la revisión
- ◆Thinking Aloud: The #1 Usability Tool, Nielsen Norman Group. Introducción al método y a los efectos de las intervenciones del facilitador.
- ◆XAG 103: Additional channels for visual and audio cues, Microsoft. Alternativas para comunicar señales importantes.
- ◆XAG 107: Input, Microsoft. Barreras de entrada que van más allá del remapeo.