Caso de Estudio
Diamond Design System
Es por ello que al tomar cualquier desafío de Product Design, una de mis primeras preocupaciones es ¿Tenemos un Design System desde el cual crecer?
He tenido la suerte de tener libertad al momento de crear o continuar uno que ya exista, y es una de las partes más entretenidas de mis procesos.
En esta pagina haré un breve resumen de mi paso a paso a la hora de crear el Diamond Design System, el cual fue utilizado a través de multiples productos de una plataforma de CX.
Haz Scroll para ver todo el proceso 😉
📍¿Dónde estamos?
En el inicio del proceso, me enfoqué en entender como se trabajaba actualmente en términos de UI.
Quería descubrir si ya existían recursos que se reutilizaran, como colores, iconos, botones, diagramaciones, etc. ¿A que recurren los desarrolladores al momento de tomar un ticket? ¿Qué cosas están permitidas y cuales no desde lo visual?
Para entender donde estábamos posicionados en cuando al Design System, plantee las siguientes preguntas:
¿Que tenemos ahora?
Con que herramientas y recursos contamos a la hora de construir o refrescar las distintas secciones de la plataforma.
¿Que framework usamos?
Importante entender las limitaciones y beneficios de los sistemas utilizados por los desarrolladores para proceder con un ritmo de trabajo óptimo.
¿La UI es coherente?
La UI es la comunicación que tenemos con el usuario.
Me interesaba entender si esta comunicación estaba siendo coherente entre las distintas secciones, si el usuario podía identificar fácilmente que hacer con cada elemento.
Base muy pequeña
Existía una pequeña biblioteca de colores y algunos componentes que se reutilizaban, sin embargo el proceso de desarrollo no estaba estandarizado en cuanto a lo visual, cada desarrollador abordaba el front end de una manera distinta.
Al hacer las preguntas previas e investigar y juntarme con distintos colaboradores descubrí lo siguiente:
Frameworks variados
Distintas secciones utilizaban distintos frameworks, lo cual resultaba en una experiencia de UI muy variada.
UI Incoherente
Debido a la UI variada resultante de los distintos frameworks, la comunicación con el usuario no era clara. Los componentes se veían y comportaban de manera distinta, generando mas roce y resistencia a los usuarios.
📍¿Dónde estamos?
En el inicio del proceso, me enfoqué en entender como se trabajaba actualmente en términos de UI.
Quería descubrir si ya existían recursos que se reutilizaran, como colores, iconos, botones, diagramaciones, etc. ¿A que recurren los desarrolladores al momento de tomar un ticket? ¿Qué cosas están permitidas y cuales no desde lo visual?
Para entender donde estábamos posicionados en cuando al Design System, plantee las siguientes preguntas:
¿Que tenemos ahora?
Con que herramientas y recursos contamos a la hora de construir o refrescar las distintas secciones de la plataforma.
¿Que framework usamos?
Importante entender las limitaciones y beneficios de los sistemas utilizados por los desarrolladores para proceder con un ritmo de trabajo óptimo.
¿La UI es coherente?
La UI es la comunicación que tenemos con el usuario.
Me interesaba entender si esta comunicación estaba siendo coherente entre las distintas secciones, si el usuario podía identificar fácilmente que hacer con cada elemento.
Al hacer las preguntas previas e investigar y juntarme con distintos colaboradores descubrí lo siguiente:
Base muy pequeña
Existía una pequeña biblioteca de colores y algunos componentes que se reutilizaban, sin embargo el proceso de desarrollo no estaba estandarizado en cuanto a lo visual, cada desarrollador abordaba el front end de una manera distinta.
Frameworks variados
Distintas secciones utilizaban distintos frameworks, lo cual resultaba en una experiencia de UI muy variada.
UI Incoherente
Debido a la UI variada resultante de los distintos frameworks, la comunicación con el usuario no era clara. Los componentes se veían y comportaban de manera distinta, generando mas roce y resistencia a los usuarios.
⛳¿Adonde vamos?: Objetivos de crear un Design System
Al tener claro el punto de partida, ya podemos empezar a definir el camino a seguir. ¿Cuál es el foco de construir un DS en este punto? ¿Qué queremos lograr?
Optimizar el tiempo
Al tener componentes definidos desde la etapa de diseño que se transmitan al código, unificamos el lenguaje para los desarrolladores.
Ya no es necesario crear un botón cada vez que necesitemos uno, podemos utilizar uno que ya esté creado, probado y validado previamente. Esto resultaría en tiempos de desarrollo mas acotados, un producto más consistente, y desarrolladores más felices y con menos miedo al diseño.
Experiencia cohesiva
El foco principal siempre debe estar en el usuario. Mi objetivo primario era que el usuario pudiera confiar en que la plataforma se comunicaría con el en el mismo lenguaje indiferentemente de la sección.
Es necesario que el usuario pueda identificar fácilmente un botón, un selector, un input, una alerta, etc; sin importar en que sección de la plataforma se encuentre. De esta manera, disminuimos la carga mental del mismo al momento de utilizar el producto y dejamos espacio libre en su mente para enfocarse en los objetivos que desea cumplir con el uso del mismo.
Además, la uniformidad y cohesión permite identificar y diferenciar el producto fácilmente frente a otros competidores.
Escalabilidad
Al identificar un framework mantenible y flexible, la creación de componentes nos permite hacer crecer nuestro producto mucho más facilmente, a la vez que permite cambios que se aplicarían en todos los usos del mismo componente sin tener que ir uno a uno.
⛳¿Adonde vamos?: Objetivos de crear un Design System
Al tener claro el punto de partida, ya podemos empezar a definir el camino a seguir. ¿Cuál es el foco de construir un DS en este punto? ¿Qué queremos lograr?
Optimizar el tiempo
Al tener componentes definidos desde la etapa de diseño que se transmitan al código, unificamos el lenguaje para los desarrolladores.
Ya no es necesario crear un botón cada vez que necesitemos uno, podemos utilizar uno que ya esté creado, probado y validado previamente. Esto resultaría en tiempos de desarrollo mas acotados, un producto más consistente, y desarrolladores más felices y con menos miedo al diseño.
Experiencia cohesiva
El foco principal siempre debe estar en el usuario. Mi objetivo primario era que el usuario pudiera confiar en que la plataforma se comunicaría con el en el mismo lenguaje indiferentemente de la sección.
Es necesario que el usuario pueda identificar fácilmente un botón, un selector, un input, una alerta, etc; sin importar en que sección de la plataforma se encuentre. De esta manera, disminuimos la carga mental del mismo al momento de utilizar el producto y dejamos espacio libre en su mente para enfocarse en los objetivos que desea cumplir con el uso del mismo.
Además, la uniformidad y cohesión permite identificar y diferenciar el producto fácilmente frente a otros competidores.
Escalabilidad
Al identificar un framework mantenible y flexible, la creación de componentes nos permite hacer crecer nuestro producto mucho más facilmente, a la vez que permite cambios que se aplicarían en todos los usos del mismo componente sin tener que ir uno a uno.
🦠 Atomic Design
El Diamond Design System se basó en el concepto de Atomic Design, que organiza los componentes de diseño en niveles atómicos, moleculares y de organismos para su reutilización y coherencia.
A continuación un detalle de lo que incluí en cada sección:
Átomos: acá detalle el nivel más básico de todo el sistema, incluye colores, tipografías, iconos, logos, espaciados. Cabe destacar que a lo largo de todo el sistema estuvo planteado bajo una retícula de 8pts.
Moléculas: incluye componentes pequeños que van a ser utilizados en muchas diferentes secciones, tales como botones, listas desplegables, componentes para tablas, inputs, alertas, tooltips, etc.
Organismos: componentes más específicos y estructurados, tales como modales, pantallas de alertas, modales de ingresos de información o formularios, etc. En este caso genere una sección especifica de componentes para esta aplicación.
Vamos a Figma
🦠 Atomic Design
El Diamond Design System se basó en el concepto de Atomic Design, que organiza los componentes de diseño en niveles atómicos, moleculares y de organismos para su reutilización y coherencia.
A continuación un detalle de lo que incluí en cada sección:
Átomos: acá detalle el nivel más básico de todo el sistema, incluye colores, tipografías, iconos, logos, espaciados. Cabe destacar que a lo largo de todo el sistema estuvo planteado bajo una retícula de 8pts.
Moléculas: incluye componentes pequeños que van a ser utilizados en muchas diferentes secciones, tales como botones, listas desplegables, componentes para tablas, inputs, alertas, tooltips, etc.
Organismos: componentes más específicos y estructurados, tales como modales, pantallas de alertas, modales de ingresos de información o formularios, etc. En este caso genere una sección especifica de componentes para esta aplicación.
Vamos a Figma
📘Documentación y Handoff
¿De que sirve un buen diseño si no puede hacerse realidad? Si el diseño es increíble pero el desarrollador no lo entiende y no lo puede traducir al código, entonces no sirve de nada.
Como parte de mis esfuerzos, me preocupe en detallar lo más claramente posible el traspaso a los desarrolladores encargados para que su trabajo pudiera ser más fácil y óptimo.
Ejemplo: AButton
Documentación AButton
Para ejemplificar esta documentación quiero mostrar el ejemplo del componente AButton, el cual es un botón con múltiples variaciones para múltiples propósitos.
Este componente estaría presente a través de toda la plataforma, por lo que su desarrollo debía ser lo más limpio posible.
A la derecha se aprecia una captura del componente creado y sus variaciones en figma. Esto pudo llegar hasta acá cierto? El desarrollador podría revisar a través de figma y tomar lo que interprete.
Pues bien, es esa misma "interpretación" la que deseaba ahorrarme al momento de pasar al código. Quería que el desarrollador fuera un mero traductor y no tuviera que ponerse creativo con el componente.
Para lograr esto, documente en términos de código el componente, cada una de sus variaciones de estado, color, tamaño, etc.
Abajo algunas capturas del figma entregado a los desarrolladores.
¿Cómo lo abordé?
Mediante dos puntos claves: documentar y explicar.
Documentar, porqué aunque seas muy claro explicando, la memoria tiene sus limitaciones y el ciclo de aprendizaje de cada desarrollador es distinto, algunos entienden con reuniones y otros con documentaciones escritas.
Explicar, porque nuestra manera de documentar puede no coincidir con un lenguaje que los desarrolladores manejen. Más allá de las barreras del idioma, explicar tu documentación e intención permite que el desarrollador entienda que queremos lograr con lo que vamos a desarrollar.
Este enfoque permite presentar el diseño y que el desarrollador pueda abordarlo de la manera que prefiera, confiando en que encontrará el sistema que le acomode siempre disponible.
📘Documentación y Handoff
¿De que sirve un buen diseño si no puede hacerse realidad? Si el diseño es increíble pero el desarrollador no lo entiende y no lo puede traducir al código, entonces no sirve de nada.
Como parte de mis esfuerzos, me preocupe en detallar lo más claramente posible el traspaso a los desarrolladores encargados para que su trabajo pudiera ser más fácil y óptimo.
Documentación AButton
¿Cómo lo abordé?
Mediante dos puntos claves: documentar y explicar.
Documentar, porqué aunque seas muy claro explicando, la memoria tiene sus limitaciones y el ciclo de aprendizaje de cada desarrollador es distinto, algunos entienden con reuniones y otros con documentaciones escritas.
Explicar, porque nuestra manera de documentar puede no coincidir con un lenguaje que los desarrolladores manejen. Más allá de las barreras del idioma, explicar tu documentación e intención permite que el desarrollador entienda que queremos lograr con lo que vamos a desarrollar.
Este enfoque permite presentar el diseño y que el desarrollador pueda abordarlo de la manera que prefiera, confiando en que encontrará el sistema que le acomode siempre disponible.
Design System
The Design System I developed was based on the concept of Atomic Design, which organizes design components into atomic, molecular, and organism levels for reuse and coherence.
Below is a breakdown of what I included in each section:
Atoms: Here's a detailed breakdown of the most basic level of the entire system, including colors, typography, icons, logos, and spacing. It's worth noting that the entire system was designed using an 8pt grid.
Molecules: This section includes small components that will be used across various sections, such as buttons, dropdown lists, table components, input fields, alerts, tooltips, etc.
Organisms: These are more specific and structured components, such as modals, alert screens, input modals or forms, etc. In this case, I created a dedicated section of components specifically for this application.
Atoms
Color System
Tipography
Montserrat
Icons
Contacto
Acciones
Flechas
Gráficos
Elementos
Símbolos
Molecules
Buttons
Default
Hover
Disabled
For the button I developed a component on figma that connected icons and allowed to do variations on top of the same element on a quick way.
Input
Table Cells
Organisms
Creation Module
Toolbar
Resume Card
👀 ¿Fin?
Me encantaría decir que terminé el Design System. Pero eso solo ocurriría en un mundo perfecto, y lo perfecto no existe.
Lo que si existe es la constante necesidad de cambio, en todo aspecto. Es por ello que el Diamond Design System es un trabajo por siempre en proceso. Surgen nuevas problemáticas, el producto evoluciona, componentes previamente planteados necesitan ajustes, etc.
Esto es un signo de buena salud del producto, así que felizmente digo: No es el fin de este design system, es solo el comienzo.