UI Kit & Design System

La investigación, el proceso y el desarrollo para idear y crear un UI Kit y Design System abierto, sólido, simple de usar y mantener, iterable y, por sobre todo, con la elaboración y participación de todos.

PedidosYa UI Kit

Esto provocaba una inconsistencia total y global, y una no efectivización del tiempo, tanto para afuera (usuarios) como para adentro (developers, QA, users testings). Digamos que desde la experiencia del usuario, uno podía visualizar un mismo elemento en una pantalla, y, en la siguiente, este elemento era distinto pero cumplía la misma función. Además se complejizaba y alargaba el trabajo con los developers y los tiempos de esfuerzo (el diseñador creaba todo desde cero o copiaba y pegaba componentes que él mismo ya había diseñado pero sin saber si otro diseñador ya lo había realizado, o si ya estaba componentizado). No había consistencia ni desde la perspectiva del usuario, ni de la visual, ni de la marca. Tampoco había forma de mantenerse actualizados entre los equipos y bajo los mismas reglas y contexto. Nada estaba bien.

Es por esto que decidí dedicarme a liderar el proyecto del diseño y desarrollo del “PedidosYa UI Kit y Design System”. Un proyecto bastante ambicioso pero apasionante. Mi idea era que los diseñadores diseñaran con libertad pero dentro un sistema común y para todos, y siempre bajo el mismo manto de consistencia y adaptabilidad, y que si surge una actuación, todos estuviéramos ‘en la misma página’.

Como Head of Design comencé teniendo un panorama general y holístico de toda la compañía y sus distintos departamentos, fui organizando objetivos cross-transactional globales y luego fui focalizándome en objetivos o problemáticas causados por sector. En Producto, además de puntualizar algunos temas a mejorar para ir aceitando el modo de trabajar entre diseñadores, squads y tribus, encontré que cada diseñador trabajaba con su/s propio/s archivo/s (de Sketch) creando cada elemento o símbolo de cero en cada nueva iteración, pantalla o user flow como prototipo.

Usando el UI Kit

Luego de definido, desarrollado y creado cada símbolo y componente para la librería UI Kit, se guardó el archivo madre de Sketch en un servidor sin acceso de edición salvo para ciertas personas clave que son los responsables de mantener y actualizar. Cada diseñador, en cada nueva creación, debe linkear esa librería para tener todo actualizado e importar los símbolos, componentes y pantallas necesarias para poder focalizarse en su tarea con todo lo necesario, actualizado y componentizado.

Creamos instancias formales semanales con todos los diseñadores para ir iterando nuevas necesidades que surgieran, nuevas problemáticas, cambios, renovaciones y/o eliminaciones de símbolos que quedaban deprecados. Entre todos se evalúan y se acuerdan los pasos a seguir y se efectiviza a través de las personas clave asignadas (estas editan el archivo fuente y se sincroniza con todos los archivos). Cuando esta necesidad surge de carácter urgente, el diseñador pide para hacer un ‘chapter express’ (así le llamamos a estas reuniones inesperadas y de momento) donde se juntan los que puden en el momento para solucionar esto y no trancar el trabajo del diseñador. Luego, en la reunión formal, se retoma y actualiza a todos lo decidido para ver si debe ser reevaluado.

Design QA

Quería que los trabajos finales de los diseñadores fueran fieles a lo que se iba a lanzar. Soy bastante estricto para respetar desde el job to be done y la experiencia de usuario hasta el pixel perfecto por lo que, además de aceitar una metodología de, llamémosle ‘pairing-programming-designing’ (los diseñadores trabajaban mano a mano con los desarrolladores), y viendo detalles a cambiar, mejorar e iterar, creamos la instancia de Design QA (quality assurance).

Una de las cosas que implementamos fue que, al llegar a la instancia de testeo inicial en la app (le llamábamos ‘PedidosYa Demo’), o sea, una posible primera aproximación ya implementada de lo que podría salir a pre-prod (‘PedidosYa Night’), asignamos el release/objetivo de uno de los diseñadores a otro que no esté tan familiarizado con dicha tarea/objetivo, y así comparar el design brief, UX y UI de ese release con lo que se experimentaba en PedidosYa Demo, e ir reportando las diferencias o cambios. Al estar el diseñador un poco más ajeno a este objetivo dado que no es el foco en su sprint, la mirada se vuelve más objetiva y no contaminada, sin perder el carácter detallista del ojo del diseñador.

