Sistemas de Diseño, mucho más que componentes

Por Daniel Serrano CEO de Secuoyas

A los sistemas de diseño les pasa como a las brujas, que haberlos haylos…

Los sistemas de diseño se han puesto de moda. Es uno de los temas que más debate está generando en la escena del diseño a nivel global, y por buenos motivos. Un sistema de diseño permite lograr, entre otras muchas ventajas, dos importantes objetivos operativos de negocio, como son la consistencia y la escala.

Consistencia

Diseñar mediante un sistema es una forma de establecer un proceso de trabajo, que facilita una mayor consistencia una vez el sistema empieza a quedar estabilizado. Es relativamente fácil de implementar en equipos pequeños y en start-ups ya que, aunque las reglas sobre el sistema son escasas, y la creación y la intendencia es llevada por una única persona en la mayoría de los casos.

Para algunas start-ups, especialmente cuando están en sus inicios, se trata de un modelo en que se busca reducir costes como principal objetivo de negocio. Lo que la experiencia dicta, es que una empresa de base tecnológica no reduce costes en desarrollo tecnológico, reduce en el diseño. Es comprensible, pues su core es la tecnología, y cuesta más entender que una buena experiencia de usuario no se limita a tener una colección de componentes bonitos que combinan bien.

Por otra parte, dado que estos sistemas simplifican las relaciones entre el diseñador y el equipo que implementa el interfaz, se logra una mejor comunicación entre estos roles. Esto es especialmente relevante para empresas de producto, en las que el modelo de negocio está mucho mejor definido. La consistencia se ve complementada por la eficiencia lograda, y por otra ventaja que es difícil de detectar, poder enfocarse en resolver el problema adecuado, en lugar de un problema que ya está resuelto a nivel de interfaz.

Este tipo de compañías de producto se encuentran con un problema diferente en el momento que empiezan a crecer, y es la escalabilidad del sistema.

Últimamente, la escena del diseño se está llenando de artefactos que logran resolver el problema de la consistencia. Ejercicios hechos aquí, en nuestro país, apuntan a resolver el problema de la consistencia con aproximaciones diferentes, pero convergentes. Sin embargo ninguno logra resolver los problemas relacionados con la escala. La escalabilidad es un problema de una naturaleza muy diferente.

Escala

Una pila de libros puede ser muchas cosas, en función de su contexto y de las reglas de uso que se apliquen a la colección. En función de si esa pila de libros está en una estantería de salida en una imprenta, o en una librería, listos para ser embalados y enviados en una caja a su comprador en un almacén de Amazon, se van a aplicar una serie de reglas a esos libros que los convierten en distintas tipologías de entidades. Son esas reglas de negocio, por tanto, las que convierten a la misma pila de libros en una entidad diferente.

Si esa misma pila está en una estantería de mi casa, se convierten en parte de mi colección. En ese contexto, hay otra serie de reglas que, en este caso, determino yo de forma implícita o explícita. En mi casa, un libro se firma al llegar, se coloca por proximidad a otros libros según una clasificación que yo defino, y hay una fuerte resistencia al préstamo, lo cual evita cualquier posible consideración de mi colección como una biblioteca.

Mis múltiples mudanzas han mermado mi colección hasta unos 60 libros, por lo que en mi caso, el problema de escala, como en el caso de las start-ups que están empezando, no existe.

Para que en la Biblioteca de mi Alma Mater puedan gestionar unos 2,7 millones de documentos, o hasta 32 millones de documentos, como es el caso de la biblioteca nacional , las reglas de gobierno se hacen mucho más rígidas, explícitas, y complejas. La biblioteca dispone de procesos definidos para solicitar la adquisición de libros (proceso nada baladí), recepcionar, preparar y marcar, introducir en el sistema de registro, conservar, exponer,… A mayores, aparecen otras entidades que también hay que gestionar, como por ejemplo los usuarios del sistema, ya sean lectores o bibliotecarios.

Por tanto, si las reglas de cómo se gestionan esos elementos o componentes del sistema no están definidas, el “sistema” no puede clasificarse más que como una colección, y ese es el principal problema de los artefactos que nos inundan vestidos con el nombre de sistemas de diseño.

La primera regla básica en el escalado de un sistema en un producto digital consiste en la creación de una taxonomía adecuada y de la ontología asociada que se deberá crear a medida que se piensa en la necesidad de cubrir múltiples plataformas. Se trata de establecer un lenguaje común, y una organización asociada que permita trabajar con el sistema.

El ciclo de vida, el estado de flujo del sistema

Además, un sistema de diseño debe considerar la gestión del ciclo de vida de sus componentes. Por tanto, no sólo debe considerar el proceso de creación y clasificación. Procesos como los de distribución, versionado, actualización, y retirada son críticos, determinando la robustez del sistema.

Un mal diseño del ciclo de vida, dificulta la implementación y mantenibilidad adecuada del sistema, e induce un auténtico ejercicio de malabarismo a realizar entre el product manager, diseño, y desarrollo. La falta de dichos procesos impiden la escalabilidad.

Dependencias

