¿Realmente necesitamos un Design System?

Si bien hemos visto todos los beneficios que le puede traer el desarrollo de un design system a un equipo de diseño y a la empresa para la cual trabaja, es cierto que esto implica una inversión de tiempo, dinero y recursos para nada trivial.

Entonces surgen las preguntas: ¿Esto es para nosotros? ¿De qué nos va a servir? ¿Esto no es algo para empresas grandes? ¿Podemos invertir tiempo en esto cuando hay otras 100 cosas que resolver antes? ¿No es mejor enfocarnos en desarrollar nuevas features antes que en hacer esto que no lo pidió nadie? Y la respuesta es: depende.

Partamos de un punto de consenso: un design system no va a solucionar el 100% de los problemas de un equipo de diseño y desarrollo. Pero puede ser de gran ayuda para cierto tipo de equipos y de situaciones, así que acá van algunas recomendaciones sobre cómo evaluar nuestro entorno real de trabajo y decidir si un design system puede o no ayudarnos a mejorar nuestro día a día.

Evaluando

Antes de empezar, hay que tener en cuenta qué tipo de problemas puede resolver un design system. Y revisar si esos son realmente el tipo de inconvenientes que tiene nuestro equipo, o si estamos tratando de usar un enfoque equivocado. Recordemos que no todos los problemas son clavos, ni todas las herramientas martillos.

Un design system puede servirnos especialmente para encarar cuestiones relacionados con la consistencia en la experiencia de los usuarios, con la eficiencia de los equipos de trabajo y con la escalabilidad de nuestras iniciativas digitales. Si los problemas que encontramos en nuestro entorno de trabajo giran alrededor de alguna de estas temáticas, vamos por buen camino con la solución que estamos estudiando. Para definir esto, propongo que nos hagamos algunas preguntas.

Cuestionando nuestro producto

Una primera tanda de preguntas posibles alrededor de nuestros productos incluye ¿Cuántos productos digitales tenemos? ¿Pertenecen todos a la misma familia? ¿Están todos apuntados al mismo público? ¿Qué tan parecidos son entre ellos? ¿Qué similitudes queremos mantener y en qué es mejor que se diferencien? ¿Cómo va a crecer esta cartera de productos? ¿Existen inconsistencias, cosas que sabemos que deberían verse iguales en todos y no es así? ¿Estamos evaluando hacer un rediseño global en el futuro cercano?

Si las respuestas apuntan a que trabajamos con un grupo numeroso de aplicaciones, con muchas similitudes en cuanto a su resolución visual y la experiencia deseada para el usuario, y con algunas diferencias puntuales que permitan diferenciar unos de otros, ¡bingo! tenemos un proyecto candidato a ser mejorado con un design system. También lo sería si es un solo producto pero muy extenso, con muchas secciones, páginas o vistas que tienen que mantener características en común para no desorientar al usuario.

Pensemos en la suite de herramientas digitales de Google como ejemplo: Docs, Drive, GMail, Meet, Calendar, Photos, Chat, Forms… Estas aplicaciones tienen múltiples elementos en común que es conveniente que sean consistentes y homogéneos: iconos asociados a acciones, sistema de navegación, menús, formas de acceso al perfil del usuario, ubicación de las opciones de configuración, dinámica de navegación entre páginas. Si no se trabajara con un sistema robusto por detrás, se corre el riesgo de que alguna de las aplicaciones se salga de la norma, y las inconsistencias en la interface confundan a los usuarios de la plataforma. Mientras menos hagamos pensar y dudar a nuestros usuarios, más aumentará su confianza en nuestro producto.

Conocer los planes de crecimiento del producto también es útil para este tipo de evaluación. Si se presupone que este va a aumentar su alcance en el corto plazo, agregando secciones o funcionalidades, o que se van a incorporar otros miembros a la familia de productos, son buenos justificativos para invertir en la creación de un design system antes de que esta expansión suceda, preparando el terreno para que sea prolija y ordenada.

