DEV Community: Turo López Sanabria

¿Qué hace un equipo de DesignOps?

Turo López Sanabria — Wed, 15 Sep 2021 20:30:17 +0000

Hola 🙋🏻‍♂️
en este artículo encontrarás una visión general de los conceptos clave de DesignOps, un rol fundamental para mejorar la escalabilidad de los equipos de Diseño y sus interacciones con Desarrollo: ¿qué es? ¿qué hace? ¿qué valor aporta?.

DesignOps gestiona recursos, herramientas y procesos con el fin de mejorar la calidad y la eficiencia del proceso de Diseño

Se encarga del funcionamiento operacional del equipo, de lo que pasa en el día a día con todo lo que no sea específicamente diseñar o dirigir equipos, para que cada uno pueda centrarse en hacer su trabajo sin ruido. Con "ruido" me refiero a tareas burocráticas como el mantenimiento de procesos, la exploración y renovación de herramientas o la gestión de Sistemas de Diseño.

¡oh, Sistemas de Diseño! 🥃 chupito

Aunque es un rol que suele relacionarse especialmente con Sistemas de Diseño, el eje central de DesignOps no es este, sino la "escalabilidad", uno de los mayores desafíos a los que se enfrentan las compañías cuando sus equipos de diseño y desarrollo alcanzan un tamaño considerable.

Resuelve la mayoría de los "pains" a los que estos equipos se enfrentan, como:

Colaboración entre diseño y desarrollo
Creación y documentación de nuevos componentes
Estandarización de procesos
Reporte de bugs, defectos y mejoras
Organización de archivos y proyectos
Petición de licencias y acceso a repositorios
etc

Áreas de acción

Si bien es una disciplina relativamente reciente cuyo rol varía de una compañía a otra, nosotros la hemos dividido en 5 grandes focos de acción:

Procesos

DesignOps define e itera procesos comunes que resuelven el “cómo” para que los equipos puedan concentrarse en el “qué” y el “porqué”.

Un ejemplo de esto puede ser la definición de un proceso claro de iteración de componentes (por ejemplo añadir un nuevo tamaño de botón) para que los diseñadores y desarrolladores no tengan que perder tiempo en las tareas burocráticas que conlleva cualquier mejora de diseño y código.

En Adevinta hemos creado guías que tienen en cuenta este proceso de principio a fin: desde el momento en que surge la necesidad de un nuevo tamaño de botón, a la entrega del código final, incluyendo handoff, QA, seguimiento, etc.
Incluye unos pasos claros, templates para desarrolladores en gitHub, plantillas en Figma para diseñadores y consejos para que nada se olvide.

Herramientas

DesignOps promueve y desarrolla herramientas que mejoran la comunicación entre equipos.

Se encarga de explorar proactivamente las últimas tendencias del mercado y valorar el impacto que tendría un eventual cambio.

Un ejemplo reciente es nuestra adopción de Figma, para la cual creamos un plan detallado con todo lo necesario para que cada equipo pudiese seguir centrado en su producto sin la sobrecarga que supuso la migración, desde la coordinación con finanzas, la recreación de UI Kits y un plan de formación para los equipos de diseño y desarrollo, a un período seguro de desconexión de las otras herramientas.

Sistemas de Diseño

DesignOps lidera y coordina los Sistemas de Diseño mejorando la calidad de su implementación y asegurando su adopción, documentación y visibilidad.

En Adevinta tenemos varias actividades y vías relacionadas con Sistemas de Diseño: Creación y mantenimiento de componentes en Figma, React y Aplicaciones Nativas, Dashboards de rendimiento, Mantenimiento de procesos y mejora continua, Tests automáticos, Herramientas de desarrollo, Acciones de visibilidad, Accesibilidad, Reporte y seguimiento de deuda técnica y de UX, etc

Desarrollo profesional

DesignOps ayuda a crear un ambiente de trabajo que favorece el éxito de nuestros diseñadores, entre otras cosas asegurando que todos tengan acceso a los recursos adecuados y actualizados.

Visibilidad

DesignOps ayuda a comunicar el trabajo del equipo dentro y fuera de la organización.

