Inside Lovable: Where Everyone Ships Code

Today, I'm sharing insights from my experience as a Product Designer at Lovable, a fast-paced environment where the lines between design and development are intentionally blurred. My journey into design began somewhat unconventionally; I'm a self-taught designer with a business school background, having spent a decade in London working in various software design roles, including Head of Design at Ancorstore, before joining Lovable full-time last December.

Lovable operates at an incredible speed. We serve approximately 20 million daily active users across all our applications globally, with around 10,000 daily active users in France alone. This scale demands that we move quickly, but the challenge—and our constant focus—is to maintain a balance between speed and quality. For any designer joining a company like Lovable, accepting this velocity and adapting to constant change is paramount.

The Evolving Role of the Designer at Lovable

The world of product design is shifting, and at Lovable, we embrace this evolution. Our design team, like many in the tech industry today, faces a significantly higher cognitive load due to the breadth of responsibilities. For instance, I'm currently responsible for the entire "connectors" experience (integrations with tools like Gmail or WhatsApp) and also oversee our iOS, Android, and desktop applications. The ability to comfortably switch between contexts rapidly is crucial.

Automation plays a key role in managing this pace. AI tools are incredibly practical for automating routine tasks, allowing us to focus our efforts on areas that bring higher value in terms of user experience and design.

What We Look for in a Product Designer

Our core expectation at Lovable is that "everyone ships code," or at the very least, is deeply comfortable with the codebase. This doesn't mean every designer is building complex features from scratch, but rather that they understand and can directly interact with the code. For example, many content designers on our team will ship code for simple text changes.

Beyond technical comfort, we highly value a designer's "sensitivity in taste and craft." In an era where AI can generate a functional UI, the differentiator lies in intentional design and a deep understanding of the user. It's about crafting experiences that go beyond merely "correct" interfaces.

Shipping Code as a Designer: My Workflow

At Lovable, we communicate extensively through Pull Requests (PRs), even as designers. This direct engagement with the codebase ensures alignment and speed.

For minor adjustments or "paper cuts," I often ship the code myself. For larger changes, I'll typically request a review from an engineer, sometimes from our internal design system team. It's important to note that our "design system" is primarily code-based, not maintained in Figma, because code evolves so quickly that Figma components would rapidly become outdated. The codebase is our true source of truth.

For more complex features, I create large "draft PRs" (sometimes 700 lines of code or more) to communicate my design ideas. I'm not expected to be a senior engineer, so these drafts serve as a starting point. An engineer will then take over, refining the code and handling more complex backend aspects, while I typically focus on the front-end and animation.

My intervention point in feature development can vary. Product Managers often present initial prototypes, and we even create prototypes directly within Lovable's local development environment. My goal is never to be a blocker. If a developer ships a feature that needs styling or minor adjustments, I'm happy to follow up with my own PR to polish it. This level of collaboration is built on trust, which we foster by encouraging team members to create "how to work with me" guides or manuals.

A Concrete Example: Iterating on Connectors

Let me walk you through a recent example involving our connectors experience.

The Problem

Initially, our connectors were hidden deep within the application settings, leading to low user engagement. We wanted to improve discoverability and add a promotional banner, similar to what we did for our new "skills" feature.

My Iteration Process

1. Problem Definition and Data Review: I start by clearly defining the problem and reviewing relevant usage data to understand current behaviors.

2. Rapid Prototyping in Lovable: I use Lovable's desktop application with a local development environment (MCP) to quickly create design variants. This allows for rapid ideation directly in the product's context, without getting bogged down in pixel perfection at this early stage. The goal is to explore concepts that align with the brand.

3. Leveraging Paper Snapshot: For visual exploration and modification of existing components, I use a Chrome extension called Paper Snapshot. This tool allows me to grab live components from the DOM (Document Object Model) and paste them directly into Paper. The copied elements are vectorized and production-aligned, saving me a lot of time compared to finding or recreating them in Figma.

4. AI-Assisted Coding with Cursor: Once I have a strong visual direction, I switch to Cursor (an AI-powered coding tool). I use simple prompts to generate or modify code for specific components, always ensuring the output is clean and considers technical aspects like feature flags.

   OK, j'ai envie de bosser sur le composant en haut du composer. Ce que je fais toujours avant, c'est que j'essaie de comprendre exactement comment ça fonctionne côté code histoire d'avoir un truc qui est clean.
   

   (Okay, I want to work on the component at the top of the composer. What I always do before is try to understand exactly how it works on the code side, to have something clean.)

5. Focus on Animation: For the promotional banner, I meticulously defined an animation sequence for logos. I aimed for a dynamic feel, with an initial static phase of 250 milliseconds followed by an accelerated phase to display 15-20 logos per second.

   