Una de las principales características de un sistema de diseño es que se puede construir nuevos componentes con elementos ya existentes en el sistema. En un sistema pequeño, mantener estas relaciones resulta manejable, pero a medida que el sistema crece en tamaño, aparecen complicaciones y se hace necesario establecer reglas de orden y gobierno.

Las dependencias son un problema a tener en cuenta desde el inicio, pues van a existir dos procesos similares y complementarios durante la creación y mantenimiento del sistema: la creación de componentes y la actualización o iteración de los mismos.

Solo un trabajo profundo sobre estas dependencias, tanto de composición como de estado permite crear las reglas apropiadas para asegurar un correcto funcionamiento del sistema.

La realimentación

La clave de todo sistema para que pueda controlarse es la realimentación. En un sistema de diseño, la realimentación ha de pasar entre los miembros que trabajan en dicho sistema, y por tanto es crítica la integración entre la creación y la implementación, entre diseño y desarrollo.

Estos procesos, además han de tenerse en cuenta a las distintas escalas de funcionamiento, fundamentalmente por las dependencias existentes anteriormente mencionadas.

Los retrasos

Todo proyecto se ve sometido una implacable fuerza disruptora: los retrasos inducidos en los flujos de feedback. Este problema se vive con dolor en cualquier tipo de proyecto creativo, y en el diseño de un sistema es aún más crítico, porque en realidad existen numerosos procesos de realimentación, aunque no seamos conscientes de su presencia o efecto.

Es importante, para garantizar un correcto funcionamiento y crecimiento, detectar y minimizar estos retrasos. La filosofía ágil en desarrollo, en realidad, trata de detectar y minimizar estos retrasos en el flujo de la información.

Por tanto, los sistemas están gobernados por reglas y patrones que hay que considerar para que el sistema no entre en modo de bloqueo o de resonancia, estados a los que suelen verse abocados este tipo de iniciativas. Para lograr el correcto funcionamiento, hay que entender todo lo que interactúa con el sistema, y que transciende los componentes.

Capacidades y Cultura

Construir un sistema de diseño no consiste en entregar una documentación en un un momento del desarrollo de un proyecto o producto. Construir el sistema de diseño implica un esfuerzo permanente de aprendizaje y mejora contínua dentro de la organización.

Es obvio decirlo, pero entender bien los roles de los distintos usuarios de un sistema de diseño es crucial para hacer un correcto diseño del mismo. Es el punto de inicio para cualquier producto digital, y no lo es menos para un sistema. Con toda seguridad, a medida que el proceso de diseño e implementación avance, aparecerán nuevos roles y necesidades asociadas.

Las capacidades a aportar para el arranque y puesta en servicio del sistema, en forma de personas, procesos y herramientas, mutarán en el tiempo. También lo harán durante la fase de madurez del sistema, aunque a distinta velocidad. La cultura de una empresa influye directamente en cada una de esas fases del ciclo de vida del sistema, así como en las transiciones entre dichas fases.

En Secuoyas, hemos tenido que resolver problemas asociados a distintos puntos de madurez de producto digital de nuestros clientes. Para clientes como La Razón, la transformación del front de su medio digital no se entiende aún como una necesidad fundamental de negocio, por lo que el trabajo consistió en implantar un sistema que perdurase en el tiempo tanto como fuese posible, maximizando el número de opciones disponibles. En Solera, por ejemplo, iniciamos la colaboración en una fase muy inicial, sembrando un modelo de trabajo y definiendo los primeros procesos. El liderazgo ahora es totalmente del equipo de diseño de Solera, — leed el artículo de David, merece cada segundo que le dediquéis — y nuestro rol ha pasado a ser el de colaborar en hacerlo escalar. En el caso del Instituto de Empresa, el time-to-market era crítico, pero el modelo de trabajo pivotando sobre un producto era novel.

La experiencia que hemos acumulado en Secuoyas colaborando en distintos sistemas de diseño para nuestros clientes nos ha permitido condensar muchos aprendizajes; nos ha permitido ir confeccionando distintos modelos, métodos y elementos que nos permiten comprender el problema, y proponer soluciones adaptadas.

Recapitulando

En definitiva, una colección de componentes interactivos o elementos gráficos no es un sistema de diseño. Para que esa colección constituya un sistema, deben estar establecidas las reglas, los procesos por los que los componentes del sistema se relacionan entre sí, así como con las personas, en todos sus roles, que van a usar dicho sistema. Además, un sistema de diseño ha de establecer las normas que gobiernan el ciclo de vida de los componentes del sistema.

El impacto que tiene un sistema de diseño en una organización, entendido como un producto en sí mismo, es tremendo, pues requiere de un profundo cambio de mentalidad. Requiere de un cambio en el modelo de trabajo y de relaciones de personas, roles y tareas.

Next steps

Hace aproximadamente un año y medio que en Secuoyas montamos una célula de innovación entorno a los Sistemas de Diseño. Nuestra forma de trabajar orientada a producto nos empujaba a trabajar de una forma en que explorábamos e integrábamos muchos de los conceptos expuestos. Por tanto, tenía lógica que unificásemos internamente esa visión y las herramientas que estaban surgiendo como solución local a algunos de estos problemas.

Unos de los grandes aprendizajes, es que nuestro sistema de diseño debe ser un META sistema.

Stay tuned…

Ilustraciones: Madeline Honingford