Hey there! This is a 🔒 subscriber-only edition of ADPList’s newsletter 🔒 designed to make you a better designer and leader. Members get access to exceptional leaders' proven strategies, tactics, and wisdom. For more: Get free 1:1 advisory | Become an ADPList Ambassador | Become a sponsor | Submit a guest post
This newsletter is brought to you by Genway AI—automate the entire user interview process, delivering insights that help you create user-centered designs faster than ever. No scheduling, no staffing—just fast, actionable insights for your next design sprint.
Friends,
If you’ve ever spent hours perfecting Figma prototypes, only to watch your vision drift in the handoff to engineering, you’re not alone. For years, Elie’s design process was all about pixel-perfect layers and endless tweaks-until a quiet revolution started reshaping my workflow. It began with a few experiments using AI tools that, to my surprise, kept outperforming my old habits. The result? He found myself spending less time on appearances and more on building real, working products faster than I ever thought possible.
One Sunday, he ditched the Figma routine. Instead, he sketched out a flow in Miro, generated a spec with AI, and within hours had a running React prototype that engineers could fork and improve the very next day. No more static files, no more endless debates over gradients-just working code and real feedback from users. The shift was so dramatic that even our most skeptical engineers became advocates for this new approach.
In this edition, he is sharing the playbook that helped him-and can help you-move from static mockups to live, testable products in record time. We’ll explore the prompts, the pitfalls, and the new skills designers need to stay ahead as AI transforms our field.
Let’s dive in 👇
Elie Majorel is a builder who transforms complex problems into intuitive products with measurable ROI. At Coveo, he implements GenAI-powered Search solutions that ensure transparent retrieval while preventing hallucinations across enterprise environments. With 15+ years spanning startups and Fortune 500s in France, Germany and Canada, Elie revolutionized pharmaceutical R&D at LabTwin, reducing documentation time by 30% while eliminating workflow interruptions. Like a marathon runner pacing for the long haul while adapting to changing conditions, he blends user psychology with business strategy despite regulatory hurdles. Whether co-creating product vision with C-levels or optimizing RAG systems, Elie ensures AI delivers genuine value to the humans behind every screen.
You can follow Elie on LinkedIn or Medium
In the last few months my design workflow changed completely. After years of crafting pixel perfect prototypes and animations in Figma I moved to a faster approach that brings engineers into the loop from day one. The shift was not planned. It grew from small tests with AI tools that kept beating my old routine.
One Sunday I opened Miro, sketched a few boxes for a new agent search, and copied the flow into Claude. Claude wrote a clear spec. I pasted that prompt into Lovable, pressed generate, and two hours later a working React repo ran in a sandbox. Engineers forked the code the week after. Leaders clicked the demo and said keep going. Two hours from idea to running product. No Figma layers. No endless handoff.
I share the playbook below so other designers can try the same switch. The goal is simple. Spend less time on appearance and more time on impact.
For years, my path looked like this:
Sketch early ideas
Build low-fidelity screens in Figma
Get Product and Engineering feedback
Iterate the designs
Build high-fidelity screens in Figma
Link flows into an interactive prototype
Hand “final designs” to Engineers
Watch implementation drift away from what I drew
End up with something that didn't look like the team vision
Four pain points slowed every release:
Time sink. About half of each week went to tiny layer tweaks
Reality gap. Technical limits surfaced late in the sprint
Maintenance cost. Design tokens aged fast and broke the system
Focus on looks. We debated gradients while users stayed blocked
Craft is still worth the effort but the drag hurts the team.
Today I start with words and black and white boxes, then let the model write the first cut of code.
📌 Rules that keep the loop tight:
Sketch in plain shapes until the flow passes tests
Put user stories, edge cases, and acceptance steps inside the prompt
Touch UI details only after the prototype proves value
A task that once took a full week now fits into one morning.
Let me walk through my actual prompt for the agent search project. It looked something like this:
Create a detailed specification for an agent search interface with these requirements:
- Users need to search across multiple data sources (Salesforce, Zendesk, internal DB) - Results should show agent name, status, skills, and current workload
- Interface needs filters for availability, skills, and team
- Should support both keyboard navigation and mouse interaction
- Include error states for no results and system unavailability
- Add acceptance criteria for each main feature
- Include relevant user stories, edge cases we should handle, and a test plan covering key scenarios.
This 30-minute investment gave me a structured specification document that both product and engineering agreed with before I even started building. No more "wait, that's not what we meant" moments three weeks in.
On 15 April 2025 Figma filed confidential papers for an IPO (Reuters, Axios). The date matters because prompt-to-code tools like Lovable, v0, and Cursor shrink the space Figma owns. When anybody can move from prompt to running code in hours the value of a static design file drops.
Kevin Weil, Chief Product Officer at OpenAI, captured the point recently on Lenny's Podcast:
"We should show live demos instead of files. Build a proof in thirty minutes and test ideas fast."
The key market shifts:
Each era makes the previous look slow and limited.
When I started working as Product Designer at LabTwin in Berlin, our design process was firmly in the Product Design era. We had beautiful Figma files with perfect interactions, but the gap between design and implementation was frustrating. Sound familiar? I saw the same pattern during my time working on voice assistants for scientists. The mismatch between our Figma visions and final implementations was a constant source of tension.
I think and talk with users more, argue with spec docs less, and ship code sooner.
My calendar looks different too. Fewer meetings about UI details means more time for thinking and testing with real users.
What surprised me most was how engineers reacted to this approach. When I shared the Lovable-generated repository for our agent search, our senior developer's response wasn't what I expected:
"This actually makes sense. The code structure is clean and I can see exactly what you're trying to achieve. Much better than trying to replicate a Figma file that has pixel-perfect UI but impossible interactions." And I am not even talking about the (pricy) licenses you need to pay for the engineering team just for them to check code snippets in the dev mode…
The difference? With working code, engineers can focus on enhancing functionality rather than deciphering visual intent.
Quick loops expose weak spots early. Fix them and keep going.
I encountered several of these risks firsthand. For example, my first Lovable-generated prototype had security issues that engineers flagged (Lovable has actually released a feature to streamline that process!). Rather than seeing this as a failure, we used it as an early check - something that would have surfaced much later in our old workflow.
For brand drift, we developed a simple solution: a 30min "brand alignment" pass after the prototype proves valuable but before wider release. These tweaks get added to my prompt library to generate faster future projects.
To handle prompt drift (where similar prompts produce inconsistent results), we started treating prompts like code - storing them in our version control system with comments explaining why certain phrases worked better than others. This prompt library has become a valuable team asset.
Starting small helps teams adjust to the new method:
Begin with internal tools where polish matters less
Try a customer-facing feature with limited scope
Add a full user flow after the team builds confidence
Tackle a major feature when everyone sees the value
Start with structure. Draw the flow in Miro or on paper. Keep it plain.
Generate the spec. Prompt example:
“Create a product spec for an agent search that joins many data sources. Add user stories, tech needs, edge cases, and test plan.”
Build with a prompt-to-code tool. Use Lovable for a clean web start, v0 for richer flows, or Cursor if you enjoy tweaking code.