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, he 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.
- 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.
- 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.
- 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.
- Iconografía: no existe un sistema definido, una jerarquía, ni una consistencia visual en sus formas y sus usos.
- 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.
- 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.
- Inconsistencias entre dispositivos: la experiencia en desktop/móvil, aún contando con las peculiaridades de cada uno, es dispar.
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.
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:
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.
- 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.
- Empezar a definir nuestro “Ecosistema”. Definir estilos en elementos como formularios e iconos, uso del color, en procesos complejos, para ver como conviven.
- 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.
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:
Pasando luego a investigar cómo ese elemento crece…
Y cómo decrece…
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:
Hasta crear un sistema de fácil implementación, aprovechando las ventajas del uso de tarjetas, intuitivo y que cubra todas nuestras necesidades:
Y que de forma rápida tenga un impacto sobre la experiencia de uso en Ticketbis:
De forma transversal en todas las plataformas:
Como conclusión, 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,
y un especial agradecimiento a Daniel de la Rica por su ayuda y su valioso feedback cuando este texto era solo un borrador del proyecto que estábamos llevando entre manos.
Este artículo fue escrito como presentación del proyecto de diseño de sistemas, normalización de estilos y definición de marca que se pretendía implantar desde el departamento de ux. Después de la compra por parte de Stubhub es probable que este proyecto nunca vea la luz.
Originally published at medium.com on May 10, 2016.