Proceso y metodología

En primer lugar, lo que hicimos con todo el equipo de diseñadores de Producto fue hacer un relevamiento de todos los archivos, pantallas, elementos, flows de lo que han estado trabajando y, paralelamente, investigamos lo que estaba hoy en día en producción para ver las diferencias y dicotomías entre la idea propuesta originalmente y lo que salió en el rollout. La idea era ver la problemática frente a nuestros ojos para entender el objetivo de unificar.

Con toda esta información frente a nosotros decidimos hacer una especie de diagrama de afinidad para lograr ver los problemas hallados para buscar soluciones en común. Luego realizamos la metodología de card sorting con todos los elementos para clasificarlos por categorías hasta llegar a una taxonomía lógica y poder ordenarlos para que la arquitectura de la información quede coherente y entendible para el equipo. Al fin y al cabo, ellos mismos iban a ser los user personas de estos componentes y debía ser lo más amigable y simple posible.

Uno de los tantos problemas que hayamos fue que, por cómo se había estado trabajando previamente, aparecieron elementos con misma funcionalidad a pesar de que visualmente fueran distintos, por lo que los unificamos para hacerlos consistentes y en pieza única.

Quería crear un sistema abierto, simple, usable, reconocible, colaborativo, escalable, actualizable y robusto. Tenía claro que quería usar la metodología atomic design para que todo partiera desde el elemento más básico para luego ser utilizado en componentes y, más tarde, en pantallas.

Manos a la obra

Personalmente nunca había usado Sketch en mi vida, por lo que tuve que aprender a usarlo cuanto antes, ver videos, leer tutoriales, bajar plugins, investigar su potencial (y evaluar si era la herramienta corporativa que debíamos usar), aprender sus limitaciones, requerimientos, y ver cómo debía ser el proceso de trabajo entre los diseñadores, con los frontend y los mobile developers. Digamos que fue un curso intensivo pero valió la pena: me enamoré de Sketch a pesar de alguna de sus limitaciones.

Lo primero que hice fue organizar cómo simbolizar los elementos: la filosofía principal era empezar de lo más chico a lo más grande para que tuviera el modus operandi de ‘herencia’ (como CSS, SCSS o SASS). Es decir, que si usaba un color corporativo, ese color fuera un símbolo que con solo modificarlo, se modificara cualquier elemento, componente y pantalla que lo usara. Y que, a su vez, esto quedara sincronizado y aplicado para todo el equipo de diseñadores.

No fue una tarea para nada fácil: en cada componente tuvimos que definir qué símbolos debería contener. Debíamos pensar que una pantalla es un árbol: estos árboles pueden tener muchas ramas que, a su vez, tienen ramas más chicas y hojas. Es decir: un componente puede estar compuesto por varios símbolos (elementos) cuyos símbolos están compuestos por otros símbolos, y todo así. Digamos que era una ramificación extensa y compleja, pero era la forma de hacerlo para cumplir con mi filosofía. Sabía que lo difícil era toda la etapa inicial del diseño y desarrollo del UI Kit, pero luego, cuando los diseñadores lo usasen, esto iba a facilitar todo y ni que hablar de la efectivización del tiempo de esfuerzo.

Un sistema

abierto
simple
usable
reconocible
colaborativo
escalable
actualizable
robusto

Simbolizamos absolutamente todo: colores corporativos, estilos de textos (títulos, subtítulos, copetes, referencias, labels, tags, precios, alertas), botones (ctas), formas, íconos, ilustraciones, text fields, encabezados, listas, tarjetas, modales, alertas, swimlanes, toast, notificaciones, reviews, paneles, tabs, splash, upsellings, barra de navegación, barra de búsqueda, y de verdad que la lista sigue y sigue.

Y todo esto bajo una estructura simple y de fácil acceso dado que la idea es que el usuario encuentre el símbolo necesitado de forma sencilla y directa. El objetivo es que facilite y no que entorpezca.

A esto había que sumarle una complejidad no menor: los símbolos deberían ser responsive y únicos, por lo que debían estar configurados e ideados para todos los tamaños de dispositivos (desde un iPhone 5.5 hasta el 11, Android, iPad, etcétera). O sea, no queríamos hacer un símbolo para un iPhone 5 y otro para el 8, sino que se reutilice el mismo para ambos dispositivos. El diseñador debía poder seleccionar el símbolo y estirarlo al ancho del dispositivo y que este quedara con las proporciones debidas. Por lo que para cada símbolo y componente tuvimos que configurar cada proporción: qué debía quedar fijo (si el ancho y/o la altura), qué no, qué debía ser dinámico, qué debía quedarse a la derecha, izquierda, arriba y/o abajo cuando sea estirado, qué debía restringirse, qué no.

