The shift toward interactive prototyping isn’t just changing how quickly designers can work. It’s changing where design ends and engineering begins.

Across Opera’s mobile products, designers are increasingly moving from static concepts to working prototypes, testing interactions, exploring technical constraints, and iterating before engineering gets involved.

I asked four lead designers, Oleksii (Opera Mini), Alex (Opera for Android), Alexander (Opera for iOS), and Ronan (Opera News), how these new workflows fit into their daily routine and what is changing about the way they design.

Across the four teams, here’s how the design-to-build loop used to work:

[ Idea ] ──► [ Figma ] ──► [ Engineering ] ──► [ First Build ] ──► [ Feedback ]

How it looks today:

[ Idea ] ──► [ Figma ] ──► [ Coded Prototype ] ──► [ Interaction ] ──► [ Feedback ] ──► [Iterate ] ──► [ Engineering ]

What looks like a longer chain is actually a faster loop. Interactions that might have taken days of back-and-forth can now turn into testable prototypes in a few hours. For larger concepts and test builds, the timeline shrinks from weeks down to a matter of days. Testing and iteration happen long before engineering needs to touch a line of code, and what gets handed off is no longer a static spec. It’s working code.

The prototype is the spec now

Ronan (News) used to submit hand-annotated Figma frames and prototypes to a front-end developer and audit the result once it was built. Now he can build coded prototypes himself using Claude Code. “I can build how it looks and how it works myself,” he says, “so I audit with Claude Code instead.”

Oleksii (Mini) describes the same shift from the other direction: not a faster way to build a spec, but the end of needing one at all. “The working prototype is often a spec,” he says.

Alexander (iOS) frames it differently: a middle layer between Figma and production that didn’t really exist before. “That sounds like a small difference,” he says, “but it changes the whole rhythm of the work.”

For Alex (Android), the shift looks more like “vibe coding,” using conversational prompts to rapidly test interactive ideas before touching the codebase.

Moving the boundary

Alexander (iOS) sees the core shift between design and engineering in collaboration, rather than speed. “The relationship becomes less about designing and handing something over to engineering,” he says, “and more about we’re shaping this together.” Engineers understand the intended interaction immediately, and designers get a better sense of what’s complex to build, because they’re the ones touching the code now.

Oleksii (Mini) frames the shift around feasibility, but points in the same direction: a working prototype changes the conversation from “Is this feasible?” to “Here’s what I found is feasible, let’s refine it.” Ronan (News) has found that a GitLab URL, sitting next to a Figma file, sometimes lands closer to how developers already work.

None of the four sees an expectation to ship production-ready code. The boundary between design and engineering hasn’t disappeared. It’s just moved.

For Alexander (iOS), that boundary matters more than it might elsewhere. Opera for iOS is a browser, and a browser is tied directly to the technology underneath it. “Interaction, performance, UI, and technology are so closely connected,” he says. “When the UI and browser technology are so closely linked, writing code helps designers see real technical limits much earlier.”

Four Teams. One Shift.

Which skills still matter

Where traditional design skills fit into this new workflow depends on how each designer works.

Ronan (News) and Oleksii (Mini) both think some hard skills carry less weight now: illustration, photo manipulation, pixel-perfect mockups. Both write and audit functional code, via Claude Code and real API integrations, so their view comes from building things with it directly.

Alex (Android) uses conversational prompts more for prototyping ideas and testing motion than for producing code himself, and his view follows from that. “I don’t think my role has changed so much so far,” he says. “We are developing products and bringing ideas to life. It’s not about making mockups or shifting pixels on the screen. Fundamental skills are more important now than before. Understanding color theory, typography, layout, navigation, motion, and UX design principles is essential.”

Alexander (iOS) lands somewhere in between: “There will always be boundaries, particularly around product judgment, systems thinking, technical architecture, and understanding people.” He thinks the mechanical parts of a designer’s job matter less. “Things like creating endless variations of screens, moving pixels around, or producing high-fidelity mockups just to communicate an idea can increasingly be accelerated by AI.”

No ceiling in sight

When asked about how new tools impact product design, all four designers were very optimistic.

Oleksii (Mini) sees no ceiling at all, calls it a genuine cultural shift rather than an upgraded toolkit, and says he hasn’t found a drawback yet.

Alexander (iOS) is equally enthusiastic: “Every time the cost of making something decreases, people start exploring things they wouldn’t have explored before,” he says. “That’s bigger than simply having a better tool.”

Ronan (News) thinks coded prototyping is the biggest game changer, and he expects it to keep expanding for a long time with every new LLM version bringing new strengths.

Where Opera product design is heading

Across Opera’s mobile teams, the distinction between prototype and finished product is already beginning to blur, and the designers expect that trend to accelerate over the next year.

Oleksii (Mini) and Ronan (News) both expect designers to start working directly with live APIs, real data, and existing codebases. The goal is to move past static concepts and hand developers functional UI that sits much closer to production-ready code.

Alexander (iOS) foresees a fundamental shift in how designers engage with the product. He expects designers to become “much more involved in prototyping and early implementation,” with the distinction between prototype and product becoming less rigid.

“I think we’ll see more designers experimenting directly with the technology,” he says, “rather than only describing how it should behave.” The exciting thing, he adds, “isn’t that AI can write code for us. It’s that it gives designers more ability to make things.”

The goal hasn’t shifted

Opera actively encourages teams to use modern tools to help design and build better products, but technology is only half the equation. What each designer chooses to build still comes down to judgment, experience, and listening to users. That part hasn’t shifted at all.

Faster prototypes, shorter loops, and working code don’t replace real user feedback. They complement it by putting something functional into people’s hands much earlier, making testing more realistic.

Ultimately, all of it points toward the same outcome: building better experiences for the people using them.

Download Opera for Android | Opera Mini | Opera for iOS

iOSOpera for AndroidOpera Mini for Android

---