[{"data":1,"prerenderedAt":1057},["ShallowReactive",2],{"blog-lo-que-aprendi-construyendo-design-systems-y-que-haria-diferente-es":3},{"post":4,"surround":558,"translatedPost":569},{"id":5,"title":6,"author":7,"body":8,"date":540,"dateModified":541,"description":542,"extension":543,"img":544,"meta":545,"navigation":546,"path":547,"published":546,"readingTime":548,"seo":549,"sitemap":550,"slug":544,"stem":551,"tags":552,"union":556,"__hash__":557},"blog_es\u002Fes\u002Fblog\u002Flo-que-aprendi-construyendo-design-systems-y-que-haria-diferente.md","Lo que aprendí construyendo Design Systems y que haría diferente","Sergio Azócar",{"type":9,"value":10,"toc":517},"minimark",[11,16,37,60,66,73,76,80,83,102,105,112,116,123,126,129,132,137,142,153,157,162,172,176,181,191,195,200,210,214,219,229,233,238,245,249,254,261,265,281,284,287,319,322,354,361,365,391,404,408,411,418,421,453,458,462,465,509],[12,13,15],"h2",{"id":14},"qué-es-un-design-system","¿Qué es un Design System?",[17,18,19,20,24,25,28,29,32,33,36],"p",{},"En simple, es una colección de ",[21,22,23],"strong",{},"reglas",", ",[21,26,27],{},"componentes"," y ",[21,30,31],{},"directrices"," que actúan como una ",[21,34,35],{},"única fuente de la verdad"," para diseñar y construir interfaces.",[17,38,39,40,24,43,28,46,49,50,24,53,24,56,59],{},"Un buen Design System define desde los ",[21,41,42],{},"colores",[21,44,45],{},"tipografías",[21,47,48],{},"espaciados",", hasta cómo deben comportarse los ",[21,51,52],{},"botones",[21,54,55],{},"formularios",[21,57,58],{},"alertas",", y más. Pero va mucho más allá de lo visual: también establece cómo se comunican diseño y desarrollo, cómo se documentan los patrones y cómo evoluciona el producto de forma consistente.",[61,62,63],"blockquote",{},[17,64,65],{},"La idea es que todo el equipo hable el mismo idioma, diseñe más rápido y construya productos que se sientan coherentes, sin reinventar la rueda en cada pantalla.",[17,67,68,69,72],{},"No es solo una librería de componentes. Es una forma de trabajar que busca ",[21,70,71],{},"alinear diseño, código y experiencia de usuario",".",[17,74,75],{},"Más adelante voy a entrar en detalle sobre cómo lo construí y qué aprendí, pero primero quiero contarte cómo fue enfrentarme a esta idea desde cero.",[12,77,79],{"id":78},"cómo-terminé-construyendo-design-systems","Cómo terminé construyendo Design Systems",[17,81,82],{},"Después de trabajar en distintos proyectos y equipos, empecé a notar patrones que se repiten constantemente:",[84,85,86,90,93,96,99],"ul",{},[87,88,89],"li",{},"El mismo botón diseñado de tres formas distintas",[87,91,92],{},"Comportamientos inconsistentes en componentes similares",[87,94,95],{},"Código duplicado o difícil de mantener",[87,97,98],{},"Malentendidos entre diseño y desarrollo",[87,100,101],{},"Interfaces que se veían bien en Figma, pero no en producción",[17,103,104],{},"Cada vez que un producto crecía, también lo hacía el caos visual y técnico. Y con él, el tiempo que perdíamos resolviendo los mismos problemas una y otra vez.",[17,106,107,108,111],{},"Ahí fue cuando entendí que necesitábamos algo más que una librería de componentes. Necesitábamos una ",[21,109,110],{},"forma compartida de construir interfaces",", con reglas claras, decisiones centralizadas y una fuente de la verdad para todos los equipos.",[12,113,115],{"id":114},"expectativa-versus-realidad","Expectativa versus realidad",[17,117,118,119,122],{},"¿Te acuerdas cuando en el colegio te tocaba hacer un trabajo en grupo?",[120,121],"br",{},"\nCada uno hacía su parte por separado, lo juntaban todo al final… y el resultado era un verdadero \"Frankenstein\".",[17,124,125],{},"Bueno, construir un Design System se siente muchas veces así.",[17,127,128],{},"Al principio crees que va a ordenar todo, que unirá diseño y desarrollo como por arte de magia. Pero en la práctica, aparecen los malentendidos, los atajos, las decisiones cruzadas, y lo que debería ser un sistema coherente empieza a desarmarse.",[17,130,131],{},"Estas fueron algunas de las diferencias más marcadas que viví entre lo que imaginaba… y lo que realmente pasó:",[133,134,136],"h3",{"id":135},"expectativa-1","Expectativa 1:",[61,138,139],{},[17,140,141],{},"“Voy a crear una librería de componentes reutilizables y el equipo la va a usar feliz.”",[17,143,144,147,149,150,152],{},[21,145,146],{},"Realidad:",[120,148],{},"\nAlgunos devs la ignoran, otros la rompen, otros no saben cómo usarla.",[120,151],{},"\nSin documentación, onboarding y soporte interno, nadie la adopta como esperas.",[133,154,156],{"id":155},"expectativa-2","Expectativa 2:",[61,158,159],{},[17,160,161],{},"“El diseño está en Figma, así que solo tengo que replicarlo.”",[17,163,164,166,168,169,171],{},[21,165,146],{},[120,167],{},"\nEl diseño no contempla estados, errores, focus, interacción, loading...",[120,170],{},"\nTerminé tomando muchas decisiones técnicas que no estaban definidas.",[133,173,175],{"id":174},"expectativa-3","Expectativa 3:",[61,177,178],{},[17,179,180],{},"“Una vez que los componentes están hechos, no hay que tocarlos más.”",[17,182,183,185,187,188,190],{},[21,184,146],{},[120,186],{},"\nEl diseño evoluciona, aparecen nuevos requerimientos, y cada cambio afecta múltiples partes del sistema.",[120,189],{},"\nUn Design System necesita mantenimiento constante.",[133,192,194],{"id":193},"expectativa-4","Expectativa 4:",[61,196,197],{},[17,198,199],{},"“Voy a crear componentes genéricos y reutilizables para todo.”",[17,201,202,204,206,207,209],{},[21,203,146],{},[120,205],{},"\nComponentes ultra flexibles terminan siendo difíciles de mantener, testear o entender.",[120,208],{},"\nA veces es mejor tener variantes claras que un solo componente con 15 props.",[133,211,213],{"id":212},"expectativa-5","Expectativa 5:",[61,215,216],{},[17,217,218],{},"“Diseño y desarrollo van a trabajar como un solo equipo.”",[17,220,221,223,225,226,228],{},[21,222,146],{},[120,224],{},"\nSin procesos claros y un lenguaje común, aparecen malentendidos todo el tiempo.",[120,227],{},"\nColaborar no es automático: hay que construir puentes intencionalmente.",[133,230,232],{"id":231},"expectativa-6","Expectativa 6:",[61,234,235],{},[17,236,237],{},"“Con Tailwind puedo hacer todo sin un Design System.”",[17,239,240,242,244],{},[21,241,146],{},[120,243],{},"\nTailwind ayuda, pero sin decisiones de diseño compartidas, tokens y una estructura clara, tu proyecto igual se vuelve inconsistente.",[133,246,248],{"id":247},"expectativa-7","Expectativa 7:",[61,250,251],{},[17,252,253],{},"“En unas semanas tengo el sistema listo.”",[17,255,256,258,260],{},[21,257,146],{},[120,259],{},"\nUn Design System no se termina. Es un sistema vivo que crece, se adapta y necesita evolucionar junto a tu producto.",[12,262,264],{"id":263},"necesidades-de-diseño-y-desarrollo","Necesidades de Diseño y Desarrollo",[17,266,267,268,271,272,275,276,280],{},"Cuando te enfrentas a crear un Design System (ya sea desde cero o a partir de una base existente) siempre aparecen dos caras de la misma moneda: lo que quiere y necesita tanto ",[21,269,270],{},"Diseño"," cómo ",[21,273,274],{},"Desarrollo",". Es ahí donde empiezan todos los ",[277,278,279],"del",{},"problemas"," desafíos.",[17,282,283],{},"Para contextualizar un poco analicemos las necesidades de cada equipo.",[133,285,270],{"id":286},"diseño",[84,288,289,295,301,307,313],{},[87,290,291,294],{},[21,292,293],{},"Consistencia visual",": Un lenguaje visual unificado (colores, tipografías, espaciados, iconografía, etc.).",[87,296,297,300],{},[21,298,299],{},"Velocidad y eficiencia",": Poder diseñar interfaces sin reinventar los mismos componentes cada vez.",[87,302,303,306],{},[21,304,305],{},"Escalabilidad de diseños",": Que lo que funciona en una pantalla también funcione en otras (web, mobile, responsive...).",[87,308,309,312],{},[21,310,311],{},"Tokens de diseño claros y reutilizables",": Definición técnica de colores, tamaños, fuentes, z-index, etc.",[87,314,315,318],{},[21,316,317],{},"Relación directa con la implementación",": Que lo que diseñan se vea igual en producción.",[133,320,274],{"id":321},"desarrollo",[84,323,324,330,336,342,348],{},[87,325,326,329],{},[21,327,328],{},"Reutilización real de componentes",": Librería estable, bien documentada y fácil de usar.",[87,331,332,335],{},[21,333,334],{},"Consistencia funcional y técnica",": Mismos patrones de props, slots, estados, accesibilidad, validación, etc.",[87,337,338,341],{},[21,339,340],{},"Facilidad de mantenimiento",": Código limpio, con nombres claros, tests, y sin lógica duplicada.",[87,343,344,347],{},[21,345,346],{},"Documentación viva",": Storybook o similar, con ejemplos reales, no solo teoría.",[87,349,350,353],{},[21,351,352],{},"Adaptabilidad a contextos distintos",": Que un botón (por ejemplo) funcione igual en cualquiera de las aplicaciones que tenemos.",[17,355,356,357,360],{},"Cada equipo tiene sus propias necesidades y prioridades, pero para que un Design System funcione, ",[21,358,359],{},"deben trabajar en conjunto",", tomando decisiones basadas en definiciones compartidas. Ahí es donde deben aprovechar al máximo los puntos de unión entre ambos mundos.",[133,362,364],{"id":363},"necesidades-mutuas-el-punto-de-equilibrio","Necesidades mutuas, el punto de equilibrio",[84,366,367,373,379,385],{},[87,368,369,372],{},[21,370,371],{},"Lenguaje común",": Tokens, nombres de componentes, variantes, estados. Todos deben hablar el mismo idioma.",[87,374,375,378],{},[21,376,377],{},"Proceso de diseño–desarrollo fluido",": Entregas claras desde Figma (o lo que usen), handoffs eficientes, feedback mutuo.",[87,380,381,384],{},[21,382,383],{},"Versionado y control de cambios",": Para que los cambios en diseño se puedan implementar y comunicar sin romper el resto del sistema.",[87,386,387,390],{},[21,388,389],{},"Adopción transversal del sistema",": Que no se quede en un equipo. Tiene que ser fácil de usar y entender por todos.",[61,392,393],{},[17,394,395,396,399,400,403],{},"En resumen, un Design System necesita ser lo suficientemente ",[21,397,398],{},"cerrado"," como para respetar las definiciones de diseño sin permitir cambios visuales arbitrarios, pero también lo suficientemente ",[21,401,402],{},"flexible"," como para extenderse y adaptarse sin romper nada.",[12,405,407],{"id":406},"cómo-lograr-la-adopción-del-sistema","Cómo lograr la adopción del sistema",[17,409,410],{},"Tener un Design System técnicamente impecable no sirve de mucho si nadie lo usa.",[17,412,413,414,417],{},"Uno de los mayores desafíos no es construir el sistema, sino lograr que el equipo lo adopte de verdad. Y no me refiero solo a “que lo conozcan”, sino a que ",[21,415,416],{},"lo integren en su día a día",", lo respeten, lo cuestionen y lo mantengan vivo.",[17,419,420],{},"Algunas cosas que me funcionaron (y otras que aprendí a la fuerza):",[84,422,423,429,435,441,447],{},[87,424,425,428],{},[21,426,427],{},"Involucrar desde el inicio",": Si el sistema se construye entre unos pocos, alejado del equipo, va a generar rechazo. Mientras más voces participen desde el comienzo, más pertenencia genera.",[87,430,431,434],{},[21,432,433],{},"Mostrar valor rápidamente",": Un componente útil, bien documentado y fácil de usar vale más que una promesa de “algún día vamos a tener todo ordenado”.",[87,436,437,440],{},[21,438,439],{},"Documentar con empatía",": No es solo escribir cómo usar un componente, es pensar en cómo lo entenderá alguien que llega por primera vez. Ejemplos reales, capturas, casos de uso, FAQs... todo suma.",[87,442,443,446],{},[21,444,445],{},"Dar soporte interno",": Si alguien tiene un problema con un componente, tiene que haber una forma rápida de resolverlo. Slack, issues, pair programming... lo que sea, pero que no sientan que están solos y sobre todo, un flujo claro de como reportar los errores.",[87,448,449,452],{},[21,450,451],{},"Celebrar el uso",": Cuando alguien adopta un componente, lo mejora o reporta un bug, hay que celebrarlo. Pequeños reconocimientos hacen que el sistema se vea como algo vivo, colaborativo y útil.",[61,454,455],{},[17,456,457],{},"La adopción no es un evento, es un proceso. Y requiere tiempo, paciencia y mucha comunicación.",[12,459,461],{"id":460},"lecciones-aprendidas-y-recomendaciones","Lecciones aprendidas y recomendaciones",[17,463,464],{},"Después de todo este proceso, me quedo con varias ideas que ojalá hubiese sabido antes:",[84,466,467,473,479,485,491,497,503],{},[87,468,469,472],{},[21,470,471],{},"Un Design System no es un proyecto, es un producto",". Y como todo producto, necesita investigación, diseño, mantenimiento, comunicación y evolución.",[87,474,475,478],{},[21,476,477],{},"Empieza por lo que más duele",": No intentes resolver todo desde el día uno. Identifica qué está causando más fricción hoy y empieza por ahí.",[87,480,481,484],{},[21,482,483],{},"La perfección no es el objetivo",": Siempre va a haber deuda, componentes por mejorar y decisiones que se pueden cuestionar. La clave es que sea útil y evolucione.",[87,486,487,490],{},[21,488,489],{},"Sin adopción, no hay sistema",": Si no lo usa el equipo, es solo una carpeta más en tu repo.",[87,492,493,496],{},[21,494,495],{},"Cada equipo es distinto",": No copies un sistema de otro lado esperando que funcione igual. Inspírate, sí, pero adapta todo a tu contexto y necesidades reales.",[87,498,499,502],{},[21,500,501],{},"Anticipa los problemas",": Tu Design System puede y va a fallar, habrán cambios de definiciones y de diseño. Ten eso en cuenta para que construyas todo de forma modular y flexible.",[87,504,505,508],{},[21,506,507],{},"Utiliza Atomic Design",": Pero utilizalo bien, cada componente es un mundo por si mismo, mientras más atómico sea cada uno, más fácil es modificarlo o extenderlo sin romperlo todo.",[61,510,511],{},[17,512,513,514,72],{},"Un Design System es una inversión a largo plazo. Puede ser desafiante, incluso frustrante a veces, pero cuando empieza a funcionar, ",[21,515,516],{},"todo el equipo gana en velocidad, consistencia y confianza",{"title":518,"searchDepth":519,"depth":520,"links":521},"",2,3,[522,523,524,533,538,539],{"id":14,"depth":519,"text":15},{"id":78,"depth":519,"text":79},{"id":114,"depth":519,"text":115,"children":525},[526,527,528,529,530,531,532],{"id":135,"depth":520,"text":136},{"id":155,"depth":520,"text":156},{"id":174,"depth":520,"text":175},{"id":193,"depth":520,"text":194},{"id":212,"depth":520,"text":213},{"id":231,"depth":520,"text":232},{"id":247,"depth":520,"text":248},{"id":263,"depth":519,"text":264,"children":534},[535,536,537],{"id":286,"depth":520,"text":270},{"id":321,"depth":520,"text":274},{"id":363,"depth":520,"text":364},{"id":406,"depth":519,"text":407},{"id":460,"depth":519,"text":461},"2025-06-25","2026-04-25","Lecciones reales construyendo Design Systems en Vue y TypeScript: errores comunes, decisiones de arquitectura y qué haría diferente hoy.","md",null,{},true,"\u002Fes\u002Fblog\u002Flo-que-aprendi-construyendo-design-systems-y-que-haria-diferente",7,{"title":6,"description":542},{"loc":547},"es\u002Fblog\u002Flo-que-aprendi-construyendo-design-systems-y-que-haria-diferente",[553,554,555],"design-system","frontend","vue","what-i-learned-building-design-systems-and-what-i-would-do-differently","18AHe9wpUVso9Pq6btpv1qFl7_gdiEcHbErV5EwzvBY",[559,564],{"title":560,"path":561,"stem":562,"description":563,"children":-1},"Cómo hacer migraciones con Claude Code y no morir en el intento","\u002Fes\u002Fblog\u002Fcomo-hacer-migraciones-con-claude-code-y-no-morir-en-el-intento","es\u002Fblog\u002Fcomo-hacer-migraciones-con-claude-code-y-no-morir-en-el-intento","Tres migraciones reales con Claude Code: el toolchain de un monorepo, screaming architecture y el rediseño de este sitio. Lo que antes tomaba semanas, hoy se hace en días.",{"title":565,"path":566,"stem":567,"description":568,"children":-1},"oxlint-tailwindcss: el plugin de linting que Tailwind v4 necesitaba","\u002Fes\u002Fblog\u002Foxlint-tailwindcss-el-plugin-de-linting-que-tailwindcss-necesitaba","es\u002Fblog\u002Foxlint-tailwindcss-el-plugin-de-linting-que-tailwindcss-necesitaba","El plugin de linting más completo para Tailwind CSS, nativo para oxlint. 22 reglas con autofix, zero-config y diseñado desde cero para Tailwind CSS v4.",{"id":570,"title":571,"author":7,"body":572,"date":540,"dateModified":541,"description":1049,"extension":543,"img":544,"meta":1050,"navigation":546,"path":1051,"published":546,"readingTime":548,"seo":1052,"sitemap":1053,"slug":544,"stem":1054,"tags":1055,"union":556,"__hash__":1056},"blog_en\u002Fen\u002Fblog\u002Fwhat-i-learned-building-design-systems-and-what-i-would-do-differently.md","What I learned building Design Systems and what I would do differently",{"type":9,"value":573,"toc":1029},[574,578,596,619,624,630,633,637,640,657,660,667,671,674,677,680,683,687,692,698,702,707,712,716,721,726,730,735,740,744,749,754,758,763,768,772,777,782,786,801,804,807,839,842,874,881,885,911,916,920,923,930,933,965,970,974,977,1021],[12,575,577],{"id":576},"what-is-a-design-system","What is a Design System?",[17,579,580,581,24,584,587,588,591,592,595],{},"Simply put, it's a collection of ",[21,582,583],{},"rules",[21,585,586],{},"components",", and ",[21,589,590],{},"guidelines"," that act as a ",[21,593,594],{},"single source of truth"," for designing and building interfaces.",[17,597,598,599,24,602,587,605,608,609,24,612,24,615,618],{},"A good Design System defines everything from ",[21,600,601],{},"colors",[21,603,604],{},"typography",[21,606,607],{},"spacing",", to how ",[21,610,611],{},"buttons",[21,613,614],{},"forms",[21,616,617],{},"alerts",", and more should behave. But it goes far beyond the visual: it also defines how design and development communicate, how patterns are documented, and how the product evolves consistently.",[61,620,621],{},[17,622,623],{},"The goal is for the entire team to speak the same language, design faster, and build products that feel coherent—without reinventing the wheel on every screen.",[17,625,626,627,72],{},"It’s not just a component library. It’s a way of working that seeks to ",[21,628,629],{},"align design, code, and user experience",[17,631,632],{},"I'll go into more detail about how I built mine and what I learned, but first I want to tell you what it was like to face this idea from scratch.",[12,634,636],{"id":635},"how-i-ended-up-building-design-systems","How I Ended Up Building Design Systems",[17,638,639],{},"After working on different projects and teams, I began to notice patterns that kept repeating:",[84,641,642,645,648,651,654],{},[87,643,644],{},"The same button designed three different ways",[87,646,647],{},"Inconsistent behavior in similar components",[87,649,650],{},"Duplicated or hard-to-maintain code",[87,652,653],{},"Misunderstandings between design and development",[87,655,656],{},"Interfaces that looked great in Figma, but not in production",[17,658,659],{},"Every time a product grew, so did the visual and technical chaos. And with it, the time we lost solving the same problems over and over again.",[17,661,662,663,666],{},"That’s when I realized we needed more than just a component library. We needed a ",[21,664,665],{},"shared way to build interfaces",", with clear rules, centralized decisions, and a source of truth for all teams.",[12,668,670],{"id":669},"expectations-vs-reality","Expectations vs. Reality",[17,672,673],{},"Remember when you had to do group projects at school?\nEveryone did their part separately, put it all together at the end… and the result was a total \"Frankenstein.\"",[17,675,676],{},"Well, building a Design System often feels like that.",[17,678,679],{},"At first, you think it’s going to organize everything, magically uniting design and development. But in practice, misunderstandings, shortcuts, and crossed decisions appear, and what should be a coherent system starts to fall apart.",[17,681,682],{},"Here are some of the biggest differences I experienced between what I imagined… and what actually happened:",[133,684,686],{"id":685},"expectation-1","Expectation 1:",[61,688,689],{},[17,690,691],{},"“I’ll create a reusable component library and the team will happily use it.”",[17,693,694,697],{},[21,695,696],{},"Reality:","\nSome devs ignore it, others break it, and others don’t know how to use it.\nWithout documentation, onboarding, and internal support, no one adopts it as you expected.",[133,699,701],{"id":700},"expectation-2","Expectation 2:",[61,703,704],{},[17,705,706],{},"“The design is in Figma, I just have to replicate it.”",[17,708,709,711],{},[21,710,696],{},"\nThe design doesn’t consider states, errors, focus, interaction, loading...\nI ended up making a lot of technical decisions that weren’t defined.",[133,713,715],{"id":714},"expectation-3","Expectation 3:",[61,717,718],{},[17,719,720],{},"“Once the components are done, we won’t need to touch them again.”",[17,722,723,725],{},[21,724,696],{},"\nDesign evolves, new requirements come up, and each change affects multiple parts of the system.\nA Design System needs constant maintenance.",[133,727,729],{"id":728},"expectation-4","Expectation 4:",[61,731,732],{},[17,733,734],{},"“I’ll create generic and reusable components for everything.”",[17,736,737,739],{},[21,738,696],{},"\nOverly flexible components end up being hard to maintain, test, or understand.\nSometimes it’s better to have clear variants than a single component with 15 props.",[133,741,743],{"id":742},"expectation-5","Expectation 5:",[61,745,746],{},[17,747,748],{},"“Design and development will work as one team.”",[17,750,751,753],{},[21,752,696],{},"\nWithout clear processes and a common language, misunderstandings happen all the time.\nCollaboration isn’t automatic. You have to build those bridges intentionally.",[133,755,757],{"id":756},"expectation-6","Expectation 6:",[61,759,760],{},[17,761,762],{},"“With Tailwind, I can do everything without a Design System.”",[17,764,765,767],{},[21,766,696],{},"\nTailwind helps, but without shared design decisions, tokens, and a clear structure, your project still becomes inconsistent.",[133,769,771],{"id":770},"expectation-7","Expectation 7:",[61,773,774],{},[17,775,776],{},"“I’ll have the system ready in a few weeks.”",[17,778,779,781],{},[21,780,696],{},"\nA Design System is never finished. It’s a living system that grows, adapts, and needs to evolve alongside your product.",[12,783,785],{"id":784},"design-and-development-needs","Design and Development Needs",[17,787,788,789,792,793,796,797,800],{},"When you set out to build a Design System (whether from scratch or based on an existing foundation) there are always two sides of the same coin: what ",[21,790,791],{},"Design"," and ",[21,794,795],{},"Development"," want and need. That’s where all the ",[277,798,799],{},"problems"," challenges begin.",[17,802,803],{},"Let’s take a look at what each team needs.",[133,805,791],{"id":806},"design",[84,808,809,815,821,827,833],{},[87,810,811,814],{},[21,812,813],{},"Visual consistency",": A unified visual language (colors, typography, spacing, iconography, etc.).",[87,816,817,820],{},[21,818,819],{},"Speed and efficiency",": The ability to design interfaces without reinventing the same components every time.",[87,822,823,826],{},[21,824,825],{},"Scalable designs",": What works on one screen should work on others (web, mobile, responsive...).",[87,828,829,832],{},[21,830,831],{},"Clear, reusable design tokens",": Technical definitions for colors, sizes, fonts, z-index, etc.",[87,834,835,838],{},[21,836,837],{},"Direct alignment with implementation",": What’s designed should look the same in production.",[133,840,795],{"id":841},"development",[84,843,844,850,856,862,868],{},[87,845,846,849],{},[21,847,848],{},"True component reuse",": A stable, well-documented, and easy-to-use library.",[87,851,852,855],{},[21,853,854],{},"Functional and technical consistency",": Same prop patterns, slots, states, accessibility, validation, etc.",[87,857,858,861],{},[21,859,860],{},"Ease of maintenance",": Clean code, clear naming, tests, and no duplicated logic.",[87,863,864,867],{},[21,865,866],{},"Living documentation",": Storybook (or similar), with real examples—not just theory.",[87,869,870,873],{},[21,871,872],{},"Adaptability across contexts",": A button (for example) should work the same in all our applications.",[17,875,876,877,880],{},"Each team has its own priorities, but for a Design System to work, they must ",[21,878,879],{},"collaborate",", making decisions based on shared definitions. That’s where the real intersection happens.",[133,882,884],{"id":883},"shared-needs-the-balance-point","Shared Needs: The Balance Point",[84,886,887,893,899,905],{},[87,888,889,892],{},[21,890,891],{},"Common language",": Tokens, component names, variants, states. Everyone should speak the same language.",[87,894,895,898],{},[21,896,897],{},"Smooth design–development process",": Clear handoffs from Figma (or whatever tool is used), efficient handovers, mutual feedback.",[87,900,901,904],{},[21,902,903],{},"Versioning and change control",": So that design changes can be implemented and communicated without breaking the system.",[87,906,907,910],{},[21,908,909],{},"Cross-team adoption",": It shouldn’t be stuck in one team. It has to be easy to understand and use by everyone.",[61,912,913],{},[17,914,915],{},"In short, a Design System needs to be strict enough to uphold design definitions and prevent undocumented visual changes, but flexible enough to extend and adapt without breaking things.",[12,917,919],{"id":918},"how-to-drive-system-adoption","How to Drive System Adoption",[17,921,922],{},"Having a technically perfect Design System doesn’t mean much if no one uses it.",[17,924,925,926,929],{},"One of the biggest challenges isn’t building the system, it’s getting the team to actually adopt it. And I don’t just mean “being aware it exists,” I mean ",[21,927,928],{},"integrating it into their daily workflow",", respecting it, questioning it, and keeping it alive.",[17,931,932],{},"Here’s what helped me (and what I learned the hard way):",[84,934,935,941,947,953,959],{},[87,936,937,940],{},[21,938,939],{},"Involve people from the start",": If the system is built in isolation, it will generate resistance. The more voices involved early on, the more ownership it creates.",[87,942,943,946],{},[21,944,945],{},"Show value quickly",": A useful, well-documented, easy-to-use component is worth more than a promise of “someday we’ll have everything tidy.”",[87,948,949,952],{},[21,950,951],{},"Document with empathy",": It’s not just about how to use a component, it’s about how someone new will understand it. Real examples, screenshots, use cases, FAQs—all of it helps.",[87,954,955,958],{},[21,956,957],{},"Provide internal support",": If someone has a problem with a component, there should be a quick way to solve it. Slack, issues, pair programming… whatever it takes, just don’t let people feel alone—and have a clear way to report issues.",[87,960,961,964],{},[21,962,963],{},"Celebrate usage",": When someone adopts a component, improves it, or reports a bug—celebrate it. Small recognitions help the system feel alive, collaborative, and valuable.",[61,966,967],{},[17,968,969],{},"Adoption isn’t an event, it’s a process. It takes time, patience, and lots of communication.",[12,971,973],{"id":972},"lessons-learned-and-final-recommendations","Lessons Learned and Final Recommendations",[17,975,976],{},"After all this, here are some takeaways I wish I had known earlier:",[84,978,979,985,991,997,1003,1009,1015],{},[87,980,981,984],{},[21,982,983],{},"A Design System isn’t a project, it’s a product",". And like any product, it needs research, design, maintenance, communication, and evolution.",[87,986,987,990],{},[21,988,989],{},"Start with what hurts the most",": Don’t try to solve everything from day one. Identify your biggest pain points and start there.",[87,992,993,996],{},[21,994,995],{},"Perfection isn’t the goal",": There will always be debt, components to improve, and decisions to revisit. The goal is usefulness and evolution.",[87,998,999,1002],{},[21,1000,1001],{},"No adoption, no system",": If the team doesn’t use it, it’s just another folder in your repo.",[87,1004,1005,1008],{},[21,1006,1007],{},"Every team is different",": Don’t copy someone else’s system expecting it to work the same. Get inspired, sure—but adapt it to your context.",[87,1010,1011,1014],{},[21,1012,1013],{},"Anticipate problems",": Your Design System will break. Definitions will change. Plan for that. Build things modular and flexible.",[87,1016,1017,1020],{},[21,1018,1019],{},"Use Atomic Design",": But use it wisely. Every component is a world of its own. The more atomic each one is, the easier it is to update or extend without breaking everything.",[61,1022,1023],{},[17,1024,1025,1026,72],{},"A Design System is a long-term investment. It can be challenging, even frustrating at times, but once it starts working, ",[21,1027,1028],{},"the whole team benefits from speed, consistency, and confidence",{"title":518,"searchDepth":519,"depth":520,"links":1030},[1031,1032,1033,1042,1047,1048],{"id":576,"depth":519,"text":577},{"id":635,"depth":519,"text":636},{"id":669,"depth":519,"text":670,"children":1034},[1035,1036,1037,1038,1039,1040,1041],{"id":685,"depth":520,"text":686},{"id":700,"depth":520,"text":701},{"id":714,"depth":520,"text":715},{"id":728,"depth":520,"text":729},{"id":742,"depth":520,"text":743},{"id":756,"depth":520,"text":757},{"id":770,"depth":520,"text":771},{"id":784,"depth":519,"text":785,"children":1043},[1044,1045,1046],{"id":806,"depth":520,"text":791},{"id":841,"depth":520,"text":795},{"id":883,"depth":520,"text":884},{"id":918,"depth":519,"text":919},{"id":972,"depth":519,"text":973},"Real lessons from building Design Systems in Vue and TypeScript: common mistakes, architecture decisions, and what I would do differently today.",{},"\u002Fen\u002Fblog\u002Fwhat-i-learned-building-design-systems-and-what-i-would-do-differently",{"title":571,"description":1049},{"loc":1051},"en\u002Fblog\u002Fwhat-i-learned-building-design-systems-and-what-i-would-do-differently",[553,554,555],"9uZLQFAfpJd-TvYyJlaAgr7GG2tba0ci3GLEP87pzAc",1777609841241]