¿Qué es un Sistema de Diseño?

He escrito este artículo pensando principalmente en estudiantes de diseño, desarrollo o producto que aún no saben lo que es un Sistema de Diseño, pero también para cualquiera que haya oído hablar de "Componentes" y "UI kits" pero no acaba de comprender cuál es la diferencia entre estos y conceptos más familiares como "Guías de estilo" y "Manuales de marca".

A mi me gusta definir a los Sistemas de Diseño como:
"La manera oficial en que una compañía Diseña y Desarrolla sus productos digitales. Una serie de reglas, procesos y herramientas que nos ayudan a tomar decisiones inteligentes y coordinadas."

En esta definición la palabra más importante no es "diseño" es por ello que evitaré el término completo y usaré alternativamente sólo sistema y DS (por sus siglas en inglés).

Analogías y enfoques comunes

En los últimos años se han popularizado 3 figuras muy buenas para ilustrar las diferentes características de un DS:

1. Un DS es como un Lego: un conjunto de piezas predefinidas, reutilizables y modulares en el que todos los bloques encajan perfectamente.
2. Un DS es un conjunto de documentación que actúa como una receta de cocina la cual nos indica los ingredientes y cómo mezclarlos para conseguir resultados consistentes.
3. Un DS es similar a un conjunto de Átomos, Moléculas y Organismos, un sistema cerrado en el que los elementos se pueden combinar de una manera lógica y acorde a su nivel de complejidad.

Aunque estas tres analogías son geniales, porque nos muestran las claves de un DS, por sí solas se quedan cortas para explicar la complejidad del desarrollo de productos digitales; y es justamente esta complejidad la que un Sistema de Diseño resuelve.

¿Es realmente complejo desarrollar productos digitales?

En principio no debería serlo, pero hay varios aspectos a tener en cuenta para comprender lo que hay detrás del diseño y programación de la interfaz de usuario.

Simplificando y generalizando a modo de ejemplo, esta es descripción superficial de una de las empresas de Adevinta, Fotocasa.

1 - Fotocasa tiene varios productos en el mercado inmobiliario:

• Aplicaciones para profesionales
• Aplicaciones para clientes particulares
• Aplicaciones para usuarios internos
• etc

2 - Cada uno de estos productos está presente en varios canales:

• Páginas web escritorio y dispositivos móviles
• Aplicaciones nativas para iOS y Android
• Redes sociales, Merchandising, TV, Publicidad
• etc

3 - Fotocasa está dividida en grandes áreas:

• Atención al cliente
• Marketing
• Producto
• etc

Y a su vez cada una de estas áreas está sub-dividida en equipos independientes.

En el caso del Área de Producto, que es donde trabajan juntos los diseñadores y programadores, cada equipo es autónomo y normalmente responsable sólo de una parte de la experiencia de usuario, ya sea una sección de la página web o una funcionalidad transversal que comparten varias aplicaciones.

Para ilustrar esta autonomía podemos imaginarnos equipos con esta división de responsabilidades:

• El equipo X se encarga de facilitarle la vida a los usuarios que buscan vivienda y necesitan refinar (filtrar) sus resultados.
• El equipo Y se encarga de toda la experiencia que supone la creación de una cuenta.
• El equipo Z se encarga de todo lo que pasa dentro del área "mi cuenta" para aquellos usuarios que ya se han registrado.

Esta distribución de tareas entre equipos debe estar bien coordinada porque, en definitiva, el producto es uno y un usuario puede descargarse la App en su iPhone para crearse una cuenta y sin embargo continuar la búsqueda en el ordenador. Este usuario debe experimentar que está conectado a un mismo producto.

En una realidad multi-dispositivo, en el que la navegación debe ser homogénea y natural independientemente de cuántas manos intervengan en su creación, la consistencia visual tiene especial relevancia, es por ello que cuando oímos hablar de sistemas el foco suele estar en las herramientas que nos facilitan diseñar y programar consistentemente reutilizando símbolos (UI-Kits) y trozos de código (Componentes).

En este contexto nos podemos preguntar: Si ya podemos reutilizar símbolos de diseño y código para gestionar la consistencia ¿cuál es la necesidad de un sistema más amplio?

¿No se resuelven los otros problemas con Guías de estilo y Manuales de Marca de toda la vida?

Aparentemente si, y podríamos decir que hay poca diferencia entre un DS y lo que han estado haciendo por décadas las grandes industrias de producción a escala:

