From "the designer who delivered screens" to the designer who reclaims control.
David Martín, Product Designer and Co-founder of Velada.app opens by framing the shift as a historic moment, not a passing trend: "I think that now, with Vibe Coding, we're returning to this point… where designers had total or near-total control over the product".
What makes that statement powerful isn't nostalgia — it's the practical consequence. If the designer is back to touching "the real thing" (a working product), it changes the pace, the criteria, and even the type of decisions they can make: "we can design while we build".
Key takeaways
- If you can "design while you build", the handoff ceases to be the bottleneck.
- Reclaiming control doesn't mean doing everything: it means being able to validate sooner and better "without needing to wait for development teams".
Back to Dreamweaver: why the déjà vu matters (a lot)
To explain the current moment, David goes back to the beginning: "Dreamweaver and Flash" as symbols of an era where "very often the designer and the developer were the same person".
He then describes the "loss of control" as the industry professionalised and design became separated from development: "we were designing web pages… with Photoshop" and had to produce extra documents specifying "padding… margins… text sizes" by hand.
Key takeaways
- History repeats itself: every tool shift redefines the role; today "we're returning to this point" of expanded control.
- If your process still relies on "specifying things manually", you're operating with a pre-AI mental model ("that wasn't efficient at all").
"The great moment" for digital product
David puts it plainly: "we are at the great moment for digital product".
His three reasons? Less friction to create, greater speed, and more autonomy: "costs and barriers to entry are being reduced", "design cycles are getting shorter", and "the designer… regains genuine autonomy".
Key takeaways
- Your competitive advantage is no longer "making screens" — it's learning faster thanks to shorter cycles ("reducing it to weeks or days").
- Autonomy isn't absolute independence: it's the ability to move the product forward with fewer dependencies ("without needing to wait for development teams").
A word of caution: process still matters
David tempers the hype with a key idea: "the design process is still important".
It's not "prompt → app → success". He insists on the full cycle: "research… ideation… prototyping… testing" and on the fact that "without the process we won't get anywhere".
Key takeaways
- Vibe Coding accelerates, but it doesn't replace discovery ("they're still incredibly important").
- If your team is cutting research for the sake of speed, you're accumulating product debt ("without the process…").
What exactly is "Vibe Coding"
David summarises it like this: "Vibe Coding is building products through a conversation".
The disruptive part isn't "using AI" — it's the shift in focus: "the code stopped mattering… he simply wanted the product to work", even when errors appeared: "he'd take a screenshot of the error… 'fix it'".
Key takeaways
- You move from designing "representations" to manipulating real behaviour ("conversing" rather than laying out screens).
- The new "flow" resembles directing more than executing: "I want to change this action…" and iterating to adjust.
The new design process
The design process "reorders itself": implementation first, learning sooner
David gives a direct example: because "the timescales are so short", perhaps "we can reorder it" and use implementation as an engine for ideation.
He reinforces this later in the Q&A: perhaps it no longer "makes sense to go through all these prior phases before launching" because you can "build a very simple version… launch it, test it… and then go back to ideation".
Key takeaways
- If the cost of "testing" falls, your process can pivot towards learning by prototype ("launch it, test it…").
- What matters is shortening the time to insight, not "completing phases" ("swap them around because there's no longer such a barrier").
Designing while you build: the Lovable Prompts case
Here David gets very specific: "the better the initial prompt… the better the result".
Instead of going through Figma first, he went straight to execution: "I didn't go through Figma. I went directly… built an MVP… and it worked". Then, once there was validation, yes: "I go to Figma… give it a bit of a polish".
Key takeaways
- If you can build fast, Figma becomes post-validation refinement ("a bit of a polish"), not a mandatory starting point.
- A good prompt is strategic design: "very detailed… features… look and feel…" is, in practice, product specification.
The tool, created by him, Lovable Prompts generates optimised prompts for vibe coding projects in an optimal way. Here's a comparison of what you get from a basic idea versus an optimised prompt:
So you can try Lovable Prompts, David is giving us a 40% discount code — just enter INTERACTIUS directly at checkout and enjoy!
Designing with data: when the designer accesses SQL without knowing SQL
David highlights an uncomfortable reality: very often "you end up designing without that data and going on instinct".
His point is that access changes now: "we don't need to know SQL… because we can access it… just by chatting". And he gives a real example: he asked which were the most frequent use cases and ended up choosing the landing page example with evidence: "Dashboard… is the… most repeated one".
Key takeaways
- If your barrier was "I don't know how to request data", your barrier now is "I don't know what to decide to measure".
- The designer can push data-informed decisions without depending on other teams' queues ("I couldn't have done this… I would have had to ask the development team").
100% functional prototypes: from "click dummies" to real flows with APIs
David draws a clear distinction: before, "we could make functional prototypes… but they're never like the final product".
Now, he says, they can be: "we can build 100% functional prototypes", with "login… password recovery… real information… APIs". His most compelling case is the fintech one: "in around two weeks… build a product… with their real data".
Key takeaways
- When the prototype has real data, testing changes category (better comprehension, more actionable feedback): "if we use the user's real data, the results… are much better".
- "Prototype" no longer means "simulation": it can be a validatable controlled environment ("it was going to be a controlled environment").
Why "Figma to Code" isn't the best path
David doesn't dismiss it as impossible, but as limited: "that can already be done… but… we're missing out on this entire process".
His critique is one of focus: if you reduce AI to converting UI into code, you give up the key advantages of the new paradigm — learning speed, real prototypes, data access, and continuous decision-making. "it's not just about taking my design and converting it to code".
Key takeaways
- The opportunity isn't to automate the handoff: it's to redesign the way you work ("we're losing so many interesting parts").
- Leave "the boring stuff" to the machine: "replicating a thousand screens… empty states…" and use your time to "solve problems".
The new role: from interface designer to decision designer
Here the central thesis emerges: with generative interfaces, "a moment will come when we no longer have to design interfaces, but design processes".
That's why David states the shift plainly: "it will go from interface designer to decision designer". And he specifies the type of decisions: "when things are shown… how they're shown… what implications they have".
Key takeaways
- Your value increases when your product becomes adaptive: decisions around rules, context, personalisation, and presentation.
- Designing "decisions" requires thinking in scenarios: "providing lots of scenarios… features…" (this is already behaviour design).
The hardest skill: embracing imperfection without sacrificing quality
David touches on a sensitive nerve in design: "I know we all love being pixel perfect".
But he reframes it as a trap: "it's not as relevant as we think it is" and, what's more, AI forces you to work with uncertainty: "it's a black box… we don't know what's happening in between".
Key takeaways
- Change the standard: "good enough to be useful" before "perfect" ("at least useful… the minimum necessary").
- The obsession with pixel perfection can hold back learning: "that can slow the process down".
Not all magic: security, limitations, and why you'll still need developers
David is explicit: "we're going to keep needing developers. And I think, in some cases, more than ever".
And he flags two specific risks. One: robustness if you lack a technical foundation ("if you have no idea about code it's very hard… to build something robust"). Two: security ("a huge number of security issues… vulnerabilities…"), including from personal experience: "two products… got hacked".
Key takeaways
- For production, technical reviews are non-negotiable: "I'd ask someone who's an expert… to review it".
- Learning "something" about code becomes a quality lever again: "it might do us good to start learning a bit of code… at a surface level".
Tools and mental stack: from co-pilots to building environments
David shares his toolkit without pretence: "I use ChatGPT a lot… Claude and Gemini" and explains use cases (copy, testing algorithms, artefacts, images).
In Vibe Coding, his routine is incremental: "I use Lovable to get started… when the product gets… more complex, I move to Cursor". And he leaves an important signal for UX Leads: the barrier to entry remains a factor: "Claude Code… is used in the terminal… there's more of a barrier to entry".
Key takeaways
- Think about tools by phase (fast start vs scaling): "I start there… then move to Cursor".
- Adoption depends on ergonomics: "very friendly UI… you don't need to know anything about programming" accelerates experimentation.
- In the video you'll find a list of tools for each moment — you're sure to discover one you didn't know about.
3 key insights
- The shift isn't about "making UI faster": it's about getting back to touching the real product, because "we can design while we build".
- The role is evolving towards judgement and structure: "from interface designer to decision designer".
- Speed doesn't forgive shortcuts: "the design process is still important" and security is a real risk ("a huge number of security issues").
If you want to see the full context, the examples, and the Q&A, we've left the full video here for you.
