Layer Like a Dev: Why Designers Should Use C4 Diagrams

Designers don’t need to be architects, but in complex systems, the biggest design win might come from a shared C4 diagram.

Designers don’t need to be architects. But the smart ones collaborate with them.

In complex systems, Figma alone won’t get you to clarity. C4 diagrams will.

Your biggest design win might not come from a single screen. It might come from sitting down with a platform architect, drawing boxes and arrows.

Context Is Complex

When you’re building large-scale enterprise platforms, most of the key decisions aren’t made at the interface level. They’re made deep in the infrastructure, long before anyone talks about flows or functionality.

In complex domains, the architecture shapes everything: data pipelines, security, system integrations and protocols. These systems are built for reliability and performance first. That means UX often comes in late, after major decisions are already made.

In construction, architects are both designers and engineers. In software, the architect is usually a software engineer with system ownership and the authority to make technical decisions.

Unless designers understand that system-level thinking, they’re stuck designing around constraints they never had a chance to influence.

What Are C4 Diagrams?

A C4 diagram is like Google Maps for your codebase. It shows your system at different zoom levels—from the big picture down to developer-level details.

Here’s how it works:

Level 1: Context
This is the world your system lives in. Who uses it? What other systems does it interact with? This level helps everyone understand why the system exists and what job it supports.

Level 2: Containers
These are the major parts inside the system—web apps, APIs, databases, services. It shows how responsibilities are distributed across the architecture.

Level 3: Components
Zoom into a container to see what it’s made of. You’ll find the internal building blocks: modules, services or UI parts that work together.

Level 4: Code
This is the implementation layer—classes, methods, attributes. Often generated directly from your code editor.

As a designer, your work often lives in Level 1 and 2. If you’ve done UX research, ask yourself:

• Is that user insight visible in the C4 diagrams?
• Are there diagrams available?
• If not, can you help create or update them?

C4 isn’t just for engineers. It’s a shared map. Make sure your design insights are on it.

Want to explore more? Visit c4model.com.

The Time When Draw.io Beat Figma

I did exactly that.

I was working as the Global Design Lead on a new remote operations and IoT platform in the oil and gas industry. Our challenge? Build software that would let operators work from the office instead of the rig. That meant handling real-time data streams, edge connectivity and integrating with a mix of new and legacy applications.

I had a great relationship with the platform architect, and that’s when I first came across C4 diagrams. The moment he walked me through one, I thought: Wait, this is my job!

He was mapping the same systems and workflows, but from a technical perspective. And I had additional insights—what users were trying to do, what tools they used today, how we should name things.

We realized that, by collaborating early, we could cover the problem from both ends. Design could inform the architecture, and architecture could guide the design. It made everyone’s job easier. Fewer surprises. Better alignment.

I spent more time in Draw.io than I did in Figma. That’s where the magic happened.

Influencing Impact

Going on a roadshow with an architect was new for me. I had to step up my game.

A technical deep dive isn’t the same as building a conceptual user journey. And in a lot of those workshops, I didn’t know what half the acronyms meant.

But the benefit of collaborating early was that I could ask questions at the right moments. These were big technical decisions with long-term consequences.

And even if I didn’t have the answers, I could bring evidence, raise user concerns or challenge assumptions that hadn’t been questioned yet.

I wasn’t there to redesign the system. I helped shape it.

And because I was working side by side with the architect, I had one of the most trusted voices in the org on my side. He had decades of credibility. He knew the domain. He’d seen what failed before and could help us avoid repeating it.

In earlier projects, I didn’t have that kind of collaboration. There was tension and misunderstanding. This time, the partnership changed everything.

And what I realized is this: When designers help shape the technical foundation, UI work becomes easier later. Because the foundation is stronger. And it’s built with the user in mind.

How to Get Started

If you’re a designer, start by finding out who’s in charge of architecture. It might be an architect. It might be a senior developer.

Go talk to them. Ask how they visualize the architecture. Ask if they use C4 diagramming. If they do, ask to see it. Tell them you want to collaborate and build a shared map of the system.

When you explain designs, use their diagrams. Put them up in design reviews or sprint planning sessions. Refer to them in refinement.

You can also sketch it yourself—especially Levels 1 and 2. If you’ve done user research, you probably already know who uses the system, what they need, and how they interact with it. That’s context and container-level insight.

Schedule a session with the owner of the system design and walk through it together. You’re not trying to do their job. You’re trying to build a shared understanding.

Even if you’re not leading strategy or deeply involved in architecture, helping visualize the system earns trust. It helps everyone stay on the same page—even if all you do is make their diagram look nice.

If you’re an architect or developer reading this: invite the designer in.
Walk them through your C4 diagram. Ask what they see. Ask what’s missing. Designers bring research, language and mental models that will make your diagrams better.

Whether you’re designing code or designing flows, you’re still designing a system. You don’t need a new process. Just collaborate. Share. Care about getting it right at all the levels.

Closing: Think in Layers

Great architecture happens when design and engineering work together.

In complex systems, you need clarity. You need to see what you’re building. You need a map.

C4 diagrams are a powerful way to get there. They help teams collaborate across roles, zoom into code when needed and still tie it all back to context.

Clarity is the foundation of great software. And when architects and designers co-create, you help connect every layer—from infrastructure to interface.

That’s what it means to think in layers. That’s how you design better systems.

Layer like a dev.