Normalización de estilos y diseño de sistemas en Ticketbis.

Mantener un diseño, y por tanto, una experiencia de uso consistente en una compañía de la envergadura de Ticketbis puede ser complicado. En este documento vamos a analizar posibles puntos de mejora y la metodología a seguir para cumplir ese objetivo.

Usar una metodología de diseño modular, de sistemas, o “atómico” (diferentes nombres para algo que en lo elemental viene a ser lo mismo), puede resultar muy útil tanto a la hora de ser replicado como a la hora de ser transmitido a través de los diferentes equipos.

1.- Análisis del UI actual de Ticketbis:

El crecimiento rápido del producto, la organización por células sin una comunicación sólida entre ellas al respecto, o la falta de una guía clara, pueden ser el motivo de que a lo largo de toda la plataforma nos encontremos con casos de incoherencia visual, inconsistencias dentro de un proceso o en interacciones similares en diferentes procesos, o falta de jerarquía.

A pesar de estar todos muy relacionados, hemos intentado hacer una categorización por tipos de elementos para poder afrontar un rediseño de manera más o menos ordenada:

• Estilos tipográficos: en una misma página conviven demasiados tipos de letra, tamaños, negritas… incluso a veces se usa una tipografía que no es la Open Sans, nuestra tipografía corporativa. Esto hace que no exista una una jerarquía clara, lo que provoca que la lectura sea más difícil.

En una misma página conviven multiples estilos que dificultan hacer foco en lo realmente importante

• Botones: Los call to action no están jerarquizados y no siguen una lógica clara, ni de posición, ni de color, ni de forma, ni de mensaje.

En la misma pantalla del proceso de compra nos encontramos con el botón “Pagar” en dos formatos distintos, de diferente color y tamaño.

• Color: el uso del color suele ser arbitrario y pocas veces se usa con intención informativa. No se tiene en cuenta el significado de colores como el rojo o el magenta, asociados normalmente a errores o a estados de “urgencia”. En este caso es especialmente problemático, ya que cualquier mensaje de error que quisiéramos dar, se confundiría o quedaría neutralizado por el resto de elementos.

Los botones de “Información” y “Te llamamos” así como la masa roja del mapa hacen que cualquier mensaje de error se confunda o pase desapercibido.

• Forma: no contamos con una lógica a la hora de crear nuevos elementos o de dotar de unidad a los ya existentes. En algunas ocasiones el affordance de los elementos es nulo.

Affordance según Don Norman, son las posibilidades de interacción que son inmediatamente percibidas por el usuario, dicho de otra manera, es la cualidad que tiene un objeto para transmitir la manera en la que se usa. Por ejemplo, un guante o una regadera, debido a su forma, te indican claramente para qué sirven y cómo tienes que usarlos. El affordance de un elemento en una interfaz nos ayuda a anticiparnos a su acción, por lo que no solo facilita el uso de la misma, sino que reduce también la incertidumbre.

Los botones de requerimientos funcionan como checkbox, pero ¿quién lo diría sin probar cómo funcionan?

La “pestaña” de “Grupos y empresas” no funciona como tal, si no que es un botón que te lleva a otra página

• Iconografía: no existe un sistema definido, una jerarquía, ni una consistencia visual en sus formas y sus usos.

Solo en la home podemos ver 3 estilos iconográficos diferentes

Se usan iconos hechos para funcionar a tamaños pequeños casi como estilo ilustrativo

• Estilo fotográfico: al no estar definido el estilo, no existe una coherencia entre el tipo de imágenes que se usan. Muchas veces no existe una intencionalidad detrás de su uso, por ejemplo, si mostramos un espectáculo, ¿queremos dar una visión general, más fría, o en cambio queremos acercarnos todo lo posible, buscar un plano corto que nos hable de la experiencia que el usuario va a poder vivir gracias a Ticketbis?. Es importante tener en cuenta que no solo comunicamos con lo que decimos, también con el tipo de imagen que mostramos.

No existe un tratamiento común entre las imágenes que usamos en nuestros destacados

¿Estamos seguros de que este es nuestro target?

• Tono: no existe un tono definido, ni de voz ni visual. Esto hace que ni en el site, ni en la comunicación más funcional como el mail o en nuestra comunicación promocional seamos consistentes. No creamos marca. Tenemos que ser capaces de dotar a Ticketbis de una voz propia.

En algunos casos, de un vistazo rápido es imposible identificar a Ticketbis en nuestras comunicaciones.

Más allá del logo, no hay uniformidad entre nuestro producto y los mails que enviamos. ¿Cómo repercute esto en la imagen que tienen nuestros usuarios de nosotros?

• Inconsistencias entre dispositivos: la experiencia en desktop/móvil, aún contando con las peculiaridades de cada uno, es dispar.

Elementos como la cabecera, el botón de buscar o de vender, cambian de manera arbitraria en cada dispositivo.