En Adevinta tenemos varios canales de comunicación, tanto activos como pasivos, que ayudan a entender el trabajo del equipo:
Slack channels, Emails, Newsletters, Twitch, Reuniones semanales de alineación y trabajo, Design critiques, Reportes, etc

Espero que esta breve introducción sea util, ayude a entender que el valor de este rol no es "entregar mas rápido"; un equipo de diseño no es, ni debería ser, una cadena de montaje.

He elegido con cuidado las palabras calidad y eficiencia para comenzar este artículo. Todo esfuerzo de DesignOps tiene como objetivo mejorar el terreno para que los diseñadores y sus managers trabajen mejor.

Si quieres saber más sobre DesignOps o Sistemas de Diseño quizás te interesen estos otros artículos de Adevinta Spain

¡Unete a la conversación! Puedes ver y comentar en directo nuestras reuniones semanales de Sistemas de Diseño. Todos los miércoles a las 12:30 en el canal de Twitch de Adevinta Spain

¡Saludos!

Turo
DesignOps en Adevinta Spain

¿Qué es un Sistema de Diseño?

Turo López Sanabria — Tue, 13 Oct 2020 16:12:10 +0000

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:

Un DS es como un Lego: un conjunto de piezas predefinidas, reutilizables y modulares en el que todos los bloques encajan perfectamente.
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.
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.

¿Cuál es el valor de un Sistema de Diseño?

Turo López Sanabria — Mon, 28 Sep 2020 08:14:54 +0000

Esta es quizás la pregunta que se repite con mayor frecuencia entre las personas que entran en contacto con "Sistemas de Diseño". Probablemente la más común después de “¿Qué es un Sistema de Diseño?” ;)

Un Sistema de diseño es una herramienta para mejorar el entendimiento entre los diferentes perfiles que trabajan de manera colaborativa. Es un producto que incluye no solo código y librerías de diseño, sino también un lenguaje compartido, una serie de acuerdos, guías, procesos estandarizados y herramientas comunes.

No es raro haber oído hablar de Sistemas de Diseño, incluso trabajar en una compañía que usa y mantiene uno, y sin embargo no tener claros cuales sus beneficios; al fin y al cabo nos pasa igual con muchos de los productos internos que existen en cualquier organización.

Aunque debería ser fácil de contestar, lo cierto es que no tiene una única respuesta, ya que depende tanto de la calidad y madurez del propio Design System como del tamaño y enfoque del equipo, y el tipo de producto en el cual se implementa.

De cualquier manera he intentado crear una lista genérica con los beneficios más relevantes:

Acuerdo
Agilidad
Alineación
Calidad
Comunicación
Consistencia
Convergencia
Eficiencia
Entendimiento
Foco
Madurez
Velocidad
Persistencia de decisiones
Propósito común

Acuerdo

Un Design System actúa en su conjunto como única fuente de la verdad para las diferentes disciplinas que colaboran en la creación de un mismo producto.

Actúa como contenedor de información sobre decisiones acordadas.
Sirve como referencia accesible y útil en la resolución de discrepancias.

Agilidad

Un Design System facilita la agilidad en producto, al prevenir estancarse en temas ya discutidos, acordados, documentados e implementados.

Distribuye uniformemente entre todos el peso de las tareas de diseño y código.
Permite crear prototipos, experimentos y lanzar MVPs en menor tiempo, asegurando que aspectos como consistencia o accesibilidad no son dejados fuera del producto inicial para cumplir con los tiempos de salida a producción .

Alineación

Un Design System asegura que las diferentes partes del producto están alineadas.

Asegura por naturaleza que el resultado del código está alineado con las guías de Diseño.
Fomenta la unificación de nomenclatura en los archivos de diseño, documentación y código.
Fomenta la unificación de unidades de medida.
Sirve como marco de implementación para mejoras de accesibilidad.

Calidad

Un Design System provee un enfoque sistemático para gestionar la calidad del código y las decisiones de diseño.

