Figma Config was something else.

Being surrounded by thousands of designers, engineers, and product leaders, all thinking seriously about where the craft is headed. For a small studio from Copenhagen, being in that space, and on that stage, meant a lot.

Config has a way of concentrating the entire industry into a few days. The talks, the product announcements, the side conversations that turn into discussions. Everyone in that building is wrestling with the same questions from different angles: what design is becoming, what tools are changing, and what our role will look like as the ground keeps shifting. Being part of that conversation, rather than just watching it from a distance, is a different feeling entirely.

There's something about being around people who care that much about the work. The conversations in the hallways, the curiosity, the sense that the industry is genuinely moving in an interesting direction. 

We left San Francisco with a lot to think about, and that's exactly what we wanted.

Figma Config 2026

Handoffs to Upstream on stage.

From Handoffs to Upstream came from something this studio has been living for the past year. Not AI, not the next big tool, but something more structural: what it actually takes to move designers upstream, and why the gap between what gets designed and what ships was never a communication problem, but a structural one.

The studio made that bet a year ago. The commercial upside is real, but that was never the reason. The reason was that the work wasn't worth making any other way. For most of the codebase, the line between designer and engineer isn't blurred. It's gone.

There's more to the story. The full talk covers how it happened, what it demanded, and what it unlocked. Worth a watch if the topic is on your mind.

For those who want to go deeper, it's all written down in a playbook. The day-to-day, the decision-making, the leadership approach, and the commercial impact. Six chapters built from a year of real work. Download it for free at edl.dk/design-engineering-book.

And if the talk raises something you want to think through, we are always up for that conversation.

Transcript

Hello everybody. I’m super excited to be here.

I’ve been asked to talk about my personal experience of turning my design studio into a design engineering studio that ships and owns design systems in code.

I haven’t flown across the Atlantic to talk about AI, even though these slides may make it seem like it. Between you and me, I’m kind of sick of AI. Just the Uber ride here from the airport, watching all those billboards, was insane. However, AI as a tool is a catalyst for us as designers, for our industry and for my studio to move upstream and take more ownership.

My name is Frederick. I run a nine-person design studio in Copenhagen. Most of our design team pushes to client repos today. I haven’t forced anybody to do this. I’ve created the opportunity for them to move in that direction. And as you all know, our work has been moving that way for a while, even before AI.

From a business point of view, there’s a huge commercial upside for a design studio to own design system work and move closer to code. But I took this risk for more personal reasons, and I’ll start with those.

The gap

Twelve years. That’s how long I’ve watched careful design work get butchered in implementation. That sounds rough, and I mean my own work too. Not by bad developers, and not by ill intentions, but by a gap I had accepted as the normal cost of doing business. We’d spend months getting something right, and it would ship looking just a bit wrong.

I called it a communication issue. I called it a Figma annotation issue. But it was a structural issue. What I’ve come to realise is that the person who cares about the detail is not the person who implements it.

To give you a bit of behind the scenes: eight months into most client relationships, the hardest work was done. We had architected the systems and redesigned the products. After that, we were on the outside looking in. We’d watch things get pulled apart. It wasn’t the engineers’ fault. We weren’t there to govern it. Decisions were made in isolation, and stakeholders sometimes gave feedback way too late.

That’s where I saw the opportunity. If my designers could earn our clients’ trust and get access to their codebases, we could own the design system. We could quality-assure the work, own component decisions and keep the integrity of our design. The relationship would get stronger, because we could take ownership of the quality of what ends up in users’ hands. And engineers would be freed up to do more important, more innovative work. That’s a win-win-win.

Why I didn’t hire developers

In case you’re wondering: yes, every quarter for the five years I’ve run this studio, I’ve thought about hiring developers in-house. They’d share our taste, sit next to the designers who made the decisions, and give us control of the output. Agencies I’ve looked up to for decades, like Fantasy, MetaLab and Ueno, have done it this way with great success.

But I knew what would happen next. Engineering headcount would grow, usually driven by demand. It would outgrow the design team I set out to build, and suddenly I’d be running a development agency with a design function attached. That simply wasn’t what I wanted.

AI changed that. Not because it makes coding easier, although it obviously does, but because it changed the timeline. Two years ago, a product designer shipping production code or maintaining a design system meant a career change: going back to school, late nights of learning. Now it means two to four months of focused work under the right conditions. And the conditions are crucial. I’ll come back to them.

I don’t want to get jumped by the engineers in this audience after the talk, so let me be clear: AI hasn’t made anyone a design engineer or a design system architect from day one. It takes exposure and extensive training. You need architectural instinct. You need to understand the DOM. You need to direct a tool, not be directed by it. AI sped up the timeline. It didn’t lower any bar for quality.

