<\/p>\n\n\n\n
Durante a\u00f1os hemos trabajado para que el dise\u00f1o pueda escalar. Creamos librer\u00edas, definimos patrones, documentamos componentes, establecemos reglas y construimos Design Systems para evitar que cada equipo tenga que empezar desde cero. Y han funcionado. Un buen Design System puede reducir inconsistencias, facilitar la colaboraci\u00f3n con desarrollo y ayudar a que productos cada vez m\u00e1s grandes mantengan coherencia.<\/p>\n\n\n\n
Pero \u00faltimamente hay una pregunta que me parece mucho m\u00e1s interesante: \u00bfqu\u00e9 pasa con todo lo que aprendimos para llegar a esas decisiones?<\/strong> Porque podemos documentar perfectamente un componente y aun as\u00ed perder una parte importante del conocimiento que existe detr\u00e1s de \u00e9l. Podemos saber c\u00f3mo funciona un modal, cu\u00e1les son sus estados y cu\u00e1ndo utilizarlo, pero quiz\u00e1 no sepamos por qu\u00e9 se decidi\u00f3 as\u00ed, qu\u00e9 problema apareci\u00f3 durante la investigaci\u00f3n, qu\u00e9 alternativa se descart\u00f3, qu\u00e9 sucedi\u00f3 cuando la probamos, qu\u00e9 restricci\u00f3n t\u00e9cnica modific\u00f3 la soluci\u00f3n o qu\u00e9 problema de accesibilidad encontramos.<\/p>\n\n\n\n Cuando ese contexto desaparece, tenemos un sistema capaz de reutilizar soluciones, pero no necesariamente de reutilizar el conocimiento que las produjo. Y con la incorporaci\u00f3n de IA a los procesos de dise\u00f1o y desarrollo, creo que esa diferencia empieza a ser mucho m\u00e1s importante.<\/p>\n\n\n\n Esto sucede constantemente en proyectos grandes. Alguien pregunta por qu\u00e9 determinado flujo funciona de cierta manera y comienza una peque\u00f1a investigaci\u00f3n interna: revisamos Figma, buscamos documentaci\u00f3n, regresamos a tickets, preguntamos a quienes participaron en el proyecto y tratamos de reconstruir una decisi\u00f3n tomada quiz\u00e1 varios a\u00f1os atr\u00e1s. Hasta que alguien termina diciendo: \u201ccreo que se hizo as\u00ed porque\u2026\u201d.<\/p>\n\n\n\n Ese \u201ccreo\u201d<\/strong> dice mucho sobre c\u00f3mo conservamos el conocimiento dentro de los productos. Una enorme cantidad de decisiones importantes termina viviendo en la memoria de las personas y, mientras el equipo permanece relativamente estable, el modelo funciona. El problema aparece cuando los proyectos crecen, los equipos cambian o simplemente pasa el tiempo. Podemos conservar durante a\u00f1os el resultado de una decisi\u00f3n y perder completamente la raz\u00f3n que la origin\u00f3.<\/p>\n\n\n\n Esto provoca algo que he visto repetirse en distintos proyectos: volvemos a discutir problemas que probablemente ya hab\u00edamos resuelto. No necesariamente porque la decisi\u00f3n anterior siga siendo correcta \u2014cuestionarla tambi\u00e9n es parte de dise\u00f1ar\u2014, sino porque muchas veces ni siquiera tenemos suficiente informaci\u00f3n para entender por qu\u00e9 fue tomada.<\/p>\n\n\n\n Hoy podemos pedirle a una IA que genere una interfaz, proponga un flujo o incluso construya parte de un producto utilizando una librer\u00eda existente. La capacidad de producci\u00f3n est\u00e1 avanzando muy r\u00e1pido, pero producir una interfaz y tomar una buena decisi\u00f3n de dise\u00f1o siguen siendo cosas diferentes.<\/p>\n\n\n\n Una IA puede saber que existe un componente, pero no necesariamente por qu\u00e9 deber\u00eda utilizarlo en determinado contexto. Puede conocer nuestros botones, formularios, modales, patrones y tokens, pero para tomar mejores decisiones necesita algo que tradicionalmente ha sido mucho m\u00e1s dif\u00edcil de sistematizar: contexto<\/strong>.<\/p>\n\n\n\n Necesita conocer qu\u00e9 sabemos de nuestros usuarios, qu\u00e9 aprendimos de investigaciones anteriores, qu\u00e9 principios seguimos, qu\u00e9 comportamientos queremos evitar, qu\u00e9 est\u00e1ndares de accesibilidad debemos respetar, qu\u00e9 restricciones tiene el negocio y qu\u00e9 decisiones ya probamos. Tambi\u00e9n necesita saber algo especialmente importante: cu\u00e1les son aquellos escenarios donde automatizar una decisi\u00f3n no es conveniente y seguimos necesitando criterio humano.<\/p>\n\n\n\n Por eso, cada vez pienso m\u00e1s que el siguiente reto de los Design Systems quiz\u00e1 no sea agregar m\u00e1s componentes, sino conservar mejor las decisiones que existen detr\u00e1s de ellos<\/strong>.<\/p>\n\n\n\n Durante mucho tiempo hemos documentado principalmente el resultado: c\u00f3mo funciona un componente, cu\u00e1ndo utilizarlo, qu\u00e9 variantes existen, cu\u00e1les son sus propiedades y qu\u00e9 comportamiento esperamos. Todo eso seguir\u00e1 siendo necesario, pero probablemente tengamos que empezar a conservar tambi\u00e9n otra capa de informaci\u00f3n: por qu\u00e9 funciona de esa manera<\/strong>.<\/p>\n\n\n\n No significa crear documentos interminables para justificar cada decisi\u00f3n. De hecho, eso podr\u00eda producir exactamente el problema contrario: enormes repositorios de informaci\u00f3n que nadie consulta. El reto est\u00e1 en estructurar el conocimiento de manera que pueda ser encontrado, relacionado y utilizado cuando realmente sea necesario, tanto por personas como por sistemas.<\/p>\n\n\n\n Una decisi\u00f3n de dise\u00f1o, por ejemplo, podr\u00eda estar relacionada con una investigaci\u00f3n, una m\u00e9trica, un principio de accesibilidad, una restricci\u00f3n t\u00e9cnica y determinados componentes. Entonces dejamos de tener \u00fanicamente documentaci\u00f3n aislada y empezamos a construir algo mucho m\u00e1s interesante: memoria del producto<\/strong>.<\/p>\n\n\n\n Aqu\u00ed es donde el concepto de inteligencia de dise\u00f1o empieza a tener sentido para m\u00ed. No lo veo necesariamente como una nueva herramienta ni como otro nombre para un Design System, sino como la capacidad de una organizaci\u00f3n para conservar, conectar y reutilizar el conocimiento que genera mientras dise\u00f1a productos<\/strong>.<\/p>\n\n\n\n Un Design System podr\u00eda formar parte de esa inteligencia, pero tambi\u00e9n la investigaci\u00f3n, las decisiones de accesibilidad, los principios de experiencia, los resultados de experimentos, las restricciones conocidas y los patrones que sabemos que funcionan. Incluso deber\u00edan formar parte aquellos que sabemos que no funcionan, porque aprender qu\u00e9 no repetir tambi\u00e9n es conocimiento.<\/p>\n\n\n\n Lo interesante es pensar que esta inteligencia podr\u00eda crecer junto con el producto. Cada investigaci\u00f3n agregar\u00eda contexto, cada prueba aportar\u00eda evidencia, cada problema encontrado a\u00f1adir\u00eda una nueva restricci\u00f3n y cada decisi\u00f3n correctamente documentada reducir\u00eda la posibilidad de que otro equipo tuviera que resolver exactamente el mismo problema desde cero.<\/p>\n\n\n\n Entonces el dise\u00f1o deja de escalar \u00fanicamente porque reutilizamos componentes. Tambi\u00e9n empieza a escalar porque reutilizamos aprendizaje.<\/strong><\/p>\n\n\n\n Durante a\u00f1os hemos intentado mejorar el handoff entre dise\u00f1o y desarrollo utilizando mejores especificaciones, documentaci\u00f3n, Design Systems compartidos, tokens y herramientas que permiten acercar ambos procesos. Hemos avanzado much\u00edsimo, pero seguimos hablando, en cierta medida, de trasladar una decisi\u00f3n desde el lugar donde fue dise\u00f1ada hacia el lugar donde finalmente ser\u00e1 implementada.<\/p>\n\n\n\n La IA puede empezar a reducir todav\u00eda m\u00e1s esa distancia. Si parte de nuestro conocimiento de dise\u00f1o puede vivir cerca del c\u00f3digo, de los componentes y de las herramientas que participan directamente en la construcci\u00f3n del producto, ya no necesitamos traducir constantemente las mismas reglas.<\/p>\n\n\n\n Esto no significa que los dise\u00f1adores tengamos que convertirnos en desarrolladores, pero s\u00ed creo que nuestra relaci\u00f3n con tecnolog\u00eda tendr\u00e1 que ser cada vez m\u00e1s cercana. Entender c\u00f3mo funciona una librer\u00eda de componentes, c\u00f3mo llegan los tokens a producci\u00f3n, c\u00f3mo se estructura un repositorio o c\u00f3mo utiliza contexto una herramienta de IA empieza a ser relevante porque esos son algunos de los lugares donde nuestras decisiones terminar\u00e1n viviendo.<\/p>\n\n\n\n No necesitamos escribir todo el c\u00f3digo, pero cada vez ser\u00e1 m\u00e1s dif\u00edcil dise\u00f1ar sistemas digitales complejos sin entender qu\u00e9 ocurre con nuestras decisiones despu\u00e9s de Figma<\/strong>.<\/p>\n\n\n\n Durante mucho tiempo, escalar dise\u00f1o signific\u00f3 poder producir m\u00e1s sin aumentar proporcionalmente el esfuerzo. Un componente dise\u00f1ado una vez pod\u00eda utilizarse en veinte lugares y un patr\u00f3n pod\u00eda resolver decenas de escenarios. Esa sigue siendo una de las grandes aportaciones de los Design Systems, pero ahora aparece otra posibilidad.<\/p>\n\n\n\n Una investigaci\u00f3n realizada por un equipo podr\u00eda influir en decisiones futuras de otros equipos. Una mejora de accesibilidad podr\u00eda convertirse en una regla que evite repetir el mismo problema en diferentes productos. Una decisi\u00f3n correctamente documentada podr\u00eda seguir ayudando a\u00f1os despu\u00e9s, incluso cuando las personas que originalmente participaron en ella ya no formen parte del proyecto.<\/p>\n\n\n\n En ese escenario, escalar dise\u00f1o no significa solamente reutilizar soluciones. Significa tambi\u00e9n reutilizar criterio.<\/strong> Y creo que esa diferencia puede convertirse en una parte importante de c\u00f3mo entendamos los Design Systems en los pr\u00f3ximos a\u00f1os.<\/p>\n\n\n\n Figma seguir\u00e1 siendo importante. Los Design Systems seguir\u00e1n siendo importantes. Los prototipos, componentes y documentaci\u00f3n tambi\u00e9n. No creo que estemos frente al final de esas herramientas ni que la IA vuelva irrelevante el trabajo que hemos construido alrededor de ellas.<\/p>\n\n\n\n Lo que s\u00ed creo es que la IA est\u00e1 haciendo mucho m\u00e1s visible algo que probablemente siempre estuvo ah\u00ed: el valor del dise\u00f1o nunca estuvo \u00fanicamente en las pantallas que produc\u00edamos<\/strong>. Estaba tambi\u00e9n en las preguntas que hicimos antes de dise\u00f1arlas, en la investigaci\u00f3n que modific\u00f3 nuestras hip\u00f3tesis, en las alternativas que descartamos, en las conversaciones con desarrollo, en los problemas que encontramos y en las decisiones que tomamos como consecuencia de todo ello.<\/p>\n\n\n\n Ese criterio se construye despu\u00e9s de a\u00f1os de dise\u00f1ar, probar, observar resultados, equivocarnos y volver a intentarlo. Sin embargo, una parte importante de ese conocimiento se sigue perdiendo entre proyectos, documentos, archivos y equipos.<\/p>\n\n\n\n Por eso, quiz\u00e1 una de las oportunidades m\u00e1s interesantes de la IA aplicada al dise\u00f1o no sea simplemente permitirnos producir interfaces m\u00e1s r\u00e1pido. Tal vez sea ayudarnos a construir productos y organizaciones capaces de recordar no solamente qu\u00e9 dise\u00f1amos, sino por qu\u00e9 lo dise\u00f1amos de esa manera<\/strong>.<\/p>\n\n\n\n Si conseguimos hacerlo, el siguiente paso de los Design Systems probablemente no ser\u00e1 una librer\u00eda con m\u00e1s componentes. Ser\u00e1 un sistema capaz de conservar m\u00e1s contexto, m\u00e1s aprendizaje y m\u00e1s decisiones.<\/p>\n\n\n\n Un sistema con memoria.<\/strong><\/p>\n\n\n\n Y quiz\u00e1 ah\u00ed empiece realmente lo que podemos llamar inteligencia de dise\u00f1o.<\/p>\n","protected":false},"excerpt":{"rendered":" Durante a\u00f1os hemos trabajado para que el dise\u00f1o pueda escalar. Creamos librer\u00edas, definimos patrones, documentamos componentes, establecemos reglas y construimos\u2026<\/p>\n","protected":false},"author":1,"featured_media":40,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[19,11,15],"class_list":["post-39","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-design-system","tag-diseno","tag-diseno-ux-ui"],"_links":{"self":[{"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/posts\/39","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/comments?post=39"}],"version-history":[{"count":1,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/posts\/39\/revisions"}],"predecessor-version":[{"id":41,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/posts\/39\/revisions\/41"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/media\/40"}],"wp:attachment":[{"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/media?parent=39"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/categories?post=39"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nadiagh.com\/blog\/wp-json\/wp\/v2\/tags?post=39"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Tenemos sistemas que recuerdan componentes, pero no siempre decisiones<\/h2>\n\n\n\n
La IA hace m\u00e1s evidente un problema que ya ten\u00edamos<\/h2>\n\n\n\n
De documentar interfaces a documentar criterio<\/h2>\n\n\n\n
Del Design System a la inteligencia de dise\u00f1o<\/h2>\n\n\n\n
Dise\u00f1o y desarrollo cada vez est\u00e1n menos separados<\/h2>\n\n\n\n
Tambi\u00e9n tendremos que reconsiderar qu\u00e9 significa escalar UX<\/h2>\n\n\n\n
El archivo nunca fue el verdadero entregable<\/h2>\n\n\n\n