Organización

Separando documentos

La forma en la cual están separados los documentos en un design system es la primera indicación de cómo serán las cosas dentro de él. En cualquier caso, siempre es conveniente apuntar a una organización intuitiva y modular, así de sólo un vistazo rápido ya puedes saber de qué se trata cada documento, y su relación con los demás.

El design system

Un design system es modular por naturaleza. Sus documentos deberían tener cierta independencia, y beneficiarse de la flexibilidad de las distintas combinaciones posibles.

A diagram with connected squares that represents how to split files
  • Style Guide o Foundations: Contiene todo lo que llamaríamos tokens: estilos de color, sombras, espacio, tamaños, escala tipográfica, entre otras cosas.

  • UI Kit: Contiene los componentes como campos de texto, cuadros de diálogo, botones, etc. Los componentes en este archivo usan los etilos del documento de Style Guide, y no deberían contener otros estilos por separado.

  • Patterns: Los patterns o patrones, son representaciones de pantallas o procesos necesarios para completar una tarea, que podrían repetirse a lo largo de un proyecto. Un pattern puede ser algo individual, como una pantalla con un formulario (así puedes ver la separación entre campos, la ubicación del botón de enviar); o algo más largo como un proceso de búsqueda que involucre varios pasos. Los patterns son mayormente referenciales, y no necesariamente deberían ser componentes de Figma o símbolos de Sketch.

En proyectos o features

Cada proyecto o feature puede necesitar uno o más documentos, dependiendo de su complejidad y de si está usando sus propios componentes o los que vienen del design system (o una combinación de ambas cosas). Los diferentes tamaños de pantalla que estés teniendo en cuenta también pueden impactar en la organización y separación de los documentos.

Poniendo de ejemplo un caso relativamente simple, donde el proyecto está siendo diseñado tanto para desktop como mobile, y los componentes están viniendo desde una librería separada dentro de ese proyecto, la estructura podría verse algo así:

Project
↳ Project (Desktop)
↳ Project (Mobile)
↳ Library

Dividir tamaños de pantallas en documentos separados te dará un poco más de libertad y espacio a la hora de organizar esos documentos internamente, como veremos más adelante. Por otro lado, si el proyecto está usando sus propios componentes que no son parte del design system, estarán incluidos en el documento Library, dentro de la misma carpeta.

Páginas

Las páginas se usan para separar distintas secciones dentro del mismo producto, siguiendo una estructura que en cierta medida refleja la navegación o niveles principales. Hagamos de cuenta que tenemos una app con una barra de navegación en la parte inferior.

A portion of a screen showing a navigation or tab bar at the bottom

Las páginas en el documento coincidirán con esa división:

Home
Search
Profile
Account
Settings

En las librerías y UI Kits

Cuando los documentos tienen componentes en librerías o UI Kits, también habrá una página separada donde se ubicarán todos los símbolos y componentes. La idea es tenerlos separados y bien localizados, y no repartidos por ahí en diferentes pantallas o páginas. Veamos el siguiente ejemplo, que representa el documento de un UI Kit en un design system:

Elements
Components
Patterns
Editable components

Frames y artboards

La disposición de los frames y artboards dentro de una página te puede dar una idea de la relación entre pantallas, si se usa de una forma consistente en todas las páginas. La ubicación de las pantallas (en filas y columnas) y la separación (horizontal y vertical) puede ayudar a establecer un sistema de organización.

Verticalmente

De forma vertical, se ubican los diferentes estados de una pantalla. Por "estados" queremos decir momentos temporales que atraviesa una pantalla, y generalmente son siempre los mismos.

A serie of colour blocks representing screens separated vertically
  • Final: cuando toda la información está completa. Este es el escenario ideal, donde la cantidad y complejidad de información es la que estamos esperando encontrar la mayor parte del tiempo.
  • Partial: en este caso falta información. Esto podría pasar porque el usuario no ha subido toda la información necesaria, o porque hay información que no puede ser mostrada en ese momento.
  • Empty: no hay información por mostrar. Esto podría pasar, por ejemplo, cuando hay una lista de ítems favoritos pero el usuario aún no ha marcado ninguno como tal.
  • Loading: es lo que se mostrará mientras la información está siendo cargada, y aún no aparece. Una práctica habitual es usar un "esqueleto" con una estructura de base que pueda mostrarse anticipadamente.
  • Error: hay algo que no va bien, y por lo tanto la información no puede mostrarse. Piensa, por ejemplo, en lo que pasaría cuando el usuario no tiene conexión a internet.

No todas las pantallas tendrán todos los estados, esto se puede ajustar caso por caso. Aún así, separando la pantallas verticalmente podemos empezar por el estado final y luego incluir los otros debajo, manteniendo la misma separación vertical.

Horizontalmente

De forma horizontal las pantallas se disponen de manera que representen un flujo de izquierda a derecha. Por ejemplo, la primera de ellas podría ser la pantalla principal (o de primer nivel) y la siguiente una secundaria (o de segundo nivel). También podría ser un elemento temporal, como una ventana de diálogo.

A serie of colour blocks representing screens separated horizontally

La separación entre frames o artboards también indicará la relación entre pantallas: si están cerca, entonces la relación conceptual entre ellas también será más grande.

Capas

La disposición de capas sigue una organización que coincide con el orden de los elementos en la interfaz. La capa superior será para el elemento que está arriba de los demás. Y la siguiente, debajo, también para el elemento que esté debajo en la interfaz, y así sucesivamente con las demás. Siempre siguiendo un orden vertical que corresponda con un flujo de lectura de arriba hacia abajo, coincidiendo con el diseño.