Still, the opportunity let us stop doing handoffs. We started building and shipping. We stopped being a vendor that delivers files and became what engineers build on top of. That’s still crazy to me.

So if anyone here, even after all the great talks today, thinks this is a future possibility, I’m here to tell you it’s not. It’s happening right now, and it starts with design system ownership in code. As designers, we can have a much bigger impact on important product features if we own the design system.

Start with one person

We’re all in different situations. I’m here to show you how a small Copenhagen studio did it. But whether you’re a design director at a Fortune 500 company, a chief design officer or a freelancer, the playbook is the same. It starts with one designer and the right conditions.

The key is picking one person. Not a team, not your whole organisation. For me, that was Modestas. He’s somewhere in the crowd, so find him and talk to him later. I hired him three years earlier to replace me in Figma, because I had a studio to run.

I picked him for three reasons: he was organised, detail-obsessed and curious about code. All wonderful traits in a designer. But personality wasn’t enough. He also had four slightly underdeveloped capabilities that I believed this needed.

He thought architecturally. A component lived inside a system in his head, not on a Figma canvas. He thought about how his work would be consumed downstream by developers, and you could see it in his files and handoffs: developers actually wanted to consume his work. He had a basic understanding of the DOM from working with developers. And like anyone in this room, he could learn to prompt. Not typing into a chat box, but directing a tool. That’s a big distinction.

A note on perfectionism

A quick note on perfectionism, because I know a lot of people in this room have it. It will speed up the learning process a lot, but you need to manage it. Modestas was, and still is, protective of his ideas. He’s proud, he wants to impress, he’s a good old-fashioned perfectionist. I love that about him, because I’m the same. But as a leader, you need to notice those traits and design around them. Good traits can become negatives when you’re changing someone’s career from design to engineering.

I expected his perfectionism to slow him down, because I know it would paralyse me if I suddenly had to go from a Figma canvas to making architectural decisions that would last in code. Early on, I didn’t need polish. I needed momentum.

So I told Modestas up front: I expect mistakes. I expect us to look back on this work in a few weeks and be embarrassed by it. That’s the signal it’s working. Imposter syndrome is common for all of us. Sprinkle some design system architecture on top and you have a lethal mixture. As a leader, you need to name it before they do.

The one-week test

Modestas was up for the challenge. I time-boxed one week and cleared his calendar. I handed him a B2B SaaS UI we had designed in Figma: fully specced, ready to go, never coded. My expectations were simple. Extract the components, set up Storybook, make it real.

He had never built a production component library. I wasn’t testing whether he could do it cleanly. That would have been foolish. I was testing whether, under a bit of time pressure and discomfort, he could lift those four capabilities.

At the end of the week, we had Storybook running and components separated, working in a browser instead of a Figma file. That was a big step. He read his way into half of it and figured out the rest as he went. Some of it was rough. Some of it was over-engineered. None of it was finished. But every capability I was looking for was there, and that was enough for me to fully commit.

The conditions

Before we moved on to billable work, a few things had to line up. The studio absorbed the cost of him learning on the job. He needed to go at his own pace, and you can’t rush this. We bought a design system course to strengthen his architectural decisions and give us shared terminology, internally and with clients.

And as corny as it sounds, trust was a huge part of it. He started prototyping his designs in code on his own, without me asking, because he thought it was a better medium for his work. That’s trust.

I had a clear aha moment shortly after the test. Modestas had designed a complex chart component in Figma, and we were told it was unbuildable. He asked which JavaScript framework the developers were using, prototyped it in code with Cursor and walked the developers through his implementation. It turned out not to be so unbuildable after all. That’s when I knew this was right for us.

One of the most important things I did was also one of the simplest. I dedicated 15 minutes of my own time every day to what I called a design engineering sync, at 2 pm. It worked as a daily deadline. Without a clear horizon, individual contributors can disappear into problems and perfectionism. The sync gave us a reason to surface. Sometimes we talked for five minutes, sometimes for hours. It didn’t matter. It was there.

The scariest room

Then I put him in engineering meetings, the scariest room I could think of. At first they were uncomfortable for both of us, because it was all new: architecture talks, planning sessions, rooms where we didn’t have all the answers yet.

Most leaders’ instinct here is to protect and smooth the path. That’s a good instinct. But at first, I protected Modestas from only one thing: being publicly exposed by engineers before he had the language to hold his own.

There’s a sentence I used in those rooms: “We’ll circle back to you on that. We need to weigh our options.” That’s a complete answer. It needs no apology, and it shows process, not ignorance. You can’t afford to look ignorant when you’re moving from design into engineering. Find your own version, because you will need it. Modestas watched me use it, started using it himself, and today he doesn’t need it anymore.