• Las fábricas de coches diseñan, construyen y entregan sistemáticamente productos de altísima calidad ajustándose a las legislaciones de cada mercado e incluso permitiendo a cada comprador personalizar los accesorios.

• La industria del "packaging" también ha resuelto la consistencia de calidad. Solamente con entrar en un supermercado podemos saber cuales productos pertenecen a una misma línea y marca, independientemente del contenido del envase o las ilustraciones.

• Los periódicos escriben, diseñan, imprimen y entregan miles de copias todos los días. El diseño de editorial sigue unas reglas y procesos, un sistema muy bien aceitado que es además precursor de los estilos de nuestras Webs (cabeceras, párrafos, negritas, imágenes, etc)

Estos y otros cientos de productos existen desde hace mucho tiempo, antes que cualquier página web, y para ellos son válidas las mismas analogías con las que comencé este artículo.

• La fabricación de coches es un buen ejemplo de la combinación de piezas como si fuesen un LEGO

• El diseño de packaging usa "recetas" de constantes y variables para lograr que todos los diseños de diferentes cajas de infusiones respiren igual.

• Las columnas y elementos de un periódico son análogas a elementos químicos que combinados dan forma e identidad a una determinada línea editorial.

Espera... ¿Estamos reinventando la rueda? ¿Son los Sistemas de Diseño una moda? ¿Estamos volviendo a bautizar algo que ya existía?

Rotundamente no.

Los Sistemas de Diseño no existían cuando internet comenzaba a ser lo que es en la actualidad y tampoco son una moda que pasará. Son una evolución natural y necesaria de nuestra forma de hacer diseño y programación de productos digitales.

Para entender este punto de vista hay que enfatizar que ni los símbolos reutilizables (UI Kits y Componentes) existían hace años, ni las Guías de estilo y Manuales de Marca son por sí solos un DS.

¿Cómo se diseñaba y programaba antes de tenerlos y porqué nos encontramos en este punto?

Del lado de diseño

Yo que soy cuarentón comencé a diseñar "para web" justo después de acabar la licenciatura en Diseño Gráfico, una carrera repleta de reglas de composición y limitaciones técnicas. Y justamente "la web" se presentaba como lo contrario: una mundo nuevo, sin reglas, en el que se podía animar cualquier interacción casi gratis.

Hace más o menos 20 años html estaba en pañales, era menos rico en posibilidades y los diseñadores gráficos que comenzábamos a poner un pie en la web nos lanzamos de cabeza a herramientas como Macromedia Flash que nos permitía hacer animaciones con las que interactuar y creíamos (equivocadamente) que la web evolucionaría hacia el diseño audiovisual ya que nuestro día a día estaba más cerca de la animación, el diseño de carteles y publicidad que del diseño industrial o editorial.

Y el cliente no demandaba otra cosa. Para las marcas la web era un sitio en donde hacer branding, no producto.

Aunque no todo era Flash y muchos defendían que "hacer web con html" era una mejor idea, seguían siendo días de gloria para quienes podíamos hacer "webs" y "micro-sites" que distribuíamos en CD auto-ejecutables a pantalla completa.

También hay que recordar que cuando comenzamos no había legislación sobre riesgos de ejecutar nada en la web, ni códigos de conducta, ni consejos de buenas prácticas. Los diseñadores no teníamos muy claro si algo se ejecutaría en el ordenador del cliente o en el servidor (y tampoco sabíamos lo que todo aquello significaba). Prácticamente nadie era consciente de lo que experimentaríamos en unos años. Los teléfonos inteligentes no existían, el concepto de accesibilidad no significaba nada especial para ninguna de las personas que conozco, etc.

Y sin darnos mucha cuenta ya lo teníamos encima, una eclosión de dispositivos y pantallas. Todo esto estimulado por un incremento bestial en la velocidad de la conexión a internet, que daba piedra libre para hacer diseños y desarrollos cada vez más innovadores.

Lo cierto es que reaccionamos tarde: hasta hace poco en las escuelas de diseño y programación se seguía enseñando una "web" de ilimitada libertad creativa sin riesgos evidentes o impacto relevante. Y no sin razón... al fin y al cabo lo digital no está escrito en piedra: a diferencia de un coche o un periódico, nosotros podemos corregir un fallo en cualquier momento aunque ya hayamos entregado el producto.