También tuvimos que tener en cuenta que hay íconos y componentes del sistema que sí teníamos que personalizar para que el usuario sienta que está en su atmósfera: no podíamos usar la status bar de iPhone en un Android, o usar el ícono de 'compartir' de Android en un iPhone.

Otro tema que quería tener firme para facilitar el uso era la sustitución de símbolos en un componente. O sea que un componente tuviera una estructura de fácil sustitución de símbolos que lo componen. Supongamos que tenemos un bottom tab con 4 íconos: la idea es que estos íconos sean símbolos y que el diseñador pueda seleccionar cada uno y sustituirlo por otro (obviamente el símbolo debe tener el mismo tamaño y proporción). O sea, mi idea de base era evitar hasta el límite el ‘detach symbol’ para no perder la actualización y sincronización del UI Kit base.

Un tema no menor eran las distancias de los componentes, los márgenes y paddings. Por lo que evaluamos los distintos componentes y vimos cómo hacer para que estas distancias se respeten sin tener que apelar a la memoria del diseñador ni tener que recurrir a cada rato a la documentación (dado que esto está todo definido en el Design System que hicimos en paralelo). Por lo que fuimos descubriendo varias de estas problemáticas y las fuimos solucionando a medida según el caso. Un ejemplo claro es el de los botones: sabíamos que los padding izquierdo y derecho debían ser de una medida exacta siempre, y lo mismo sucedía arriba y abajo, por lo que comenzamos a utilizar un plugin de Sketch para configurar esto. El diseñador solo tiene que escribir el label del botón, y este se crea tal como lo definimos. Y así fuimos solucionando varias medidas, márgenes y gutters.

Abstract

Un tiempo antes de culminar mi etapa en PedidosYa, gestioné con Abstract y DeliveryHero (empresa alemana que compró PedidosYa) para obtener licencias y poder mejorar más el proceso de actualización del UI Kit, de los flows, blue prints, etcétera. Este sistema apenas había aparecido y ya me parecía sumamente interesante. Explicado de forma simplificada, Abstract es un software que realiza versionados de los archivos Sketch para que se puedan crear distintos branchs (o variaciones y actualizaciones de archivos), y luego pedir un review al responsable (generalmente el diseñador líder). Si este lo aprueba, lo pasa al archivo master para que quede en la versión final y oficial.

Este sistema estaba implementándose en el momento en que me fui de PedidosYa. Sigo en constante contacto con mi antiguo equipo y me comentan que lo siguen usando y que les facilitó mucho la dinámica diaria.

Design System

Paralelamente al UI Kit, creamos el PeYa Design System para que quede todo documentado.

La idea es que en dicho framework esté cada elemento, componente, pieza, pantalla y recurso con la siguiente información:

Datos técnicos (colores, tipografías, interlineados, paddings)
Concepto
Principios
Atributos
Objetivo de su uso
Casos de uso (cómo sí se puede usar, cómo no se puede usar)
Casos border
Animaciones
Microinteracciones
Niveles de elevación
Ejemplos contextuales
Cómo se categoriza
Con qué otros componentes puede convivir y con cuáles no
Cómo encontrarlo en la estructura del UI Kit
Otros cientos de ítems

Una de las tantas ventajas que encontramos en documentar esto fue que linkeamos Sketch con Zeroheight, por lo que si un componente del UI Kit se actualiza, estos cambios automáticamente se actualizan en Zeroheight, donde queda público. Esto facilitó y aceitó mucho el proceso.

Conclusión

Tanto UI Kit como Design System fueron realmente un éxito para la empresa y hasta el día de hoy se siguen usando diariamente. Con base en lo que hicimos con el equipo de diseñadores, se creó una librería en paralelo directamente relacionada pero para desarrolladores con todos los datos técnicos de cada elemento y componente con el mismo propósito: reutilizar, consistencializar y efectivizar los tiempos de desarrollo. Y cada vez que se actualiza un componente, se actualiza en cada librería para que todos estemos trabajando bajo la misma atmósfera.