Previene la generación de errores que son inevitables al crear algo desde cero.
Previene la repetición de errores
Al estar en constante evolución a través de iteraciones, cada componente va adquiriendo mejor calidad con el tiempo, sobre todo comparado con componentes nuevos.
Al ser un sistema modular, cerrado y versionado, reduce el riesgo de pérdidas tanto en código como en diseño.
Es fácil de aislar para valorar su calidad y medir en su integración externa.
Recibe gestión de calidad constante, la cual además incrementa cuando mayor es la adopción.

Comunicación

Un Design System actúa tanto como canal, como lenguaje de comunicación común para las diferentes disciplinas que colaboran en la creación de un mismo producto.

Provee un foro idóneo donde compartir conocimiento transversal.
Al unificar lenguaje facilita el entendimiento.
Actúa como disparador de conversaciones interdisciplinares.
Previene el bloqueo de tareas de desarrollo por cambios de diseño

Consistencia

Un Design System permite obtener los mismos resultados de calidad a lo largo del tiempo.

Ayuda a que una vez decididos, diseñados y documentados, tanto los diseños como su implementación en código sean iguales cada vez que se reutilizan.

Convergencia

Un Design System agrupa el esfuerzo de todos los perfiles bajo un mismo paraguas.

Fomenta a que los desarrolladores y diseñadores colaboren en una sola dirección para lograr objetivos comunes.

Eficiencia

Un Design System asegura el máximo rendimiento del tiempo invertido en código y diseño, con el mínimo desperdicio de energía para conseguir los mismos resultados.

Mejora el enfoque, minimizando la inversión de tiempo en crear productos desde cero, para usarlo en resolver problemas.
Mejora el código a base de iteraciones, que es más barato comparado con escribir código de calidad desde cero bajo demanda.
Elimina la necesidad de comunicar reiterativamente decisiones de diseño que están documentadas e implementadas.
Libera a los equipos del mantenimiento de código propio, a menudo duplicado.

Entendimiento

Un Design System facilita el entendimiento al proveer una serie de herramientas y recursos que cierran la brecha entre diferentes perfiles.

Documenta procesos acordados.
Elabora y refina un vocabulario común que facilita la comprensión de las especificaciones.
Estandariza canales y procesos para reportar y solucionar problemas.
Ayuda a elaborar un modelo conceptual común del producto en el que se trabaja.
Minimiza la falta de información al reducir la opacidad de las diferentes partes del ecosistema.

Foco

Un Design System despeja el camino de tareas redundantes, facilitando poner foco en lo que realmente importa.

Madurez

Un Design System refleja la madurez de un equipo interdisciplinar.

Permite acelerar la maduración de los equipos.
Requiere tomar decisiones importantes y mejorar procesos que resultan beneficiosos en otras áreas.
Al requerir trabajar de manera colaborativa, fomenta la “polinización” de conocimiento.

Persistencia de decisiones

Un Design System incrementa la duración de las decisiones tomadas.

Previene la volatilidad de la información, despegándola de estar sujeta al puesto de las personas, o su relación con el producto o la compañía.
Define un espacio que protege al código y al diseño de perderse, en un potencial caso de cambio de dirección en cualquiera de las áreas de la compañía.

Propósito común

Un Design System ayuda al propósito común de diferentes disciplinas que colaboran en la creación de un mismo producto.

Alimenta al crecimiento en una sola dirección.
Facilita la puesta en producción de MVPs de alta calidad en diseño, código e interacción.

Velocidad

Un Design System permite tomar decisiones y generar valor más rápido.

Idear es más rápido si el lenguaje visual está claro, existe documentación de marca y guías de estilo.
Plasmar esas ideas en las herramientas de diseño es más rápido si ya existen símbolos y estilos predefinidos en UI Kits.
Compartir especificaciones entre diseñadores y desarrolladores es más rápido si existe un lenguaje común, herramientas compartidas y un proceso claro y acordado.
Traducir esos diseños en código es más rápido si ya existen componentes y estilos listos para producción.
Hacer QA es más rápido si se hace sobre un producto construido con elementos que ya han sido validados.
Reduce el tiempo de incorporación a nuevos miembros al equipo.
Reduce el tiempo que lleva aprender a trabajar con un sistema nuevo.

Quizás te interese este otro post: ¿Qué es un Sistema de Diseño?

¡Saludos!

Turo
DesignOps en Adevinta Spain

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