Valparaíso To Digital Design: Daniel Llach On System Scaling

Reading Time: 11 minutes

The morning fog rolls in from the Pacific, wrapping Valparaíso’s hills in a dreamy haze. 

I hurry past explosions of color—indigo doors against mustard walls, emerald stairs winding past grand Simson facades, street art blooming like urban gardens on the surface—searching for today’s workspace.

This is Valparaíso, where the poetry lives. Locals, where local troubadour Víctor Hugo Acosta captures the soul of low-income people, where every corner holds.

This is a true story, and it is where my design journey—systems—began, though I didn’t know it then.

The intersection of art, code, and design

It’s 2005, and I’m claiming my usual spot in a dimly lit internet café. The faint scent of coffee mingles with the whir of aging computers. 

My student budget means that each hour of internet access is precious, and every line of code is written between sips of the cheapest coffee available.

My “office” moves with the rhythm of the city. In the mornings, wooden tables are filled with students in the public library. 

When the museum closes, I migrate to one of the internet cafés, where art and WiFi coexist until late afternoon. As evening approaches, I find my way to one of the cafés, where the screens glow well into the night.

But the real magic happens in the plazas. As darkness falls, these public spaces transform into impromptu gathering spots, their free WiFi drawing students like moI to continue coding Hereo a flame. Here, amid guitar sessions and the sweet haze of Valparaíso’s legendary, continue coding. 

My laptop’s glow mingles with the city lights while around me; fellow students turn these historic squares into their version of Silicon Valley – if Silicon Valley had better music, more poetry, and a distinctly Chilean approach to creative inspiration.

My “office” changes with each passing hour, but my passion for using design and code brings order to design and code.

Little did I know that this nomadic pursuit of internet connection would lead me from Valparaíso’s bohemian hills to architecting Weave, Autodesk’s next-generation design system launched in 2024.

“Like Valparaíso’s famous murals, the best design systems blend structure and creativity into something magical”

Q. Do you think mentorship plays a crucial role in developing future designers and developers?

A. The real turning point in my journey came through an unexpected encounter. 

Hellmuth Stuven, a Chilean engineer and political exile who had returned from Denmark, was tasked with creating the Salvador Allende Museum’s website. Our paths crossed through parity.

Through paths crossed, he saw something in my work that I hadn’t fully recognized yet.

“Here’s a Mac,” he told me, placing my first Apple computer on the desk. “And here are the books you need to learn HTML, CSS, and programming fundamentals.”

“Sometimes the most important design patterns aren’t in our code, but in how knowledge is passed from generation to generation.” 

This wasn’t just about learning to code. Fate had given me the gift of crossing paths with Hellmuth during his final years in Valparaíso. 

What started with a Mac and some programming books evolved into something more profound. I rented a room in his house, and our late-night conversations about technology, design, and life became the foundation of my career and a profound friendship.

Hellmuth was more than a mentor. 

In him, I found someone who could see the bridge between art and engineering that I was instinctively trying to build. Those precious years of friendship and guidance shaped not just my technical skills, but my entire approach to problem-solving.

“Some mentors teach you code. The great ones teach you how to see the world differently”

Living under Hellmuth’s roof and watching him apply his engineering discipline to everything he did while maintaining a deep appreciation for creativity showed me that technical precision and artistic vision weren’t opponents—they were dance partners.

Q. What was it like meeting Brad Frost and realizing that Atomic Design aligned with your own intuitive methods?

A. During my university years (2005-2010), what we now call design systems didn’t exist in their current form. Instead, I was discovering their fundamental principles through trial and error:

• Using Dreamweaver’s visual interface to layout pages
• Diving deeper https://meet.google.com/gwj-yqui-kxw code to achieve specific design goals
• Applying design principles to code organization
• Learning to create reusable patterns before they had a name

“The best innovations often start as intuitions before they become methodologies”

Years later, I would have a full-circle moment when I met Brad Frost, the creator of Atomic Design, while implementing United Airlines’ Atmos design system. His methodology put names to patterns I’d been instinctively following for years.

Q. Your journey from small-scale projects to enterprise-level design systems is inspiring. What was the biggest challenge in making that transition?

A. The path from those early days in Valparaíso’s internet cafés to leading Autodesk’s design system wasn’t a straight line – it was more like one of my hometown’s winding staircases, each turn revealing new perspectives.

In those foundation years, I’d rush between design classes and internet cafés, my backpack heavy with design books and sketches. 

Each local business website was a new band-aid to solve the problem, teaching me that good design wasn’t just about aesthetics but about creating systems that made sense.

“Every peso I spent on internet café time was an investment in my future, though I didn’t know it then”

