Resources
Articles, guides, templates, and insights on product design and AI.
Getting started with Claude Code
Complete guide for designers: from installation to deployment, visual quality, skills, and Figma MCP.
Claude Code and Figma MCP: designing and implementing without switching tools
For the past few months, I have been using Figma MCP to read my designs directly from Claude Code, generate components that match the design, and iterate in real time between the mockup and the codebase. The workflow compresses the design-to-integration cycle from days to hours. I design in Figma, then Claude Code reads the component specs, spacing, tokens and layout through MCP, and generates production-ready code that stays faithful to the original intent. The interesting part is not the speed. It is the quality of the feedback loop: when I see the result instantly, I make better design decisions because I can evaluate them in context, not in isolation.
Designing a design system in Figma, then implementing it with Claude Code
I recently ran a complete experiment: designing a full design system in Figma (tokens, components, variants, documentation), then implementing it on a dedicated site built in Astro and Tailwind, driven entirely by Claude Code. The design system covers foundations (color, typography, spacing, elevation), atomic components (buttons, inputs, badges, tags), and composite patterns (cards, navigation, forms). What this approach changes in the relationship between design and development is fundamental. The design system becomes a single source of truth that both the designer and the AI can read. Claude Code does not interpret screenshots, it reads structured design data. The gap between the intended design and the implemented result shrinks to almost nothing.
Training non-designers on generative AI: field notes
I have started running AI workshops for entrepreneurs and product teams. The most common misconception is that generative AI replaces skills. It does not. It amplifies what you already know. A product manager who understands user needs will write better prompts than a junior who copies templates. The training works best when I start with their actual problems, not with the tool.
50 apps in one year: what AI prototyping actually changes in practice
Since launching Condamine Apps, I have prototyped and deployed 50 functional web applications using Claude Code, Bolt, and Cursor. The speed gain is real: what used to take weeks now takes days. But the design decisions remain mine. AI accelerates production, it does not replace the thinking. The biggest shift is that I can now validate ideas with real, working prototypes instead of static mockups.
Using Claude Code across an entire product design project
From functional scoping to screen production, from prototyping to documentation, I integrated Claude Code into every phase of a product design project over six months. For scoping, it helps structure requirements and generate user flow diagrams. For design, it reads Figma files and produces component code. For prototyping, it builds functional applications deployed on Vercel in hours. For documentation, it generates technical specs and handoff materials. What works: the acceleration is real on repetitive tasks, code generation, and rapid iteration. What slows you down: ambiguous instructions produce ambiguous results, so the designer's ability to frame precisely becomes even more critical. What changes: the designer's posture shifts from someone who delivers screens to someone who orchestrates a production pipeline. The craft does not disappear, it evolves.
Why I organize design work in seasons, not sprints
At France VAE, I restructured the design workflow around one-month seasons with three delivery cycles each. Sprints create urgency but they do not create clarity. A season gives enough time to frame a problem, explore solutions, and ship something tangible. Each season has a theme, a set of deliverables, and a retrospective. The team went from reactive to intentional within two seasons.
Running design thinking workshops in a public service context
At beta.gouv.fr, I facilitated two-day workshops with field actors who had never heard of design thinking. The method worked, but only after I stripped it of all the jargon. No "How Might We", no dot voting theater. Just clear questions, sticky notes, and structured conversations. The output was better because the participants felt respected, not lectured.
The PM-Designer partnership: three principles that make it work
Every productive PM-Designer collaboration I have experienced rested on three things. Rigorous preparation: every workshop has a scenario, exercises, and a defined deliverable. Continuous transparency: the PM sees the design evolving in real time, and we adjust together rather than waiting for a big reveal. Documented decisions: every trade-off is logged so the team never relitigates the same questions. On responsibilities, the PM owns the specs, the designer feeds them with annotated mockups and documented user journeys. We align on priorities upstream and present to stakeholders together. Design moves faster when the PM trusts the process and the designer respects the product constraints.
Hiring designers when you are the only designer
When I joined UNOWHY, I was the only designer for five products. The instinct is to hire someone who works like you. The better move is to hire someone who complements you. I recruited five designers over three years. Each one brought a skill I did not have: motion, research, systems thinking. The team became stronger precisely because I did not try to clone myself.
Design scoping is 80% of the work
Most design projects that go sideways do so before a single screen is drawn. The brief was vague, the scope was implicit, the success criteria were missing. I now spend the first week of any engagement on a scoping document: what problem we solve, for whom, what we deliver, what we explicitly do not do. It is not glamorous work. It is the work that makes everything else possible.
Template: Design Scoping
A framework to frame design problems, scope, and goals before starting UI.
Process: PO / Design Sync
Rituals and workflows to align Product Owners and Designers efficiently.
Workshop: Design Teardown
Workshop template for analyzing and critiquing existing interfaces collectively.
Checklist: Feature Design
A granular checklist to ensure quality from kickoff to handoff.
Process: UI Slicing
Methodology to break down interfaces into atomic components for devs.
Figma: File Status
Naming conventions and status tags for keeping Figma files clean.
Building a product roadmap when the product does not exist yet
SQOOL Extend started as a PowerPoint slide in a board meeting. No specs, no users, no competitive benchmark. To build the roadmap, I ran five stakeholder interviews, mapped the assumptions onto a risk matrix, and designed a three-phase MVP plan. The first version shipped in five schools within four months. The roadmap was not a Gantt chart. It was a sequence of bets we could validate quickly.
How a design culture actually takes root in a product organization
At UNOWHY, I worked to make design a shared practice beyond the design team. I invited product managers to observe user tests. I ran cross-functional ideation workshops with business, tech, and design together. I documented every design decision so the team could reference them instead of reopening debates. Small, repeated actions woven into the daily work. Over time, six departments became involved in the design process: tech, product, customer success, design, management, and end users. The most convincing argument was always the simplest: a thirty-minute user test that prevented three weeks of development in the wrong direction.
A design system for five brands: the real challenge is not technical
At UNOWHY, I built a unified design system across SQOOL, SQOOL Extend, SQOOL Protect, Hi SQOOL and the corporate brand. The Figma architecture was straightforward: shared foundations, brand-specific tokens. The hard part was getting five product managers to agree on shared components. I spent more time in alignment meetings than in Figma. The system cut design time by 60%, but only because the team trusted it.
Moving from designer to design lead: what nobody tells you
The biggest adjustment is not managing people. It is letting go of the craft. When I became Design Lead at UNOWHY, I had to accept that my team would design things differently than I would. And that was fine. My job shifted from making screens to making decisions: hiring, process, priorities, stakeholder alignment. The designers who struggle most in lead roles are the ones who cannot stop designing.
Designing for 500,000 users who never asked for your product
SQOOL was deployed in 465 high schools across Île-de-France. The students did not choose it. The regional government did. Designing for captive users changes everything. You cannot rely on engagement metrics or NPS. You have to observe actual behavior in classrooms, talk to teachers, and watch where students get stuck. The interface has to work on the first try because there is no onboarding flow when the bell rings.
When the product direction is unclear, design creates the most value
At UNOWHY, I inherited SQOOL Connect, an aging Android launcher with dozens of features and no clear product direction. Instead of redesigning the interface, I mapped the teacher-student journey across all five applications. That mapping became a prototype for a unified vision, which I presented to the executive committee. We built a testable demonstrator and put it in front of real users. The results pointed toward specialized applications rather than a single launcher. Connect was shelved. Five focused products replaced it, and the suite reached 500,000 users. Structuring the ambiguity upfront saved months of development on a product that would not have solved the real problem.
Storybook as a negotiation tool with developers
At Dailymotion, I introduced the team's first UI Kit with Storybook. The initial goal was documentation. The real impact was negotiation. When a developer wanted to skip a hover state or simplify a component, I could point to the Storybook page and say "this is what we agreed on". It moved design-development conversations from opinions to shared artifacts.