Is the battle between UI designers and developers finally over?

For time immemorial, designers and developers have battled over digital UI. Designers made pretty pictures - logos, buttons, and the other key components that make up a design system - and the developers had to translate the pretty pictures into code.

Cue an inevitable battle between designers who think every pixel matters and developers who think the designs are not practical. That this is not time well spent.

The losers? The companies spending a ton of money and time on UI work that ended up as unused PDFs.

Now, using our highly-skilled designers we can bypass all of that trouble. We just give developers everything in code. Fully front-end ready. No translation required. No stress. No time wasted.

Here's the story of how we brought peace ....ironically, through an app for hunters.

From JegerHub to HUNTA without the typical pain.

HUNTA is a Norwegian marketplace that connects hunters with the landowners whose terrain they want to hunt. It used to be called JegerHub. When the team announced the change, they explained that the old name no longer matched where the product was heading, and that they wanted something shorter and sharper that felt at home both on a Norwegian mountaintop and on a screen anywhere in the world.

They asked us to build the new identity in, shall we say, a quite limited time frame. So we did key parts by hand in Figma and then exported into a real, coded design system rather than a static file for someone else to rebuild later.

That second part is the one worth talking about. On most redesigns what can be frustrating is waiting for a developer to recreate what the designer has created. A brand designer makes a kit, a product designer turns it into screens, a developer rebuilds those screens in code, and eventually someone puts it online. Each step loses a little of the original intent and adds another "we'll sort that out later." We ran the whole thing from Figma to GitHub with one product designer.

It starts by hand, in Figma

We started in Figma. A designer built the fundamentals by hand: wordmark, an earthy paper-and-ink palette, accent colours, a set of stamps, and a field-guide illustration style.

The direction came straight from the brief. HUNTA wanted the app to feel like "a notebook you actually trust", the kind that survives a season in the field. 

You don't need to be a Figma expert for this part. Figma just holds the decisions a person makes, like a logo, a few named colours, a type pairing and a handful of components. That is enough to start building.

From a Figma file to a design system in code

Next we made a small figma file with only the essentials downloaded it as a .fig and gave it to Claude Design to turn the kit into a structured design system.

We set the direction and made the final calls. When something looked off we said so in plain, slightly Norwegian English ("too much brown", "the swatches don't read as colours", "make the testimonials feel like field notes"), and it made the change so we could look again.

From styleguide to a live front-end

A styleguide doesn't help much if it's only a PDF that's being actively ignored by the developer. What we made was a React app with real components, design tokens, and a working front page we called Feltkart (Norwegian for "field map"). -This all made it inexcusably easy to implement,

Claude Code wrote it, ran it, took screenshots of its own work, and caught and fixed bugs as it went. One is a good example. Someone reported that the colours "didn't show up", but only in Safari. Claude traced it to a newer CSS feature the pale swatches relied on that Safari wasn't handling, and replaced every use of it with a fixed value that looked identical. Same result in every browser, without the fragile dependency.

Every change went through the same short loop: edit, build, check it in a real browser, commit to GitHub, deploy to Vercel, and it was live in about half a minute. 

Keeping everything in GitHub meant a clean record of every decision and nothing stuck on one person's laptop. Deploying to Vercel meant there was always a real URL for the client to react to and see the design on a real phone or laptop browser rather than a mockup in a slide.

Why the loop matters

None of this is really about whether AI can design or write code. What mattered was how short the gap got between having an idea and seeing it live. 

For example, we got some feedback from actual hunters, we can't share what they thought the original "U" in the word mark looked like, but it certainly inspired a change. 

We made the change to the logo wordmark and updated it across every lockup and stamp instantly. Feedback went straight into the design system instead of a backlog.

What this actually changes

For a service redesign, the usual constraints are coordination and cost/time. You need a brand person, a product designer, a developer, and enough calendar to pass the work between them. 

When those steps fold into one loop, the sums change. One person with good judgement can take a project from rough idea to live site, directing while Claude builds the design system.

It's worth being clear about what this isn't. It isn't "good design is now cheap", and it isn't a way to manage without designers. 

We can't stress enough how taste and the decisions are still human, and they still start by hand in Figma. And that will make you stand out from all the purely AI generated designs out there.

What gets cheaper is the rollout: the slow, lossy handoff from a design file into working code. What you keep at the end is a design system your team can actually build on, versioned in GitHub.

The result

HUNTA wanted an identity that, in their words, "feels familiar and dependable, but belongs in 2026": the old logbook brought into modern type and colour. 

That is what is now live, along with the design system and the front-end underneath it, all built in a handful of sessions and all in code their team can keep working on.

You can see it at hunta.no/en. We kept hold of the design decisions; the tooling just took out the slow part in the middle.