I spent the first few years of my career building exactly what was in the spec. Pixel-perfect, line-by-line, no questions asked. Then I started working with Rainui at RIVER and realised that a spec isn't a blueprint - it's a starting point for a conversation I wasn't having. It changed how I think about the engineering side of enterprise projects.
Two Different Languages
Designers talk about feel, flow, and experience. Developers talk about state, logic, and constraints. Neither language is wrong. But when a creative director says "this section needs to breathe" and a developer hears "add padding," you end up with something that technically matches the feedback but misses the point entirely.
I had to learn to translate. Not just Figma-to-code translation, which is mechanical. I mean understanding what the design is trying to do emotionally, and then figuring out how to make the code serve that goal.
When I design something, I'm thinking about how someone will feel when they use it. The whitespace isn't empty - it's giving the content room to land. The animation isn't decoration - it's guiding attention. When a developer understands that, everything changes.
Rainui Teihotua
Chief Creative Officer
That quote sums up the gap. Rainui isn't thinking about CSS properties. He's thinking about what a user experiences. My job is to take that intent and turn it into something a browser can render.
What I Got Wrong Early On
When I first started working with design teams, I'd push back on things that seemed impractical. An animation that would be complex to implement. A layout that didn't fit neatly into a grid system. A hover state that required custom JavaScript instead of a simple CSS transition.
The push-back was technically justified. But it was often wrong in context. A complex animation that takes two extra hours to build might be the thing that makes an entire page work. Saving those two hours and shipping a flat, static version saves time but loses the design's purpose.
I'm not saying developers should never push back. Sometimes a design genuinely doesn't work on mobile. Sometimes an animation will cause performance problems. Sometimes a layout assumption breaks at certain screen sizes. Those are legitimate constraints that designers need to hear about.
The difference is between "this is hard, so let's not" and "this won't work because of X, so here's an alternative that achieves the same thing."
The Figma-to-Code Gap
Figma designs exist in a perfect world. Fixed viewport, ideal content length, no loading states, no error states, no edge cases. The developer's job is to take that perfect-world design and make it work in the real world, where screens are different sizes, content is unpredictable, and things go wrong. This is where design systems earn their keep.
Good collaboration means talking about these gaps early. Not after the build, when the developer ships something that doesn't match and the designer is frustrated. Before the build, when the developer can say "what should happen when this text is three lines instead of one?" and the designer can make that decision intentionally.
I've started keeping a list of questions I ask about every design before I write a line of code:
- What happens on screens narrower than 400px?
- What does this look like with real data instead of placeholder content?
- What's the empty state? The loading state? The error state?
- If the user has 200 items instead of 5, does this layout still work?
- Which elements are fixed and which should scale?
These aren't criticism. They're the questions that prevent the build from diverging from the design halfway through.
When to Trust the Creative Director
I've learned that when Rainui makes a design choice that seems unusual - an unconventional layout, an unexpected colour combination, a deliberate asymmetry - there's usually a reason. He's been designing for over 20 years. He's seen patterns I haven't.
I love it when Hassan asks me why I made a choice. Not because he's questioning it, but because he genuinely wants to understand the thinking. That means when he builds it, the result carries the intent, not just the appearance.
Rainui Teihotua
Chief Creative Officer
There's a balance. Blind execution produces fragile implementations because the developer doesn't understand what matters and what's flexible. Constant questioning slows everything down and erodes trust. The right spot is asking "why" about the choices that aren't obvious, and trusting the rest.
Practical Things That Help
Shared vocabulary. We've built up terminology over the years. When Rainui says "tension" he means a specific visual relationship between elements. When I say "breakpoint" he knows I'm talking about a screen width where the layout needs to change. We don't have to explain basics anymore.
Early prototypes. I'll build a rough version of a complex interaction before polishing the rest of the page. Rainui can see it in a real browser, on a real device, and give feedback while changes are still cheap. This catches the prototype trap before I've spent a day on implementation details.
Design reviews in the browser. Screenshots lie. They don't show scroll behaviour, animation timing, responsive breakdowns, or interactive states. We review work in the browser whenever we can. It takes five minutes and saves hours of back-and-forth.
Honest conversations about constraints. If something is going to take significantly longer to build, I say so. Then we decide together whether the effort is worth the result. Sometimes it is. Sometimes we find a simpler approach that achieves 90% of the effect at 30% of the cost. This is where delivery methodology matters more than anyone expects.
The Real Skill
The technical part of being a developer - writing code that works - is table stakes. The harder skill is working with people who think differently than you do and producing something better than either of you would make alone. It's the same principle behind building a team that ships.
That's what collaboration with a creative team actually requires. Not just translating Figma to code. Understanding the thinking behind the design, communicating constraints honestly, and being willing to put in extra effort when the design demands it.
I'm still learning this. But the projects where Hassan-the-developer and Rainui-the-designer are genuinely collaborating produce better work than the projects where I'm just executing a handoff.
If you want to see what developer-designer collaboration looks like in practice, take a look at how we work.