From Frames to Function

For years, digital design has followed a familiar sequence: design the experience in Figma, get it approved, document it, hand it to development, and then work through the gap between what was designed and what was built.

We’re changing that process at ANML.

Once we’ve established the strategy and design language, we’re increasingly moving from static design into functional prototypes built in code. Our designers work in the browser, explore motion alongside layout, define interaction with greater precision, and build reusable components as the experience takes shape.

The result is not less design. It’s design happening closer to the final medium—with far less left to interpretation.

Key takeaways

• Discovery, strategy, and brand direction still come first.

• We build a shared project knowledge base that Claude continuously references throughout the process.

• Figma remains an important exploration tool, but it is no longer where every design decision has to be resolved.

• Designers move fluidly between Figma, Claude Code, and the browser.

• Motion, scrolling, easing, responsiveness, and interaction are designed as part of the experience, not documented afterward.

• Our designers work in GitHub, deploy functional prototypes, and review those prototypes directly with clients.

• We build the design system in code as we go, creating a more direct path from design to development.

Why are we using less Figma?

Figma is an excellent design tool. We still use it every day.

What’s changing is the expectation that every design decision needs to be resolved there.

Digital experiences don’t exist as static frames. They move. They respond. They change state. They react to scrolling. Elements enter and leave the viewport. Navigation transforms. Layouts adapt.

A traditional design process can represent those ideas through breakpoints, component states, motion studies, prototypes, annotations, and specifications.

But there is still interpretation between the representation and the final experience.

How does something enter the page? When does it begin to move? How quickly does it accelerate? How does it ease into place? How does it react to scrolling? How does that behavior change across screen sizes?

We can now answer more of those questions directly in the medium where the experience will ultimately live.

What does our process look like now?

We aren’t asking designers to become traditional front-end engineers.

We’re expanding the material they design with.

Our designers use Claude Code alongside Figma-connected tooling, a shared project knowledge base, GitHub, and deployed browser-based prototypes.

The process looks roughly like this.

1. Start with discovery, immersion, and shared context

We begin by understanding the business, audience, opportunity, goals, and constraints.

We define the experience strategy and establish the brand direction that will guide the work.

At the same time, we create a shared project knowledge base from meeting notes, discovery conversations, strategy documents, requirements, research, and other project materials.

That context stays active throughout the engagement.

Claude continuously references this shared knowledge base as we design and iterate.

That means the work isn’t happening from an isolated prompt. Claude has access to the goals, decisions, requirements, conversations, and strategic thinking that have accumulated throughout the project.

As the project evolves, the knowledge base evolves with it.

That allows us to move faster without losing the context behind the decisions we’re making.

2. Establish the design language

With the strategy in place, we define the visual and experiential language.

Typography. Color. Hierarchy. Grids. Imagery. Components. Interaction principles.

Figma remains particularly useful here. It gives us a fast, flexible canvas for visual exploration and helps us establish the foundations of the system.

But once that language is clear, we don’t need to design every page, breakpoint, state, and behavior as a static representation.

We can start making it functional.

3. Bring the design system into code

Once the design language is established, Claude Code connects directly to our Figma file and design system through an MCP.

This creates a bridge between the work we’ve established in Figma and the functional prototype we’re building in code. Claude can reference the components, styles, patterns, and design decisions already defined in the system, giving our designers a starting point that is grounded in the work we’ve already done.

We can pull that work into Claude Code and begin bringing it to life in a real browser.

That continuity is important. We aren’t starting over when we move into code, and we aren’t asking another team to reinterpret the design system from a set of static files.

We’re taking the design language we’ve already created and making it functional.

From there, the browser becomes another part of the design environment.

4. Build the system as we design

As patterns become established, we catalog components in code.

Those components can be reused across new functional pages, tested with different content, refined, and expanded.

The design system grows alongside the experience instead of being documented only after the work is complete.

As the system gets stronger, we spend less time rebuilding familiar patterns and more time solving the parts of the experience that actually need new thinking.

5. Branch, merge, and deploy

Our designers work in branches connected to the project repository.

As the work evolves, we merge those branches and deploy functional prototypes that our team and the client can access in a real browser.

Clients can navigate the experience, interact with it, resize it, experience the motion, and leave contextual feedback through BugHerd.

That makes the conversation much more concrete.

Instead of asking:

“Can you imagine how this will work?”

we can ask:

“Does this work?”

6. Move into production with less translation

By the time the work moves fully into production development, developers aren’t starting with a collection of static references and motion samples.