¡Oh! Esta es una de las claves de la complejidad inevitable del trabajo digital. La versión final del producto es el resultado de iteraciones y decisiones que no están obligadas a guardar coherencia con lo que había antes.

Aunque la escalabilidad, la consistencia y las buenas prácticas seguían siendo fundamentales en todas las ramas del diseño, nosotros creímos que la web sería otra cosa, con sus pros y contras.

Lo efímero de la plataforma, la eclosión de herramientas y el potencial de la tecnología... podríamos haber corregido el rumbo antes pero llegaron más pantallas, teléfonos inteligentes y tabletas, aplicaciones nativas (iOS y Android simplificando mucho), etc.

De repente el concepto de "multi-dispositivo", un montón de variaciones para "pintar" y una obsesión por controlar cada interacción, cada diseño, de cada una de ellas, en todas las posibles resoluciones y orientación de cada dispositivo.

Sumado a la llegada del concepto de "contexto": El usuario no navega de la misma manera en el ordenador de su casa que cuando está sentado en el Metro. "Tenemos que diseñar experiencias diferentes para cada caso".

¡Ojo! no digo que el diseñar teniendo en cuenta el contexto esté mal, sino que es una realidad relativamente nueva.

Herramientas de diseño

Aunque en muy poco tiempo aprenderíamos que diseñar "para Web" era muy diferente a diseñar visuales, nuestras herramientas no irían al mismo ritmo. Flash fue desaconsejado vehementemente por diversas razones y muchos de nosotros reemplazamos nuestras herramientas de diseño gráfico tradicional (como Illustrator y Photoshop) por Fireworks. Aún así tuvieron que pasar unos cuantos años hasta el lanzamiento de Sketch, seguramente la primera herramienta de uso masivo especialmente creada para el diseño de interfaces (UI Design).

Y luego la locura, una explosión de herramientas de diseño, animación y prototipo: Una nueva por año, una nueva por mes, por semana, una mejor que la otra... hoy mismo estoy con un debate racional y emocional entre Sketch y Figma.

Escribir sobre la evolución de las herramientas da para otro artículo entero, pero el mensaje que quiero comunicar en realidad es que las herramientas que utilizamos en un principio para diseñar webs, banners y aplicaciones eran aquellas pensadas para el diseño sin reglas: retoque fotográfico, logos, animación y cartelería publicitaria. No elegimos inicialmente aquellas que ya nos proveían guías de estilo como QuarkXpress y PageMaker, herramientas de diseño editorial.

---

Antes de explicar la parte de código, doy una mini definición de dos conceptos por si no estás familiarizado con ellos (muy simplificado, perdón programadores): El backend es lo que pasa en el código antes de entregarle contenido a tu ordenador para que tu lo veas, y el front-end es la parte de código que ves y con el cual interactúas.

Ahora sí.

Del lado de código:

Por un lado tenemos que recordar que en un principio las webs eran bastante libres en composición. Independientemente de que fuese incorrecto a nivel técnico, lo cierto es que se podía "pintar" cada página por separado sin mucho remordimiento y, a pesar de la existencia inicial de hojas de estilo, cada página de un mismo sitio podía ser totalmente diferente a la siguiente sin mucho drama.

Por otro lado los usuarios no esperábamos tampoco que las webs fuesen dinámicas, que tuviesen lógica. Nuestra expectativa no era que fuesen inteligentes y que nos mostrasen contenido diferente de acuerdo a nuestra interacción, nuestro perfil, o posición en el flujo de la página. Hoy estamos muy acostumbrados a que existan pasos, pantallas interconectadas e interacciones no lineales, pero cuando comenzamos a diseñar para web lo hacíamos "pintando" cada página de forma aislada, buscando que fuera coherente pero independiente del resto, como si fuese una revista o un periódico físico.

En el caso de las webs "dinámicas" era el backend quien hacía la mayor carga de trabajo. Casi nada de la lógica pasaba en tu ordenador, sino que en cada interacción había una llamada al servidor, que procesaba todo y devolvía otra página. Cada página era simplemente un html (unas plantillas si no sabes de código) que el frontend podía colorear y animar. Evidentemente muy poco del trabajo de diseño se veía impactado por lo que pasaba en el backend a pesar de que mucho de lo que pasaba en diseño impactaría a backend.

---