2.- Creación de un sistema y aplicación del mismo a lo largo de todo el producto:

Existen varios modelos diferentes, aunque el que posiblemente más se ha popularizado ha sido el de Brad Frost, en el que se distingue entre 5 diferentes estratos: átomos, moléculas,organismos, plantillas y páginas.

Atomic Design según Brad Frost

Hay otros modelos que se ajustan más a nuestras necesidades, como por ejemplo el que propone Joey Di Nardo, en el que se evidencia que cada unos de estos estratos puede funcionar tanto como continente como contenido, y en el que, manteniendo la “metáfora bioquímica”, se tiene en cuenta también la convivencia de unos elementos con otros:

Aquí puedes ver más información sobre los ajustes de Di Nardo a la metodología “atómica” de Frost

Los beneficios de aplicar esta metodología son:

• Nos proporciona consistencia en la interfaz de usuario, en la experiencia y en las funcionalidades, con los beneficios que ya todos conocemos
• Ofrece flexibilidad y eficiencia, porque diseñando desde el nivel “elementos” en lugar de hacerlo desde el nivel “página” creamos un diseño modular y escalable.
• Este diseño modular y escalable es mucho más fácil de aplicar sobre diferentes dispositivos y de hacerlo crecer y decrecer según nuestras necesidades.
• Con el tiempo acaba siendo predecible, lo que hace que de cara al usuario sea más fácil de usar, pero también más fácil de desarrollar de cara al equipo de Ticketbis, reduciendo así tiempos de producción.
• Centrándonos puramente en lo visual, si logramos hacer un site más armónico será más bello y por lo tanto más usable.
• En definitiva, ahorra tiempo y dinero y al ser más usable, mejora la conversión.

3.- Primeros pasos:

Como estamos continuamente creando nuevos flujos y elementos, resulta imposible hacer un parón para hacer un rediseño que normalice todos estos elementos. Por lo tanto, en paralelo hemos ido creando ciertos elementos que en un futuro cercano nos permitirán llegar a ese primer punto que es la consistencia visual de todo el site. Algunos de estos elementos son:

• Hoja de estilos. En la que queden reflejados los elementos básicos de nuestra UI, colores, estilos tipográficos y otros elementos básicos.

“Craft” de Invision nos permite crear hojas de estilo de forma rápida y cómoda

• Interacciones sencillas. Elementos como los botones, los formularios, los listados e incluso las fichas de evento deben mantenerse consistentes a lo largo de todo el producto y entre si.

• Dotar de affordance a los elementos más complejos del sistema. Algo que nos ayuda a esto es mantener una clara relación entre el sistema y el mundo real.

Diferentes vistas de las tarjetas en el proceso de selección de eticket vendido

• Empezar a definir nuestro “Ecosistema”. Definir estilos en elementos como formularios e iconos, uso del color, en procesos complejos, para ver como conviven.

Página de “Dirección” dentro del proceso de Checkout

• Normalización del sistema de mailing. Establecer una serie de elementos comunes y articularlos en función de nuestras necesidades, manteniendo una coherencia visual y de tono entre nuestro sistema de mailing y el producto.

“Venta” y “Recordatorio de Envío”

4.- Siguientes pasos:

Una vez alcanzado un primer estadio dónde todos los estilos de todos los elementos estén normalizados y hayamos eliminado todas las inconsistencias visuales del site, lo lógico sería desarrollar el sistema que ya hemos empezado a crear.

Empezando por redefinir la unidad mínima:

Investigación de una posible evolución de la tarjeta de evento en desktop

Pasando luego a investigar cómo ese elemento crece…

El destacado de la home podría ser un ejemplo de tarjeta a gran escala, con la misma información y las mismas funcionalidades, no un mero elemento “decorativo”

Y cómo decrece…

Los listados no dejan de ser consecuciones de tarjetas con información similar, y en algunos casos funcionalidades similares

O cómo se comportan durante los diferentes procesos, como el checkout, la publicación, la ordenación e incluso las comunicaciones con el usuario:

Dependiendo de la información que tengamos que contar al usuario los módulos cambian de contenido, o se añaden nuevos

Hasta crear un sistema de fácil implementación, aprovechando las ventajas del uso de tarjetas, intuitivo y que cubra todas nuestras necesidades:

Con pocos elementos modulares cubrimos casi todas las necesidades, algunos incluso podrían ser implementados en el back

Y que de forma rápida tenga un impacto sobre la experiencia de uso en Ticketbis:

De forma transversal en todas las plataformas:

Para finalizar debemos recordar que el sistema que creamos, siguiendo con la metáfora bioquímica, está vivo, y que nos debe servir de guía, pero también se tiene que poder ir modificando según las necesidades de cada momento: los datos aportados por la investigación con usuarios, los datos de conversión, etc, y que por lo tanto no es algo inmutable.

Gracias por tu tiempo,

el equipo de Ticketbis.