Una última cosa a tener en cuenta respecto de nuestro producto en sí, tiene que ver con el estadio en el ciclo de vida del mismo. Una aplicación digital pasa por diferentes etapas a lo largo de su existencia, comenzando en general con una naturaleza muy inestable y cambiante, momentos en los cuales aún se está definiendo la funcionalidad básica, las estructuras generales y el tipo de clientes con los interactúa. En esa etapa, no es muy recomendable comenzar un proceso de consolidación de un design system, ya que nadie podría pronosticar a ciencia cierta cuál será la forma futura del producto ni sus necesidades puntuales (lo que suele metaforizarse como no trates de limpiar la casa si la fiesta aún no termina). Con el paso del tiempo, se pueden establecer con mayor seguridad aquellas partes y componentes de la aplicación que se revelan como las más importantes, y empiezan a emerger patrones de uso en común, lo que nos da una idea clara de por donde comenzar a estandarizar nuestro producto y nuestros procesos. Probablemente, en esa primera etapa, sea más útil establecer algunas bases de comunicación y consistencia mínimas, y no preocuparnos por armar un design system completo.

Analizando nuestro equipo

También tenemos que hacernos preguntas acerca del equipo y la forma de trabajo que mantenemos, por ejemplo ¿Cuántos miembros tiene nuestro equipo?¿Esperamos crecer de forma rápida en el próximo tiempo? ¿Tenemos un solo equipo desarrollando todo o el trabajo en la aplicación está repartido?¿Hay equipos externos a la empresa trabajando para nosotros? ¿Tenemos alta rotación de personal?

Si somos tres personas trabajando solas, que nos conocemos de toda la vida, que podemos terminar las frases de los otros antes de que las digan, y no pensamos ampliar el equipo, no tiene (mucho) sentido invertir en un desarrollo cuya finalidad última es mejorar la documentación y la comunicación.

Ahora, si todo apunta a que tenemos (o vamos a tener) un equipo grande, disperso o descentralizado, un design system puede colaborar mucho en mejorar la comunicación, democratizar el conocimiento y acelerar el onboarding de nuevos miembros. Yo soy de los que opinan que la naturaleza del equipo es aún más determinante que la naturaleza del producto a la hora de pensar si nos va a beneficiar o no desarrollar un design system.

Algo típico que sucede en las startups tecnológicas, es que el proyecto se inicia con un equipo muy chico, a veces de 3 o 4 personas: este equipo tiene la idea inicial, construye las primeras versiones, consigue clientes, itera, mejora el producto, y un día encuentran su nicho ideal de mercado o consiguen una ronda de inversión que implica hacer crecer el producto de manera exponencial, para lo cual salen a contratar gente. Y contratar mucha gente, no siempre significa hacer crecer mucho el producto. Los recién llegados necesitan capacitación, onboarding, entender cómo funciona la empresa y cómo trabaja el equipo para poder sumarse a él de la manera más eficiente. Ese es el momento en el que tener toda o gran parte de la documentación de trabajo centralizada, ayuda muchísimo a los miembros del equipo que tienen que dar las capacitaciones a los recién llegados, y también a los ingresantes, que encuentran un recurso prolijo y claro para entender algunos de los principios por los cuales se rige la empresa.

Revisando nuestro workflow

Finalmente, es útil hacernos algunos cuestionamientos acerca de nuestra manera de trabajar, nuestra forma de llevar adelante los proyectos y los inconvenientes que solemos encontrar en el camino: ¿Hay partes de nuestro producto que han sido desarrolladas más de una vez por diferentes equipos?¿Sentimos que reinventamos la rueda cada semana? ¿Encontramos problemas puntuales de implementación de forma repetitiva? ¿Pasamos mucho tiempo tomando decisiones triviales? ¿Tenemos casos habituales de “eso lo hicimos alguna vez pero nadie sabe dónde está”? ¿Gran parte del día a día de los diseñadores consiste en corregir las implementaciones que hacen los desarrolladores?

La respuesta afirmativa a cualquiera de estas preguntas indica una organización en la que los equipos trabajan divididos en silos, donde la información no fluye y donde no existe una fuente de documentación y consulta fiable. Un design system no hace magia, pero ayuda mucho en estos casos en que, por estar descentralizado y repartido el desarrollo del producto, son muy informales los criterios para la toma de decisiones y es complicado saber que están haciendo los miembros de los demás equipos.