Las cosas son muy diferentes ahora: La potencia del frontend ha crecido a una velocidad bestial, con avances en paralelo de librerías y frameworks que hoy permiten hacer auténticas maravillas sin necesidad de enviar datos al servidor para que las procese backend y las devuelva. Esto significa que tanto diseño como frontend tienen más alas, ya que la interacción de los usuarios con la página no se limita a lo que ve sino que todos los datos con los que podemos "jugar" están a nuestra disposición (filtros, contenido dinámico, notificaciones, etc) y un mismo trozo de diseño y código no sólo puede ser reutilizado sino que se puede modificar en tiempo real.

Otro aspecto a tener en cuenta es que "el tráfico" (la gente que visita un sitio o una App) cuesta dinero; los datos que antes se guardaban en servidores físicos ahora están en "la nube", y "la nube" es un proveedor como Amazon o Google-Cloud que cobran por almacenar y distribuir estos datos.

Esto nos obliga a dividir las aplicaciones en pequeños módulos para que el usuario sólo descargue lo que necesita, y paguemos poco tráfico. Y cada uno de estos módulos debe verse e interactuar de manera consistente.

---

Sé que estoy simplificando y escribiendo algunas barbaridades, pero lo hago con fines divulgativos ;)

---

A este tren se suma además la proliferación de servicios que permiten enriquecer las webs y aplicaciones sin que el equipo las tenga que programar, como pueden ser una pasarela de pago o un servicio de chat que se integra con nuestro código pero que no está dentro de él.

Usar estas piezas de Lego de diferentes fabricantes nos obliga a prestar atención a propiedades que no siempre son compatibles con nuestras reglas de diseño o programación.

Esto impacta directa y no siempre positivamente en la uniformidad del producto ya que un mismo usuario saltará de un proveedor a otro en la misma sesión.

Además el código técnicamente correcto para web es extremadamente abierto, flexible, permisivo: Se puede lograr el mismo resultado de mil maneras diferentes: una caja azul se puede programar con o sin componentes, escribiendo estilos en el propio html o en un archivo de cualquier extensión (.CSS, .JS, SCSS, etc), con o sin la necesidad de usar pre-procesadores, con o sin javascript, etc. Casi cualquier cosa se puede "traducir" para que un explorador como Chrome lo entienda.

¡Ah! también comenzamos a hacer experimentos para mejorar nuestras aplicaciones: Hoy podemos comparar variaciones del mismo diseño en paralelo, mostrándole a algunos usuarios una versión y a otros otra, medirlo y quedarnos con la mejor (lo que se conoce como AB test). Esta es una técnica muy potente pero, siguiendo nuestras analogías, al ser una receta muy libre promueve inconsistencias y spaghetti de código.

Por si fuese poca complejidad y pocos elementos a tener en cuenta, la estructura de nuestros sitios tiene que gustar a Google para que podamos aparecer entre sus resultados más relevantes: El código debe pesar poco, el HTML debe ser semánticamente correcto, el contenido de calidad, la página debe cumplir unos parámetros de seguridad, incluir o excluir tal o cual contenido, etc.

¿Cómo ha impactado este incremento de complejidad en nuestra forma de trabajar?

Mirando el lado bueno, desencadenó la creación de nuevos perfiles de Diseño (que además hemos incorporado a nuestras responsabilidades la Investigación de usuarios, el análisis de datos, etc) y desencadenó también una especialización de los programadores gracias a la división del código de Front-End en trozos que hay que combinar, compatibilizar, empaquetar y distribuir.

¡Y todo esto sin haber siquiera entrado en el universo de las Apps Nativas! Madre mía.

Mirando el lado menos cómodo, las cosas han dejado de ser simples. Por un lado tenemos cada vez más facilidad para "meter cosas" en una aplicación, pero por otro hemos perdido la capacidad de controlarlo todo. Estamos obligados a mirar con cuidado aspectos que hasta hace poco tenían poca relevancia, como accesibilidad, rendimiento, privacidad, gestión de tráfico, etc.

---

Hay un montón de cosas (como Research) que voy dejando fuera intencionalmente para no sumar líneas a un artículo que me va quedando cada vez más largo.

---

¿Cómo está el panorama ahora mismo?

No muy ordenado pero muy atractivo, como podrás imaginarte.