6. Deployment and Measurement: The finished feature is deployed with feature flags, allowing for internal testing before a broader rollout. Measuring data on views and engagement is essential to validate our design choices.

Understanding the Backend with AI

A critical part of my design process, especially for complex features like connectors, involves understanding the underlying backend architecture. I leverage Cursor to ask questions about how data is structured, how different plans (admin vs. regular user) impact functionality, or how API connectors are managed. This helps me simplify complex technical concepts for our non-technical user base.

The Recruitment Day Challenge: Redesigning Branching

My recruitment day at Lovable involved an 8-hour design challenge: redesigning the concept of "branching" for a live version of an app. This is a complex topic, especially for non-technical users who might struggle with concepts like database conflicts or version control.

My Approach to the Challenge

1. Starting with Text: I always begin by outlining the problem in text, trying to simplify it and understand the core complexities. I researched how other tools like Figma (multiplayer, FJAM) and even non-tech examples (Apple's list management, Mario Kart's split screen, shopping lists, calendars) handle versioning or parallel workflows. My goal was to avoid the overly technical language of Git or VS Code.

2. Exploration over Bias: For the first hour or two, I deliberately avoided looking at Lovable's existing interface to prevent bias. I focused on identifying natural entry points for creating a new version.

3. Concept Development: I explored various UI patterns – tabs, sidebars, dropdowns – but identified their potential pitfalls (e.g., users missing a dropdown and making changes on the wrong branch).

4. Final Concept: "New Session": My ultimate concept aimed for a "mental model" that was creative and non-intimidating, drawing inspiration from chat applications like Slack threads. Instead of "branching," I proposed "New Session" – a more user-friendly term. I also considered small branding touches to align with Lovable's identity.

   Within a session, users could "push to main," though I acknowledged that "main" itself is still a technical term that might need further simplification.

The Recruitment Day Process

The test day included a checkpoint at midday with the Head of Design and another designer. This was invaluable for ensuring I was heading in the right direction and understanding how I would collaborate with the team. At 6 PM, I presented my concept in a 10-minute presentation, focusing on clearly explaining my decisions, rationale, and design choices.

Q&A: Collaboration and Tooling

Design-Dev-PM Collaboration

Our collaboration model is fluid, embracing the "driver not passenger" philosophy where everyone takes ownership. We operate with a lean PM team, meaning designers and developers often work autonomously to define, build, and measure features. While we do plan for the medium term, the focus is often on short-term iterations, as our users appreciate seeing continuous improvements based on their feedback.

Tooling Philosophy and Specifics

At Lovable, we have unlimited access to our own platform, which I heavily leverage for prototyping. For other AI tools like Cursor, our developers also have unlimited usage, as these tools are seen as accelerators for development.

When it comes to design tools, we choose the right tool for the job:

• Paper: I primarily use Paper for rapid iteration and restructuring existing components, often in conjunction with Paper Snapshot. It's excellent for quickly exploring visual changes on production-aligned components. However, Paper currently lacks features like reusable components or detailed token management, making it less suitable for maintaining a full design system.
• Figma: I use Figma for tasks that require a high degree of control over visual details, such as integrating with iOS UI kits for native components, working with complex gradients, or intricate vector design. Figma remains superior for comprehensive design system thinking and maintenance.
• Cloud Code/Design: Cloud Code is used across the team, while Cloud Design is less common. We're free to choose the tools that best suit our individual workflows, even traditional whiteboards.

We don't "reuse" components within Paper in a design system sense. Instead, I snapshot a component from the live codebase into Paper, make my changes, and then either share a Paper link for feedback or commit the changes directly into the PR. Tools like Paper can often infer design tokens (e.g., background in Paper might map to bg-background-accent in a framework like Radix UI), but manual review for precision is still needed.

Actionable Takeaways

• Embrace the Code: Designers who are comfortable with the codebase, even for small changes, are invaluable in fast-moving environments.
• Prioritize Craft & Intentionality: In an AI-assisted world, differentiating your design work through deep user understanding and refined aesthetics is more important than ever.
• Iterate Rapidly, Ship Often: Don't be a blocker. Use quick prototyping methods, leverage tools to iterate directly on the product, and contribute code when possible.
• Build Trusting Relationships: Clear communication and mutual understanding between designers and developers are key to a seamless workflow.
• Choose the Right Tool: Understand the strengths and weaknesses of different design and AI tools. Some are great for rapid iteration, others for detailed design systems or complex visual work.
• Understand the Backend: Using AI to grasp technical architecture can significantly inform and simplify complex design problems for non-technical users.