For the leaders in this room: there’s a difference between protecting people from shame and protecting them from struggle. Struggle is good. It’s how we all grow. Realising two weeks too late that you made the wrong architectural decision sucks, but it’s growth. Late nights reading Reddit threads about which framework to use for your next cross-platform app suck too, but they’re growth. Shame is how people stop growing. Looking stupid in a Zoom call full of engineers kills momentum. Intervene on the shame, and stay out of the struggle.

What we shipped

Back to the timeline. By October, we had shipped our first design system with downstream developers consuming our work in code. It was the foundation: semantic tokens, primitive components, all that jazz.

We even built a feature on our own npm package. It was an invoicing module with mock logic, and our client Proper’s developers hooked it up to their own API. Separation of concerns, exactly how we wanted it. It created the goodwill we needed as a studio to take on more ownership of engineering.

In December, we restructured the Storybook slightly, because Proper wanted us to build a mobile app for them. That showed it was working. That foundation, those mobile components and those architectural choices now run a handful of white-label apps in production, built on the work one designer did in his first five months as a design engineer. And by now, many of our designers have built work like this.

The culture shift

Then I started seeing a cultural shift at the office. It showed up first in our Friday design reviews, where the whole studio looks at work in progress together. Modestas had started bringing his components, his code and his Storybook, and you could see the why and the what clicking for everyone.

Design engineering started coming up in personal development conversations. The first time, a designer asked me in a one-on-one: “Frederick, I want to do what Modestas is doing. How can we make that happen?” By then, Modestas had done the hard part: showing everyone that a designer can move into something potentially more meaningful and take more ownership.

To build on that, I asked Modestas to speak to his colleagues at our annual retreat in October. I used the retreat to announce that design engineering and design system ownership would become our core services the following year, which sounds insane. But I also asked Modestas to present. Not a status update, but a real talk about what design engineering is and what it unlocks for designers and for our industry.

He stood in front of colleagues who had watched him be uncomfortable and deep in his work for months, and shared his optimism that this is the future for us as designers. The same talk from me would have been an instruction. From Modestas, someone people trusted, it was an offer. People don’t change careers passionately because their boss tells them the new AI thing is great. They move when someone they trust shows them what’s possible.

To be honest, not everyone on my team has asked to make this transition. Some are juniors who want to deepen their product design craft first, and that comes first. Some are still cautious, and I get that. When they get there, they get there. Half my designers ship code today. The other half do equally important work. The future of our industry doesn’t require everyone to make this move.

Where we are now

Twelve months ago, Modestas was “only” making pixels in Figma. Really good pixels. Today, the design systems he built are consumed by developers across three continents. That’s not a job change. It’s a completely different person doing completely different work, in a very short time. As a leader, watching it happen has been one of the most rewarding things I’ve done in five years of running the studio, and I believe you can experience that too.

Here’s what it looks like: a screenshot from a Git repository, with three designers from our team pushing to a client’s codebase. That seemed impossible not long ago.

And this number still surprises me. We double-checked it several times before flying over: 84% of the production code in one of our client projects is built by designers. Our design system component coverage is sky-high. We have the ownership, and we have the quality. In most of the codebases we work in, including that one, the line between designer and engineer isn’t blurred. It’s gone.

That’s what design engineering means to me, and it makes me so excited. I run a small studio. No scale, no famous name. What I sell is outcome: what actually ships and moves our clients’ business forward. Design engineering let me build the studio I always dreamed of in terms of craft, one where the gap between what we design in Figma and what ships is as small as we can possibly make it.

The commercial upside is real, but that’s not why I made the bet. I took the risk because the work I wanted to make simply wasn’t possible any other way. Design needs to own the code, whether that’s your organisation’s design system or the front-end of a core part of your product. Design needs to move upstream.

What to do on Monday

If you lead a design team, next Monday, pick the designer who cares and shares capabilities and interests like Modestas’s. Hand them a UI ready for implementation. Give them a week to build it, and get out of their way. Don’t force your whole organisation to chase this shiny new thing. It will backfire.

And if you’re a designer thinking, “My leader will never go for this. I’ll never get the chance,” start anyway. The skills you build now will compound for the next decade. On Monday, set up the LLM of your choice and get started with the Figma MCP. Ask a developer you trust for access to their codebase. Fix something small. Build something you just designed in Figma, ideally using components from your Storybook or component library. Your developers will love you for it. Be curious and ask why. You don’t need permission to start.

Finally, for the leaders here: I’ve written up a longer version of these thoughts than I can fit into 20 minutes, covering the day-to-day, the decision-making and the commercial impact. You can download it here, or find me and my team around for the rest of the week. We’d love to chat and share the link.

Thank you very much.