Cuando los elementos en el diseño están horizontalmente uno junto a otro, entonces la capa que esté más arriba corresponderá al elemento que esté más hacia la izquierda, siguiendo un orden de lectura de izquierda a derecha.

A page layout containing a header, sidebar, main content and footer

Excepciones

La forma en que las capas están ordenadas determina también que un elemento esté "encima" o cubra a otro en el lienzo. Por ejemplo, si tienes un cuadro de diálogo será necesario que esté primero en la lista de capas, de forma que pueda cubrir el resto de la interfaz. Esto es algo que también se debe tener en cuenta, y por supuesto será una excepción al sistema de ordenamiento que hemos comentando antes.

Componentes

Idealmente, los componentes tienen que seguir la misma configuración y orden de capas que se usa fuera de ellos. Esto también aplica a cuando incluyen instancias anidadas de otros componentes.

Flexibilidad

Para que el mantenimiento de los componentes sea más fácil de llevar a cabo, tenemos que minimizar la cantidad total de componentes que tenemos. Es por esto que los componentes se piensan de forma que sean flexibles, así puedes tener diferentes resultados desde la misma base, por ejemplo ocultando o mostrando capas.

Veamos un ejemplo práctico. El componente Item tiene una imagen de avatar a su izquierda. Este avatar también incluye una capa con una imagen transparente por sobre el ícono, así este ícono puede verse cuando no haya una imagen cargada. Esto tiene un doble propósito: simular un comportamiento real, y también hacer que el componente sea más versátil.

The item component uses an avatar with a transparent layer on top of it

Componentes de base

Una estrategia para intentar minimizar la cantidad de componentes es pensar en la estructura de base que varios de ellos compartirán, es decir, la que todos ellos tendrán en común. A partir de ahí se crea un componente de base que funciona como estructura común. Los otros componentes que tengan ligeras variaciones o diferencias pueden usar este componente como punto de partida, como una instancia anidada, y luego añadir las capas adicionales que puedan necesitar.

Veamos un ejemplo con este componente Item que hemos visto antes. Si queremos una variante sin padding a sus lados, y otra con padding, lo que tiene más sentido sería primero crear la opción sin padding.

The item component, without paddings at its sides

Luego, puedes incluir este componente como una instancia anidada dentro del componente que sí tendrá padding. Este nuevo componente con padding ocultará la línea divisoria de la instancia, y luego añadirá una capa en este componente que la tenga de ancho a ancho.

The item component, without paddings at its sides, is used as base for one with padding

Trabajar de esta forma es clave para optimizar el mantenimiento. Con sólo actualizar el componente de base los cambios se propagarán a las otras variantes que la estén usando.

¿Qué debería ser un componente?

En lo que concierne al diseño, la idea es siempre tener la menor cantidad posible de componentes en un archivo. Esto ayudará a reducir el tiempo de mantenimiento que necesitemos para ellos; y es por esto que nos beneficiará seguir buenas prácticas como usar componentes anidados siempre que sea posible (y tenga sentido).

En cualquier caso, reducir el mantenimiento no quiere decir que tengamos que comprometer la facilidad de uso y posibilidad de encontrar fácilmente los componentes que necesitamos en nuestro día a día. Tenemos que preguntarnos a nosotros mismos: ¿Esto debería ser un componente (de Sketch o Figma), o en este caso podría servir que fuera solamente un grupo?. Para poder responder esto, tenemos que hacernos otras dos preguntas fundamentales:

  • ¿Qué tan seguido se usará? Si esto se usará solamente en algunos casos aislados, tal vez no sea necesario crearlo como componente. El beneficio principal de crear componentes son los cambios y actualizaciones que se propagan con facilidad, por lo tanto, mientras más se use el componente, más estará justificado que sea un componente de Figma o símbolo de Sketch.

  • ¿Es solamente para documentación? Un componente puede tener diferentes casos y estados, entre otras cosas. Estos deberían estar documentados en alguna parte, pero no siempre deberían ser un componente o símbolo en nuestro archivo de diseño. Para aquellos casos que son solamente referenciales (es decir, para propósitos de documentación) un grupo puede ser suficiente. Esto podría ser, por ejemplo, para el estado Down de un botón, una situación que la mayoría de las veces no necesitarás usar en tus diseños, y que basta con que esté documentada una sola vez.

Anatomía y propiedades

Cuando los componentes pasan de diseño a código, generalmente tienen propiedades opcionales, y otras que son requeridas. La persona de front-end usará esto para representar el componente en la interfaz. Estas propiedades pueden decidir si el componente tendrá (o no) un ícono, una imagen, el alto y ancho, y todas esas opciones que se decidió que fueran provistas como posibles de configurar a nivel de código.

It shows the different parts a component can have, such as an avatar, a title and a descriptive text

Si queremos usar el componente Item con una imagen de avatar, pero intencionalmente usando la variante con padding y ocultando la línea divisoria, el código se vería algo así:

<item padding no-divider>
    <avatar type="icon" icon-name="user"></avatar>
    <content title="Jane Copper"></content>
    <content text="Berlin"></content>
    <action icon-name="trash"></action>
</item>

Estas propiedades o atributos que ofrecerá el componente deben decidirse en la etapa de diseño, involucrando a los programadores y acordándolas como equipo. Estas definiciones son también un compromiso de parte del diseñador de no usar variantes personalizadas de un componente que, más adelante, no serán posibles de obtener con el código existente.