The component system already exists in some form. Behavior has been explored. Motion has been tuned. Responsive decisions have been tested. The client has interacted with the experience.

That doesn’t eliminate engineering work.

It reduces the amount of interpretation between design intent and implementation.

And that means less time spent specifying, redlining, recreating motion studies, and correcting mismatches during QA.

Is the creative process still iterative?

Absolutely.

Creative work has never been linear.

We don’t finish strategy, finish Figma, move into Claude, and never look back.

We move between tools based on what we’re trying to solve.

We might establish a direction in Figma, move into Claude Code to experience it in the browser, discover something that changes our thinking, and jump back into Figma to explore the idea visually.

Then we move back into code.

Figma → code → feedback → Figma → code.

Sometimes a visual problem is faster to explore on a canvas. Sometimes you need to scroll, click, resize, or feel the motion before you know whether an idea is working.

The shared knowledge base helps anchor that nonlinear process. Even as we move backward and forward, the goals, strategy, requirements, and decisions remain part of the context.

The process becomes a loop rather than a handoff.

Explore. Build. Experience. Refine. Repeat.

What does this have to do with functional branding?

A lot.

We think of a digital brand as more than a visual system.

It’s also a behavioral system.

A brand isn’t experienced as a collection of static moments. It unfolds.

How quickly something responds can feel like the brand.

How an image reveals itself can feel like the brand.

The restraint or energy of an easing curve can feel like the brand.

The way a page reacts as you scroll can feel like the brand.

These aren’t implementation details added after the identity is complete.

They’re design decisions.

Working in code lets us make those decisions while the visual language is still evolving.

A transition can be expressive or restrained. An interaction can feel precise, playful, quiet, or immediate. Motion can reinforce the same qualities as typography, color, imagery, and composition.

That’s what we mean by functional branding: the identity isn’t simply expressed through what an experience looks like.

It’s expressed through what it does and how it behaves.

Does AI make design simpler?

No.

It makes a different design process possible.

Tools like Claude Code make it easier for designers to work directly with functional software. But generating an interface is not the same thing as designing a good experience.

You still need judgment.

You still need to understand the user, the business, and the brand.

You still need to establish hierarchy, composition, rhythm, interaction, and behavior.

You still need to know when motion adds meaning and when it gets in the way.

The design work hasn’t disappeared.

Designers simply have a more powerful medium in which to express it.

What does this look like at enterprise scale?

We recently used this approach as part of our work on the Salesloft launch, a large-scale B2B digital experience.

B2B experiences bring their own kind of complexity. You’re often communicating sophisticated products to multiple audiences, across many pages and content types, while still needing the brand to feel distinct and coherent.

At that scale, designing isolated pages isn’t enough.

You need systems.

Components need to be reusable. Content needs to flex. Motion needs to remain consistent. Responsive behavior needs to hold up across many different scenarios.

Working with functional prototypes allowed us to see those relationships earlier.

We could test components against different content. Tune motion and scrolling in context. See how the brand behaved across pages. Resize the experience rather than speculate about intermediate states.

The feedback loop became:

Design. Run it. Scroll it. Resize it. Use it. Refine it.

For enterprise B2B work, that difference compounds quickly.

Are we replacing Figma?

No.

We’re changing where different parts of design happen.

Figma remains valuable for exploration, concepts, systems thinking, collaboration, and establishing a design language.

Code gives us another environment for design.

And there isn’t a clean dividing line between the two.

A browser experiment might send us back into Figma. A visual exploration in Figma might lead to another functional prototype. Motion might change composition. Responsive behavior might change the component structure.

The goal isn’t to choose Figma or code.

It’s to use the best medium for the decision we’re making.

What changes when design gets closer to the final medium?

For us, the biggest shift isn’t simply speed.

It’s fidelity.

The thing the client reviews is closer to the thing the developer receives.

The thing the developer receives is closer to the thing that launches.

And the behavior we design is closer to the behavior people ultimately experience.

There are fewer translations along the way.

That creates room for more precise motion, richer interaction, stronger functional branding, better responsive behavior, and more iteration where it actually matters: in the experience itself.

For years, digital design workflows have been built around increasingly sophisticated ways of describing what software should do.

We can now spend more of that time designing what it actually does.

We’re collapsing the distance between strategy, brand, design, motion, and development.

And we think the work is better for it.

ANML designs and builds digital experiences where brand, product, motion, and technology work as one system. If you’re rethinking a digital platform or building an experience where the details matter, let’s shape what comes next.