Designers are becoming technical

I was trying to explain SVGs to a colleague, our main designer, when I realized the conversation was not really about file formats.

It was about how technical design is becoming.

For years, the boundary was fairly clear. Designers created the visual system. Developers implemented it. The designer might export an SVG, but what happened inside that file usually belonged to someone else.

That boundary is disappearing.

Not because every designer is learning JavaScript. Large language models can now translate design intent into technical action.

An SVG is not a finished picture#

Most people treat an SVG like a better PNG: the version of the logo that stays sharp when you make it bigger.

That is true, but incomplete.

An SVG is a set of drawing instructions:

The file describes points, curves, fills, strokes, and relationships. The browser follows those instructions and produces the image.

That means the logo is not a flat artifact. It is structured data.

Every part can be inspected. Every color can be changed. Individual shapes can be isolated, animated, rearranged, or made interactive.

The asset contains far more possibility than the static image we normally see.

Developers have always known this. What is changing is who can use it.

I built the explanation instead#

As I tried to explain this, I realized I could demonstrate it faster than I could describe it.

I made a small interactive component that separated the SVG into its different sections. As we moved through the markup, the corresponding part of the logo became visible.

This path created that curve.

This group contained that part of the mark.

This value controlled that color.

The code stopped looking like an opaque technical artifact. It became another way of examining the design.

My colleague did not need to memorize SVG syntax before she could understand what was happening. The component and the LLM acted as interpreters between visual intent and implementation.

The technical layer became explorable.

The result is the C-Paw blueprint study. It draws the original geometry, isolates its parts, and decodes the SVG commands behind the mark.

Designers can now ask the asset questions#

An LLM can read an SVG because an SVG is text.

A designer can give it the file and ask:

• Which paths make up this section of the logo?
• What is preventing this mark from changing color?
• Can you make the outline draw itself on screen?
• Can each section respond independently to a hover?
• Can this adapt automatically to light and dark backgrounds?
• Can you turn the brand colors into reusable variables?
• Can you show me what every group controls?

Previously, those questions probably became tickets or requests. Now they can become part of the design process itself.

The designer does not have to describe an animation and wait to see how someone else interprets it. They can create a version, test it, adjust the timing, and decide whether it feels right.

That is technical work, even if the designer never manually writes the code.

Technical does not have to mean “developer”#

We have treated technical ability as knowledge of syntax: knowing which tag to write, which property to change, or which JavaScript function to call.

LLMs weaken that definition.

The more important skill becomes understanding the system well enough to direct it. What are the pieces? How should they behave? Which relationships need to remain intact?

What should happen when the screen changes or a person interacts with the design?

Those are already design questions.

The LLM handles more of the translation between those decisions and the code required to express them. That lets designers move deeper into implementation without abandoning their actual expertise.

They are not becoming junior developers. They are becoming more technically capable designers.

Structure is now a design decision#

This also changes how assets should be created.

An SVG containing sensibly named groups is easier to understand than one containing 200 paths called path-1 through path-200.

A logo with intentional color variables is easier to adapt than one with the same hex value buried in twenty places.

Layer names, grouping, hierarchy, and reusable values are no longer cleanup for developers. They determine how easily a design can be understood and transformed by people and models later.

The underlying structure becomes part of the design.

A clean SVG can become an animation, an interactive explainer, a themeable product element, or a generative system. A flattened asset can mostly remain what it already is.

The distance between designing and building is shrinking#

SVG is particularly good at revealing this change because the visual object and its implementation are the same file.

But the larger pattern goes beyond SVG.

Designers can now inspect components, adjust responsive behavior, test motion, explore states, and prototype interactions through conversation.

They can work closer to the final material instead of stopping at a representation of it.

That does not eliminate the need for developers. It creates a better starting point for collaboration.

Designers can arrive with more than a static frame and a description of what it should do. Developers can engage with a tested behavior instead of interpreting one from scratch.

I started by trying to explain why SVGs matter.

The interactive component made a bigger point: the technical layer of design is becoming accessible to the people who understand the design best.

The logo was already code.

Now the designer can work with both.