Prácticamente todas las compañías tenemos lo que se conoce como "Deuda Técnica" y "Deuda de Diseño", millones de páginas en el mundo han envejecido mal. Hemos ido apilando pruebas y tecnologías, y con el paso del tiempo se empiezan a evidenciar más de una decisión de diseño víctima de la moda, y varios lenguajes de código enlazados en un spaghetti que muchas veces es mejor no desenmarañar.

Siguen apareciendo pantallas y puntos de contacto, y hemos tenido que dar un paso atrás y reflexionar sobre lo inviable de seguir diseñando cada micro-interacción de forma granular sin poner en riesgo todo.

Si bien hasta hace relativamente poco ajustar cada diseño "al pixel" estaba bien visto, hoy en día es muy raro sugerir en una sesión de revisión de diseño "subelo 2px para que se vea mejor".

Mirando el lado positivo

Ha pasado mucha agua bajo el puente y ahora somos conscientes de la complejidad del ecosistema digital y de su tendencia natural a la disrupción e inconsistencia.

Hoy contamos con un sistema que nos ayuda a conectar y orquestar las diferentes partes, a tomar decisiones de diseño y programación de una manera fácil. Que nos brinda la capacidad de evolucionar nuestras Apps de manera sostenible, encajando los avances inevitables de la tecnología de manera controlada.

¿Cuáles son las partes de este "Sistema" que lo conecta todo?

Un buen Sistema de Diseño está compuesto de herramientas que permiten llegar a acuerdos de manera ágil, a estar alineados aunque el equipo no esté en la misma sala, a producir rápido productos de calidad consistente de manera eficiente.

Incluye no sólo símbolos reutilizables (UI Kits, Componentes, Tokens, etc), sino también un lenguaje y herramientas compartidas, guías y procesos estandarizados.

Pero las partes aisladas no garantizan un Sistema de Diseño; he oido muchas veces "no hay un Design System a menos que los componentes estén codeados" o todo lo contrario, "¡la clave está en los UI-Kits!".

A mí me gusta enfatizar que cada parte del sistema debe ser relevante para la persona que lo usa: Los símbolos reutilizables son magníficos pero no sirven para nada si están en una tecnología que no usas.

Un diseñador no usa componentes programados en código para diseñar sino símbolos que son fáciles de arrastrar en su herramienta de diseño (un UI Kit).
De la misma manera, rara vez un programador usará una galería de símbolos que están dentro de esa herramienta de diseño (UI Kit) si los componentes ya están disponibles y documentados en un repositorio de código con el que trabaja habitualmente.

Lo cierto es que puedes tener todas las partes y no tener un sistema y puedes tener un sistema que funcione muy bien sin librerías de diseño o componentes.

Puedes tener buen ritmo y agilidad de desarrollo sin una plataforma tecnológica unificada. Es factible lograr que todo se vea y se comporte uniformemente aunque sólo hayas migrado la mitad del código a una tecnología nueva (ya sea React o Vue por citar dos ejemplos).

Del lado de Diseño puedes estar perdiendo el tiempo si inviertes esfuerzo en exportar todos tus colores y tipografías en un formato de código para agilizarle el desarrollo a tus programadores, cuando este no está montado para que los estilos se consuman de esa manera.

En los equipos que se comunican y entienden bien, muchas de las decisiones se toman sin un ordenador a mano. Siempre y cuando un espaciado "talla L" signifique lo mismo para todos (1em, 16px, etc) una pizarra es suficiente.

Un buen Sistema de Diseño ayuda a tomar decisiones, a saber qué hacer en cada momento, no sólo cuando quieres seguir el consenso sino también cuando tienes que desviarte de lo acordado y es por ello que la clave está en el fácil acceso a la documentación.

Un buen Sistema de Diseño está vivo, no sólo evoluciona con el tiempo, se ajusta a las modas y se aprovecha de las nuevas posibilidades de la tecnología, sino que además permite corregir las decisiones incorrectas después de haberlas implementado.

---

Si quieres saber cuáles son los beneficios de un Design System, quizás te interese este otro post: ¿Cuál es el valor de un Sistema de Diseño?

---

¡Saludos!

Turo
DesignOps en Adevinta Spain

Sobre nuestro equipo:
En Adevinta Spain tenemos Sistemas de Diseño para todas nuestras marcas, que incluyen guías de estilo, manuales de colaboración, Tokens, Componentes y UI Kits tanto para Web como para Native Apps.

Echa un vistazo a SUI Components nuestro proyecto de React Open-Source con el que creamos todas nuestras Webs.