Evitar el retrabajo debería ser uno de los principales objetivos detrás de un equipo de design system. El costo real de hacer dos veces la misma cosa, una y otra vez, es difícil de medir. Pero tengamos en cuenta que consume el tiempo de los diseñadores volviendo a tomar decisiones ya tomadas, de los desarrolladores programando nuevamente componentes que ya estaban hechos, y de los analistas y testers revisando y evaluando cosas que ya habían sido aprobadas. Además, dos componentes desarrollados son a la larga dos componentes para mantener, versionar y actualizar.

Cualquier equipo con problemas de workflow que se manifiestan en errores recurrentes y mucho tiempo de soporte a la implementación puede ser mejorado con la inclusión de un design system.

¿Hay compromiso?

No quiere dejar de hablar de la importancia que tiene el nivel de compromiso del equipo en el desarrollo de un design system. Un design system no debería ser es el proyecto de un líder todopoderoso, ni una ley que emana de una suerte de gurú infalible. Es una construcción colectiva que debe ser constantemente alimentada y cuidada por todos.

Podemos entenderlo como un contrato implícito entre las diferentes “patas” que hacen al desarrollo de un producto digital. Por este contrato, el diseñador se compromete a utilizar ese set de componentes siempre que se pueda; el desarrollador, a que esos elementos que ya fueron programados y aprobados, van a verse y funcionar siempre de la misma manera en todas las situaciones; los encargados del producto y el negocio, a entender que si hacen requerimientos que no están contemplados por el sistema, consumen más tiempo del equipo y, por lo tanto, más dinero.

Aún teniendo un design system super amplio, con cientos de variaciones ya desarrolladas, testeadas y aprobadas, podemos encontrarnos en un equipo que no esté dispuesto a respetar el compromiso asumido: diseñadores que prioricen expresar su voluntad y propongan resoluciones siempre diferentes a los mismos problemas; desarrolladores que prefieran hacer su propia versión de un componente antes que usar algo hecho por otra persona; o managers que pidan modificaciones particulares sin tener en cuenta la necesaria extensión en los tiempos de desarrollo.

Entonces es bueno relevar antes de comenzar, el grado de involucramiento y conocimiento acerca de los beneficios de un design system que existe entre todos los involucrados en el proceso (diseñadores, desarrolladores, managers), para no darnos después de meses de trabajo con que tenemos un sistema hermoso, pero que nadie usa ni respeta.

Entonces, ¿hacemos un design system o no?

Embarcarse en el desarrollo de un design system no debería ser una decisión tomada a la ligera. Si bien existen múltiples atajos para acelerar el proceso y tener lo antes posible un set de componentes modulares para trabajar, el principal cambio que se debe dar es en el modo de trabajo de las personas. Y como todo cambio en los hábitos, lleva tiempo y esfuerzo poder implementarlo.

Hacerse todas las preguntas planteadas aquí constituye una buena guía para poder alinear expectativas y no cometer el error de pretender que un design system corrija todos los problemas de un producto o de un equipo de desarrollo.

Entonces, resumiendo: mi recomendación es que encaremos el proceso de construir un design system cuando tenemos un producto amplio (o en franco crecimiento), un equipo extenso, distribuido o en crecimiento, o un workflow con problemas de errores repetidos, retrabajo o gaps comunicacionales. Antes de comenzar el proyecto, verifiquemos que existe buy in por parte de la dirección, y que hay un compromiso de respetarlo por parte de todas los miembros involucrados (o que al menos se entiendan los trade off de no utilizarlo).

Por el contrario, que no es tan urgente el desarrollo de un design system si nuestro producto es muy limitado, nuestro equipo es chico y está bien comunicado, y nuestro workflow funciona dentro de todo bien. Tampoco recomiendo iniciar el proceso si el producto está en una etapa de exploración y no está claro hacia donde se desarrollará. Finalmente, no lo haría si no existe un compromiso por parte de los otros miembros del equipo involucrados de respetar los acuerdos. En este último caso, empezaría con un trabajo de sensibilización (mostrar ejemplos del trabajo de otros empresas al equipo, presentar los beneficios esperados a los stakeholders) antes que con el desarrollo del sistema en sí.

Un design system es una herramienta muy poderosa, pero solo cuando se lo usa para solucionar los problemas correctos.