En este módulo hemos creado los componentes de nuestro Sistema de Diseño. Ahora, es el turno de documentarlos para que sepamos cuáles son las pautas a seguir y que esta sea la fuente de verdad para nuestro equipo tanto de diseño como de desarrollo.
Pero antes, quiero compartirte estas dos charlas/tutoriales del canal oficial de Figma en YouTube sobre Documentación de un Sistema de Diseño por si deseas profundizar mucho más en este tema:
Ahora sí, ¡comencemos!
Para documentar nuestro Sistema de Diseño, es importante que revisemos cuál es el objetivo y cuáles son las cosas que debemos incluir para cumplir con ese objetivo.
Inicialmente, lo que queremos es que nuestro equipo de diseño y desarrollo conozca qué componentes hay y cómo puede utilizarlos. Por esta razón, como buenas prácticas debemos incluir en la documentación:
Título e introducción
Anatomía del componente
Arquitectura del componente (donde están incluidas las variantes)
Ejemplos del componente con las diferentes variantes
Descripciones de uso
Consideraciones adicionales (como por ejemplo de accesibilidad)
Esto puede variar dependiendo del componente y de lo que el equipo de diseño considere pertinente para el diseño. Esto puede tener varias iteraciones y no necesariamente debe estar 100% perfecto y completo en un inicio. Lo importante es hacer una descripción detallada que de una clara idea del componente: cómo es, qué variantes tiene, cuáles son sus dimensiones, ejemplos de uso, entre otras cosas. Imagina que estás escribiendo una especie de tutorial para que personas de tu equipo (que ya puedan llevar tiempo o que apenas están comenzando) puedan diseñar pantallas con estos componentes.
¡Cuéntame en los comentarios cómo te quedó esta documentación!
Nos vemos en el siguiente módulo en donde hablaremos sobre cómo vender y medir nuestro Sistema de Diseño, como también, sobre mi experiencia creando Sistemas de Diseño en Startup desde cero.
este tipo de documentacion debemos crearla para todos los componentes, de mi punto de vista en mi producto a los ingenieros no les es muy util esta documentacion ya que no tienen que construir el componente desde cero, ya que este esta creado, ellos solo copian el codigo que se uso en el pasado y ya , por ejemplo cuando en mi disenos encuentran botones, ellos ya tienen el codigo de este componente.
Cual seria el objetivo de construir la documentacion que todos los desarrolladores ya saben como hacer?
El objetivo es el mismo que las reglas en la vida.
Aun cuando sabemos que algo está mal y no lo debemos hacer, hay reglas que nos dicen que están mal y no lo debemos hacer.