Detrás del botón

Actualización: esta entrada arrancaba originalmente con un tweet, pero parece que su autor lo borró. Básicamente era una discusión sobre diseño que terminaba con una afirmación del estilo “si necesitas 100 horas para poner un botón mal vamos”. Sigamos.

Hace no muchos años, cuando quería hacer una partida rápida sin quedar con amigos a Enemy Territory (un juego exclusivamente multijugador), tenía dos opciones: podía crear una partida vacía o unirme a una ya creada. Lo habitual era echar un vistazo a las creadas y fijarse en:

  • cuántos jugadores había en cada una (más jugadores significa que la partida está en marcha, pero puede que haga rato que ya ha empezado),
  • qué latencia había entre mi ordenador y el servidor (a menor latencia juego más fluido),
  • si se estaban jugando niveles que tenía o no (descargables, a parte del juego básico),
  • etc.

La interfaz para ello debía contribuir a tomar una decisión, facilitando la comparación, ordenación y filtrado.

Una tabla muestra varias columnas con: "Server name", "Map name", "#PLRS", "Type", "Ping", "Filters", "Fav".

Si ninguna partida me convencía, podía optar por crear una nueva (si tenía servidor) y esperar que la gente la viera en la lista y se uniera.

Hoy en día, en la mayoría de juegos no se utiliza este sistema para hacer partidas rápidas. Lo habitual es que esta pantalla de selección se sustituya por un matchmaking, un sistema que elige por nosotros. ¿Cómo? Pues el sistema ya sabe qué niveles tenemos descargados, puede priorizar partidas que estén a punto de empezar, o recientemente empezadas, y escoger siempre la que tenga menor latencia. Incluso puede hacer una valoración de nuestro nivel de juego y meternos en partidas con jugadores similares, para una sesión de juego más ajustada y divertida. Y si no encuentra ninguna partida adecuada puede crear automáticamente una nueva a la espera que otros jugadores utilicen el sistema, pero ni siquiera en este caso es necesario informar explícitamente al usuario de ello, simplemente se le mantiene en espera.

Lo único tangible de todo esto, la interfaz visual que lo representa, acaba siendo un único botón (“Jugar”) y una pantalla invitando al jugador a esperar mientras se busca una partida.

Una pantalla muestra el texto "Finding Opponent" con un botón cancelar

Pero que la interfaz sea sencilla (al menos en su conceptualización visual) no significa que el proceso de diseño sea menos costoso que ofrecer otro tipo de interfaz.

Plantear un matchmaking, incluso asumiéndolo como un patrón conocido que no debemos reinventar, supone investigar el comportamiento de los usuarios, intentando averiguar qué impacto puede tener utilizar este sistema, ya que no en todos los casos ni juegos puede ser la mejor solución. Posteriormente es necesario no sólo pintar un botón en la pantalla, sino también diseñar el proceso que hay “por detrás”: ¿qué es un jugador de nivel similar?, ¿cuántos jugadores “buenos” podemos añadir en una partida sin desbalancear?, ¿qué latencia es aceptable para los jugadores?, ¿vamos a priorizar que el idioma de los participantes sea el mismo?

Todo esto afecta a la experiencia de usuario, de jugador en este caso, y me cuesta referirme a ello con alguna palabra que no sea «diseño».

Publicado por

Dani Armengol

Consultor independiente de arquitectura de información