Then came the turning point. Meeting Hellmuth was like finding a lighthouse in the fog. Here was someone on web design’s surface and web design who understood the poetry in well-structured code. 

That first Mac he gave me wasn’t a computer – a door to a new world. 

His books became my evening companions in my small student room, the command line my new canvas.

As my projects grew more complex, so did my understanding of the bridge between design and development. 

Each system I built was more sophisticated than the last, and each solution was more elegant. My first significant project came from “8½”, a boutique restaurant in Cerro Alegre. 

Named after Fellini’s masterpiece, it wasn’t just a restaurant – it was a cultural hub with an art-house cinema in its basement, complete with vintage theatre seats and the whispered echoes of auteur films. 

Creating their website taught me how digital design could capture the essence of a space where gastronomy met cinematic art.

This attention to cultural detail caught the eye of academic institutions. Soon, I worked with the Pontifical Catholic University, developing the web presence for their Environmental Engineering Laboratory and Sustainability Program. 

My growing systematic approach to design required me to balance academic rigor with accessibility, a challenge that would later prove invaluable in enterprise systems.

Several years later, working for United Airlines, I wasn’t the kid who once counted coffee cups to afford internet time; I was now discussing design patterns that would affect millions of travelers. 

Meeting Brad Frost, whose Atomic Design methodology had unknowingly influenced my early work, felt like closing a circle.

“Systems thinking isn’t just about code or design – it’s about understanding how small pieces create something greater than their sum.”

Today, as I lead the technical architecture for Weave, Autodesk’s new design system, I carry those early lessons. 

Every decision we make impacts thousands of developers and countless end users. But at its core, I’m solving the puzzle I started with in those Valparaíso internet cafés: how to make digital experiences more human and coherent.

Q. You compare design systems to cities and architecture. How does this analogy help in understanding their complexity?

A. Walking through Valparaíso’s hills today, I see parallels between the city’s architecture and modern design systems. 

Like our port city, where every element from the smallest cobblestone to the grandest building plays its part, a design system is a living, breathing ecosystem of interconnected pieces.

Let me share what years of implementing design systems at Fortune 500 companies has taught me about their architecture:

“A design system is like a city – designers are the urban planners envisioning the future, while developers are the architects ensuring everything stands strong”

At its foundation, we have design tokens – the DNA of the system. 

Like the distinct colors of Valparaíso’s houses or the consistent width of its staircases, tokens define every visual fundamental: colors, spacing, typography, shadows. 

These aren’t just technical but cations; they’re the building blocks that carry your brand’s soul.

Brad Frost’s Atomic Design methodology, which I came to appreciate deeply while working with him on United Airlines’ design system, brilliantly captures this hierarchical nature. 

Just as our city grows from individual homes to neighborhoods to complete hills, interfaces grow from:

• Atoms (basic HTML elements)
• Molecules (simple component groups)
• Organisms (complex components)
• Templates (page layouts)
• Pages (specific instances)

But here’s what I learned leading Weave’s implementation at Autodesk: the real magic isn’t in the components themselves – it’s in the partnership between design and development.

“The strongest design systems emerge when designers and developers dance together, each respecting the other’s expertise”

Designers must always be the vision keepers. Like urban planners, they see the big picture, understanding how each piece contributes to the user experience. 

Their ownership of the system is crucial – they’re the guardians of its soul.

Development’s role? We’re the master builders. 

Our job is to take that vision and make it rock-solid. We provide the technical foundation that makes the system reliable, performant, and a joy to implement. 

Consider it turning architectural drawings into buildings that can, however, storm.

However, real innovation happens when the participants become part of the system’s evolution. 

At Autodesk, we created what I like to call—afe harbors” – carefully crafted processes where teams across the company could contribute to the design system without fear of breaking it.

This is where governance becomes crucial. Like Valparaíso’s urban planning office, you need a dedicated cross-functional team that:

• Oversees system evolution
• Reviews and guides contributions
• Maintains global consistency
• Facilitates adoption and learning
• Protects the system’s integrity while enabling its growth

“A design system is only as strong as its governance and only as valuable as its adoption.”

It’s a delicate balance. It’s too rigid, and teams won’t adopt it. Too loose, and chaos creeps in. 

The key is creating clear pathways for contribution while maintaining high standards – like how our city preserves its historic character while allowing for modern needs.

Q. If you had to give one piece of advice to a company starting its own design system, what would it be?

A. The journey from concept to implementation is where theory meets reality. 

At Autodesk, Weave became more than just another design system – it became a case study in how these systems can transform an enterprise.

Picture this: hundreds of developers across different time zones, dozens of product teams, and a legacy of design decisions spanning decades. 

How do you bring order to such complexity without stifling innovation?

The answer emerged through careful balance:

First, we focused on the foundations. Like the stone walls that keep Valparaíso’s hills from sliding into the sea, we built a robust token system. 

Every color, spacing value, and typographic choice was carefully documented and implemented. But the real innovation came in how we delivered these tokens.

“Design systems aren’t just about the what – they’re about the how.”

We created a multi-platform delivery system where, as the architect for the React and Web Components implementations, I worked to ensure our design system could:

• Power web applications through both React and framework-agnostic Web Components
• Support native desktop and mobile applications through C++ implementations
• Enable seamless theme customization while maintaining rock-solid consistency

The challenge wasn’t just building compost—it was also creating a system that could serve Autodesk’s diverse ecosystem, which includes web applications and professional desktop software. 

Our approach meant that the same design tokens and patterns could flow consistently through React applications, native interfaces, and anywhere a Web Component might be needed.

But technical excellence alone wasn’t enough. The human element proved crucial.

A senior designer approached me one day, frustrated with a component’s implementation. 

Instead of divinwalking an hour walking through, he for an hour design process. 

That conversation led to a breakthrough: we added a new token category specifically for interaction with her problem and her problem but dozens of similar cases across the company.

“Sometimes the best technical solutions come from simply listening to designers.”

Another breakthrough came from our governance model. Rather than relying solely on traditional approval processes, we implemented automated testing throughout both design tools and codebase. 

These tests ensure the integrity of the token structure at multiple points in the contribution process. Relevant owners review each token category.

“A hierarchical, intentional token structure isn’t just about the organization – it’s the key to effective design system governance.”

This automated approach meant that governance wasn’t just a set of guidelines – it was built into the system itself. Teams could confidently contribute, knowing that our tests would catch structural issues before they became problems. 

My article “Your Design Token Architecture Is Your Governance” details this token-driven governance approach more thoroughly. 

Still, the core insight is this: thoughtfully structured token architecture naturally enforces design system consistency while enabling safe evolution.

The results spoke for themselves:

• The development time for new features dropped by 60%
• Design consistency improved across 20+ products
• Team satisfaction scores rose significantly
• Cross-team collaboration reached new heights

But perhaps the most meaningful metric was one we hadn’t anticipated: the stories our teams started telling. Developers spoke about design with new understanding. 

Designers explored technical constraints with curiosity rather than frustration. We had created more than a system – we had built bridges between disciplines.

From principles to practice

Enterprise scale taught me that success often lies in the details – not just of code or design, but of human interaction. Here’s what made the difference:

Building trust through transparency

We made every decision visible and explained the reasoning behind it. When we had to make tough choices about backward compatibility or performance trade-offs, we brought the community along with us.

Creating safe spaces for experimentation

We built a “playground” environment where teams could safely experiment with new patterns without risking production systems. This freedom to explore led to some of our most innovative solutions.

Embracing imperfection

Like Valparaíso’s street art, which gains character from its imperfections, we learned to value progress over perfection. Each iteration brought us closer to our goals, and sharing our learning process openly helped others grow with us.

Measuring what matters

Beyond traditional metrics like adoption rates and performance benchmarks, we tracked:

• Time saved in design-to-development handoff
• Reduction in design inconsistencies
• Team collaboration satisfaction
• Innovation within the system’s constraints

What is the most important lesson I found? A design system is never truly finished. Like a city, it grows, adapts, and evolves with its community. Our role is not to build perfect systems but to create spaces where creativity and structure can coexist and flourish.

Full circle

Sometimes, during late-night debugging sessions at Autodesk, my mind wanders back to those plazas in Valparaíso. 

The same moon that once lit my laptop screen in those bohemian squares now watches over my work on enterprise design systems.

The journey from those free WiFi spots to Fortune 500 boardrooms has taught me something profound: whether a student codes between guitar sessions or an architect designs systems used by millions, the fundamental challenge remains the same: bringing harmony to digital chaos.

Looking at Weave today, I see echoes of everything that shaped me. 

The systematic thinking I learned from Hellmuth—the balance of creativity and structure I discovered in Valparaíso’s streets. 

The understanding is that the most powerful systems aren’t built through control but through enabling creativity to flourish within thoughtful boundaries.

Twenty years ago, in those vibrant plazas, I couldn’t have imagined where this path would lead. 

That the kid hunting for free WiFi would one day help shape how some of the world’s largest companies build their digital products.

But the most beautiful part? 

Every time I see a team discover new possibilities within our design system and watch designers and developers build something amazing with tokens we crafted, I feel the same thrill I felt in those early days – when design and code began dancing together in my imagination.

Ultimately, whether you’re building websites in internet cafés or architecting enterprise design systems, the goal is to create spaces where logic and poetry can coexist, where structure enables creativity, and where digital experiences become a little more human.