The cursor blinks. The input is empty. And they have absolutely no idea what to type.

That’s not a user problem. That’s a design problem.

We’ve been so focused on the quality of what AI can do that we’ve underinvested in the interface layer around it; the part that shapes what users ask, when they ask it, and how they interpret the result.

Chat is a starting point, not an endpoint.

Here are six patterns we’re seeing — and building — that go beyond the box.

1. Empty states that actually know where you are

The first mistake is treating the empty state as a blank canvas with a few example prompts. Generic suggestions don’t help. Context-aware ones do.

For example, at Factorial, when a user lands in the Engagement section, we don’t show generic AI options; we show suggestions directly relevant to engagement: survey templates, sentiment checks, and team pulse questions. The interface reads where you are and shapes what you might want to do there.

In other cases, like policies, we removed the chat box and replaced it with a file upload, as those policies are mostly stored in documents; it doesn’t make sense to push the user to copy and paste their text instead of uploading the document directly.

Dia does something similar: their entire empty state, the layout, the suggestions, and the interaction model adapt based on the active tab. Open Gmail, and it becomes an email assistant. The interface doesn’t wait for you to figure out what it can do. It tells you.

The interface should shape the prompt, not just receive it.

2. Guiding users before they type

Another failure mode: letting users write a bad prompt and then returning a mediocre result.

The model gets blamed. The user gets frustrated. Nothing improves.

Metaview tackled this directly. Before you even start, they show you what a good prompt needs to include — specific fields, structured information, context requirements. It’s almost a checklist. You can’t really proceed without feeling like you’ve given the system what it needs.

At Factorial, we went a step further by building template prompts, pre-filled structures that guide the user into asking the right question in the right format. It sounds small. In practice, it cuts the back-and-forth dramatically.

Try this yourself: look at your most common AI feature and ask: what does a bad prompt look like? Design to prevent that, not just handle it.

3. Autocomplete that connects to real entities

Text autocomplete isn’t new. But there’s a version of it that’s genuinely different: suggestions that resolve directly to system entities.

Instead of just completing a word, the interface connects your input to a real employee, a real project, a real contract, eliminating misspellings, ambiguity, and the need to remember exact names.

Tools like AI Autocomplete have pushed this pattern broadly.

4. Clarification that doesn’t feel like an interrogation

One of the patterns spreading fast, especially in Claude, is follow-up clarification after a prompt. The model asks what it needs before proceeding instead of guessing.

The older version of this in ChatGPT was a wall of text asking generic follow-up questions. The better version is what we’re seeing now: targeted, specific UI interactions that ask exactly one thing at the exact point of uncertainty.

Metaview shows this well, too. After you submit a prompt, contextual suggestions appear that map directly to what the model needs. Clarification becomes a UI element, not a conversation thread.

5. CRUD isn’t dead, it’s just getting a chat layer

Not everyone is ready to create a record through a conversation. That’s real, and it’s okay. Some users need the familiar structure of a form to feel confident in what they’ve submitted.

Octolane AI found the middle ground: you create a deal through a chat-style input, but the result populates a structured form view.

The AI does the extraction and mapping. The user gets to verify in a format they trust.

6. Inline editing changes the whole feedback loop

The frustration of iterating on AI output isn’t just about quality; it’s about the interaction model.

Going back to the chat, rewriting your prompt, waiting for a new response, reading through the whole thing again... it breaks the flow.

Lovable introduced something that changed how I think about this: not just a chat, but direct in-context editing of generated components.

ChatGPT has moved in this direction too, with inline annotation tools. The result is a tighter loop between intention and output, and it feels fundamentally more like design and less like prompting.

Where are we heading?

The chat box won’t disappear, but I think we’ll look back at this era the way we look at early mobile apps that were just desktop websites made smaller. Technically functional, but missing the point of the medium.

These six patterns aren’t separate ideas. They’re all answers to the same question: how do you close the gap between what a model can do and what a user can ask for?

The chat box opened the door. What we build around it is what determines whether users walk through.

They’re usually described as a way to move from a set of inputs to an outcome: trigger something, evaluate conditions, execute actions.

With AI, workflows are having a comeback moment. They reduce hallucinations by constraining models into deterministic paths.

But this post isn’t about AI workflows. I’ll leave that for another time.

Because the truth is this: workflows have existed for decades, and we still struggle to design them well.

The classic workflow abstraction

From a system point of view, workflows are built from three blocks:

• Triggers: the event that starts the workflow

• Conditions: rules that split logic into different paths

• Actions: what happens as a result

This abstraction has spread everywhere: CRMs like HubSpot or Attio, automation tools like n8n or Retool, and internal platforms like Intercom.

And for good reason.

Workflows are flexible, powerful, and let users customize software without engineering help. You expose a few building blocks and let users assemble what they need.

So why do they feel so painful in practice?

The hidden cost of workflows

After working with workflows across multiple products, the downsides repeat themselves.

1. Maintenance debt: As platforms evolve, workflows silently break. Only the creator knows why something exists or what it depends on.

   

2. Conflicts: Multiple workflows can react to the same trigger and undo each other’s actions. Powerful, but dangerous.

3. Learning and sharing: Once you have dozens of workflows, understanding the system becomes nearly impossible without heavy documentation.

   

4. Experience: Large diagrams don’t scale. Navigation becomes harder than reasoning about logic.

Despite this, if you look for references, the main experience is more or less the same.

Our first workflow system at Factorial (2020)

At Factorial, we shipped our first workflow system in 2020.

The goal was simple: allow companies to customize the platform, starting with notifications.

If we could nail this, we believed we could later extend it to any company process.

The flow was standard:

1. Choose a trigger

   

2. Set conditions

   

3. Select a notification

We validated the idea with a Figma prototype.

The prototype showed a very straightforward scenario:

Create a notification for a recruiter when a new candidate enters the ATS.

The validation felt smooth, and users completed the task. We moved forward.

We were excited, and so were our investors. There was a strong belief that if this system worked for notifications, it could become the foundation for the entire HR platform.

We shipped.

And almost immediately, we realized we had failed.

Where the mental model broke

HR users knew exactly what they wanted:

I want to notify Legal when a contract is signed.

But the system forced them to think like this:

1. Trigger: document signed

2. Condition: document is a contract

3. Action: notify Legal

Their mental model was the inverse:

1. Send notification

2. to Legal

3. when a contract is signed

Same logic. Completely different experience.

What looked obvious in a guided prototype became confusing in a real, unprotected environment.

The feature worked, but only with training and onboarding.

We shipped the system in 2020, and we stopped developing it shortly after.

Five years later: procurement

In 2025, workflows resurfaced when we started building our Procurement product.

Procurement defines how companies structure their purchase processes.

When the word “workflows” appeared again, I was concerned. Our 2020 experience was still very present.

But after discovery work, we reached a different conclusion: the traditional diagram-based system was the industry standard in Finance. Big players were already using this approach.

This time, we validated differently.

Instead of a narrow task, we built a fully clickable prototype where users could recreate one of their real purchase processes.

No scripts. No happy paths. Just their reality.

Surprisingly, users had very few problems navigating the interface and building their flows.

That’s when the insight landed: Finance users have a different mental model.

They are used to thinking in processes, steps, and diagrams. Many finance tools already expose similar visualizations.

Same abstraction. Different audience. Completely different outcome.

Designing the procurement workflows with restraint

Even knowing diagrams worked better here, we avoided building a fully generic system.

We simplified aggressively in two ways:

1. Trigger and first step as defaults: When creating a workflow, users start by selecting the purchase category. The first step is always configuring a form, a predefined template with mandatory data.

   

2. Linear vs. parallel tasks: Instead of branching diagrams endlessly, parallel tasks live inside a single step.

The system stayed powerful without turning into a visual maze.

Onboarding: the same abstraction fails again

A few months later, we started a new product: employee onboarding.

We had already invested heavily in procurement, so we reused the same workflow engine and interface.

History repeated itself: HR users struggled again and the experience didn’t scale.

The same issues surfaced:

• Hard to understand what’s happening

• Hard to manage conflicts

• Massive horizontal and vertical scrolling

The abstraction was solid. The experience wasn’t.

Changing the model, not the engine

This time, we didn’t touch the technical foundation.

We changed the mental model.

1. The trigger was hidden; it never changed

2. Date conditions were embedded into navigation

3. Users built actions as a simple timeline

But what about conditions?

Conditions didn’t behave like in Procurement. Most onboarding flows are identical, with small variations depending on the employee’s location, role, or contract type, but the main structure stays the same.

So instead of letting conditions split the workflow, we embedded them inside tasks.

A task could say:

• Execute only if role = Engineer

• Skip if workplace = Remote

• Change owner if contract = Freelancer

The workflow stayed linear, and the variability became local.

For HR users, it became a no-brainer.

Builder ≠ runtime

One last lesson.

The interface for building workflows should not be the same as the interface for following them.

Admins need structure.

Employees and requesters need clarity.

We separated the two experiences:

• Kanban-style overviews for owners

• Simple task timelines for participants

No triggers. No conditions. Just what’s next.

Conclusions

After five years, three products, and a few expensive mistakes, these principles held:

1. Abstractions are never neutral: Triggers, conditions, and actions encode a way of thinking. When it doesn’t match your users’, friction is inevitable.

2. Mental models beat industry standards: Diagrams worked for Finance and failed for HR. Copying the market is easy. Designing for how people think is harder and far more effective.

3. Localize complexity: If variation is local, keep it local. Global branching is often a design smell.

4. One engine doesn’t mean one interface

   Reuse foundations, not experiences.

5. Restraint is a design skill

   Power doesn’t come from exposing everything. It comes from hiding the right things.

Workflows won’t disappear, and we should stop pretending that one abstraction fits everyone.

No growth hacks, no shortcuts.

Just a cross-functional team working with extreme clarity, with design acting not as the last step, but as the engine that aligned problems, systems, teams, and decisions.

Context about Factorial

At Factorial, we build tools that help companies run their day-to-day business across people, cash, and compliance.

Each new product is built by a dedicated team of engineers, designers, and product managers.

We invest around €0.5M per team, expecting that investment to double within a year.

Ambitious, yes, but repeatable.

And one reason it works is that design isn’t waiting for tickets. Designers shape the problem from day zero: discovering root causes, framing systems, envisioning solutions, and helping the whole team decide what matters.

Our last accomplishment: from 0 to 1 in 90 days

Employee compensation (Payroll) is one of the most painful processes for any company, and one we’d been trying to solve for years. But after multiple iterations built on top of an aging, complex system, we reached a point where progress meant starting over.

So last year, we rebooted the product completely.

Less than nine months later, the new version not only launched, but it also became the fastest-growing product in Factorial’s history.

Looking back, a few core practices made that outcome possible.

Here are the 7 keys that helped us build a product from 0 to 1M€ in just 90 days:

1. Looking beyond the obvious pains from different perspectives

Every problem has a champion: the person who feels the pain first-hand and would gladly pay to reduce errors and save time.

For employee compensation, the champion was the HR admin.

But problems rarely come from a single source.

For years, while trying to solve payroll, we assumed the main issue was the calculation process. Most visible errors came from there, so we tried to fix that.

Once we started asking better questions and talking with other stakeholders, we realized calculation was just a symptom.

Here, design played a key role: instead of stopping at the obvious pain point, we used user research and stakeholder mapping to expand the picture. We spoke not only with HR admins, but also:

1. Managers: who in many companies calculate extra hours, bonuses, and variables manually. We discovered chaos and inconsistency in how they tracked compensation.

2. External sources: like expenses, benefits, and payroll calculation tools.

3. Bookkeepers: responsible for calculations, working with very manual, error-prone processes.

4. Finance teams: who manage payments and forecasts, and often detect errors caused by all the previous steps.

5. Employees: who mostly don’t understand their payslip, and report “errors” that are actually tax nuances.

In this discovery work, ensure you:

• Frame the right questions

• Connect perspectives

• Go from symptoms to root causes

• Turn messy stories into a clear problem space

2. Shadowing customers like it was our first day on the job

Forget research playbooks that say a script is the most important thing.

Scripts are useful, but they also limit your ability to react. It’s easy to bias a script around your assumptions and miss what’s really happening.

I always give my designers the same prompt:

Go to the interview as if this is your job, and the person in front of you is doing a hand-off of their work. If you don’t understand it well enough to do it tomorrow, you’re out.

This mindset shift brings you from generic, high-level questions to end-to-end understanding.

In payroll, this helped us see:

• How complex it was for some companies to track and calculate compensation across multiple tools

• How HR admins had no way to know if managers’ calculations were correct

• How painful communication with bookkeepers was, including email chains of 50+ messages for a single month

• How disconnected HR and Finance teams often are.

So, your next customer interview, instead of investing hours in a rigid script, ask users to:

• Walk you through their entire process

• Share their spreadsheets (yes, everyone has a spreadsheet)

• Show real examples

• Expose the tools, hacks, and workarounds they use

3. Mapping the entire problem before anything else

The most human (and very designer) reaction is:

I see the problem, let’s design the solution.

Stop.

One of the biggest mistakes we made in the past 7 years was treating each pain point in isolation and designing local fixes. That’s how you end up with patches, not products.

This time, we mapped the entire system:

• from managers tracking extra hours and variables

• to HR consolidating information

• to bookkeepers calculating payroll

• to finance managing costs and payments

• to employees reacting to their payslips

With this map in mind, you stop designing features and start designing systems.

We often think “system” = design system.

But think about your home: electricity isn’t just a solution for your bathroom. It’s a connected system that powers the entire house.

Compensation works the same way inside a company, and so do most problems.

4. Exploring the end-to-end solution before defining the MVP

This is where designers have superpowers.

Our value is in connecting the dots to envision a simplified, end-to-end solution that actually solves the root problems.

Before jumping into an MVP, we forced ourselves to answer:

If we had all the time and resources, how would we solve this end-to-end?

We started with diagrams: identifying the different pieces we’d need to assemble to solve the real system, not just one screen or one step.

In each iteration, we tried to:

1. Simplify the system, keeping fewer, more powerful pieces.

2. Ensure we were still solving the root problems, not just trimming complexity for the sake of elegance.

Design led this work, but it was a cross-functional exercise: PMs, engineers, and other stakeholders stress-tested the model. The diagrams showed that many pains were more connected than we thought, and that a single piece could remove friction for several users at once.

5. Visualizing the future early to align the team

Diagrams are great for reasoning, but people need to see the product.

We started creating Lovables to turn those diagrams into something more tangible: not final designs, but clear, visual stories of the future product.

This helped:

• Align the team around a shared vision

• Make it easier for non-designers to contribute

• Trigger more concrete feedback and ideas from PMs and engineers

Once everyone could see potential interfaces, the conversation changed. Everyone can react to a UI.

Diagramming systems may be for a subset of the team; visualizing workflows through interfaces is for everyone.

When we had enough clarity, we moved from Lovables to more realistic flows in Figma.

Lovable wasn’t as powerful back then as it is today, but using it pushed us to imagine the solution inside Factorial, integrated with our existing products and flows.

6. Shaping an MVP that solved something real

I’m old-school: MVP still means Minimum Valuable Product to me.

That means:

• A well-crafted experience

• Limited functionality

• Solving a meaningful problem

• Ready to sell

Over the years, MVP has been downgraded to ship something shitty and random.

Also, when shaping our first MVP, we avoided a few traps:

1. Foundations-only MVPs: Foundations are important, but they don’t solve a problem by themselves. An MVP has to solve something concrete from day one. Design helped keep us honest: if a customer can’t feel the value, it’s not an MVP.

2. Only solving the biggest visible problem: Solving just the biggest problem isn’t enough when the experience is end-to-end. Instead, we chose to cover a thin slice across the whole journey: not perfect anywhere, but significantly better overall.

3. Designing for everyone (Global ICP): It’s almost impossible to design a good MVP for everyone on day one. We narrowed our ICP to companies where we could create value quickly.

For compensation, our MVP focused on Spanish and German companies with around 100 employees.

The solution covered a bit of each pain along the journey: managers’ data, bookkeeper communication, error tracking, and tools connectivity.

Design’s role here was to prioritize flows, not features.

7. Start selling before we’re done building

The only real validation is simple:

Are people willing to pay?

We started selling our Lovables and first vision before having the product.

We didn’t ask “Do you like it?” or “What do you think?”

Instead, we:

• Placed customers in real scenarios from their own company

• Walked through their actual process

• Measured if we could save time, reduce errors, and cut costs

The answer was clear: some customers were ready to buy even before the product existed.

Here’s what worked for us:

1. Don’t wait for a finished product to sell. Sell the vision and the path there.

2. Avoid vanity metrics early on. NPS, CSAT, or usage patterns come later. Early on, focus on: time saved, errors reduced, money saved.

3. Use realistic prototypes. Lovable, Figma, or any AI tool, but make it feel real enough for users to imagine using it tomorrow.

4. Ask about outcomes, not opinions. Skip “What do you think?” and ask:

   • How much time would this save you?

   • How many errors would this avoid?

   • What would this mean in cost?

Design here becomes a sales asset: good prototypes and clear flows make it easier for sales and product teams to have serious, outcome-driven conversations.

Conclusion

Taking a product from 0 to €1M in a few months is not about luck.

It’s about:

• identifying the right problems, not just the symptoms

• understanding the full system around those problems

• envisioning an end-to-end solution

• shaping a focused, sellable MVP

• and validating value with real customers as early as possible

Of course, there are other key factors at play, like market size, how painful the problem is, or how many competitors you’re up against.

However, in all of this, design is not decoration; design is how we:

• discover the real work users do

• turn chaos into clear maps

• imagine better systems

• make them tangible through prototypes

• and help the whole team pull in the same direction.

Without design, problems stay as symptoms, and solutions stay as features.

With design, a cross-functional team has a shared language to build products that actually move the needle.

If you look at your current product, where would letting design lead earlier have made the biggest difference in going from 0 to 1?

This is a follow-up from my last post about why you should Stop designing like 5 years ago. If you haven’t read it, I recommend it (it’s a 5-minute read).

When designers start using AI tools, they expect them to behave like senior product thinkers: drop in a random prompt, get a perfect feature.

When we introduced Lovable at Factorial, that illusion vanished quickly.

We weren’t getting bad results because Lovable was bad.

We were getting bad results because we hadn’t given it the clarity it needed.

AI doesn’t solve unknown problems. It solves the described problems.

Once we accepted that, everything changed.

Why do designers struggle on day 1

AI tools are not Figma.

As designers, we need to adapt and change our mindset.

When you start using an AI tool, you should have these things clear in your mind:

• It can’t define the problem for you. If you don’t clarify what you’re trying to solve, the tool will guess… and guess poorly.

• Vague instructions break everything. “Make this intuitive” or “fit all of this on one screen” is not direction: it’s confusion.

• It’s not a Figma replacement. Some tasks (polish, visual nuance, interaction details, error statuses) are still better done manually.

• It won’t reproduce your product perfectly. But “close enough” is usually more than enough for testing. Users don’t see the tiny inconsistencies designers obsess over.

• It depends on a structured context. Without clear goals, sections, flows, and vocabulary, outputs feel generic, fake, or irrelevant.

After a few workshops and some proper guidelines, we stopped asking Lovable to think for us at Factorial… and started using it for what it’s great at: quick prototyping, rapid validation, and fast iteration.

📌 Note
This guide is written with Lovable in mind, but 90% of it applies to any tool: v0, Lovable, Figma Make, Bolt, Magicpath, Base44, Galileo, etc. I might talk about the differences between them in the future.

How to structure your first prompt

Before you write a single screen, you need two things:

• The problem you’re solving, clearly framed

• How do you expect to solve it, clearly described

I break it down into three layers: foundations → sections → flows.

1. Foundations: give the model a skeleton

If your foundations are vague, everything that follows becomes harder. Focus on:

1. Context: What is your company, product, and problem? Explain it simply.

2. Style: How should the app feel? Tone, identity, interaction patterns.

3. Layout: What’s the global structure? Navigation, menu, main areas.

Think of this as giving the tool the skeleton before asking it to build the body.

Example of the Foundations prompt we use at Factorial

2. Sections

Once the foundations are in place, define your sections (pages, tabs, or side panels):

1. Context: What is the section for? What can users do?

2. Structure: Layout elements like navigation, filters, tables, and cards.

3. Components: Any specific details, e.g., a delete button with a bin icon.

Example of section prompt for an HR dasboard

3. Flows

Then, define how users move and act:

• Context: What’s this action for, and where does it start?

• Structure: Modal, page, or step flow?

• Behavior: Steps, data, conditions, error states.

• Components: Which UI pieces are involved?

Do this for the 1–3 most important flows first. Don’t start with edge cases.

Example of a task revision flow.

Other tips

• Structure your ideas and flows before prompting: Lack of prep = wasted time.

• Use the vocabulary of design systems: Agents understand tokens, components, and even descriptive adjectives.

• Avoid too much granularity in early prompts: Start broad (layout, flows, main sections). Add details like spacing, font sizes, and pixel-perfect specs only once the basics are working.

• Write prompts yourself: Don’t rely on other agents to generate them. Once drafted, refine directly in ChatGPT; specialized agents often perform worse.

• Avoid long text blocks: Use bullet points, one requirement per line.

• Name everything: Label sections, flows, and components to make reuse easier. If something isn’t named, use the selection tool to query it.

• Write and prototype at the same time: LLMs can take some time to generate, so don’t wait until you’ve written everything. Start with sections and launch a prototype. While it’s building, keep writing flows and other sections.

Setting the tool

Before you paste your prompt, most AI tools let you set up instructions and memory to keep the model grounded and consistent.

In Lovable, you can configure all of this directly in your project settings, including your product context, your design tokens, and the rules for how you expect the LLM to behave.

This is where you teach the model your world:

• Company context

• Your tokens

• How do you expect the LLM to behave

If you need to export tokens from Figma, the Figma Token Exporter plugin makes it straightforward.

The more you preload here, the less you’ll have to repeat later, and the more reliable your prototypes become.

Basic instructions for the LLM
- Always prefer composing or configuring existing components over creating new ones.
- Search the existing component library before coding anything new.
- Only build new components if 1) There is no matching or adaptable component 2) Reuse would significantly reduce clarity or violate design or
- Suggest which existing component(s) to reuse whenever applicable.
- Use the correct props, slots, and structure.
- Do not extend components in a way that breaks encapsulation or styling consistency.
- If a request cannot be fulfilled without:
    - Violating design token usage
    - Rebuilding an existing component
    - Breaking component API
  Then:
    - Politely explain the issue.
    - Suggest either an existing alternative or a necessary update to the design system.

How to prototype without going insane?

Once your prompt and project are ready, don’t paste your entire brain into Lovable and hope for the best.

Work in small, controlled steps:

1. Add the first section

2. Fix anything broken or unexpected

3. Refine and polish

4. Add the next section or flow

5. Repeat until the project is complete

Tips for prototyping

• A good prompt is 90% of the work: If the first 2–3 iterations are poor when prototyping, stop patching, rewrite the prompt.

• Use LLM chat for longer prompts and to see how things are built: It’s also useful for brainstorming UI/UX ideas, testing different prompt structures, and asking about how certain things work to improve fixes and iterations.

  

• Be vocal about the tech stack. Define frameworks, technologies, and libraries. Knowing code helps you out.

• Export Figma components: You can use dev-mode to export Figma code by selecting a layer, going to Layer properties on the right sidebar, switching List for Code, and selecting the plugin Figma to Code from Builder.io. Copy the code there and paste it into Lovable; it helps.

  

• Be detailed when the time is right: Specify flows, positioning, states, and styles later in the process.

• Accompany explanations with visuals: A quick Figma sketch is often 10x clearer than text.

• Use version history: Roll back and re-prompt instead of endlessly fixing broken outputs.

  

• Render prototypes in device mockups: Ask Lovable to place designs in mobile or laptop frames for more realistic testing.

• Data architecture: When using a data structure across multiple pages with filters, groupings, or variations, define the structure upfront and give the LLM a data frame to work from. For more robust needs, consider pairing the prototype with a real database such as Supabase.

  

• The edit tool is your friend. Use it to add specific details to a component, or to ask its name and how it was built so you can reuse it elsewhere in your prototype.

  

Getting Stuck?

If AI isn’t giving you the results you want, don’t prompt with things like: “it doesn’t work,” “review again,” “make it better,” or “fix it.”

• Use Chat mode. Explain the issue in depth, and ask lovable to review all files until it finds a fix that will 100% work.

• Try to understand the implementation. At times, just by understanding how things are built, you can provide better pointers on how to fix the problem. You can use the chat mode for this, too.

• Threaten it. I’m not joking. It really works. If you threaten AI, it responds much better. To be a little bit ethical, what I usually say is “If you do not fix this, a kitten will be hurt… 🐱”

What happened after 3 months of fully adopting AI prototyping at Factorial?

The short version: our ideation and validation loop went 10x faster.

We can now generate a prototype in a single day and update full flows in just a few minutes.

Instead of spending hours debating ideas on whiteboards or buried in presentations, we can jump straight into realistic, testable prototypes that feel close enough to the product that users behave naturally.

And the difference in research is huge.

Instead of running Figma click-throughs that politely guide users from screen to screen (even when they make mistakes), we can now test end-to-end flows. We can see people get stuck, recover, try alternative paths, and behave the way they would in the real product. It lets us test actual customer scenarios, not scripted paths.

But it’s not all upside.

Lovable is powerful enough to build almost anything, including ideas that are vague, unstructured, or not fully thought through. That’s the trap. It will happily generate an interface even if your problem framing is weak.

So the speed is real, but the responsibility is too:

We still need clarity on the problem, the solution, and the experience we want to create.

AI accelerates the direction you point it, which means pointing it well matters more than ever.

Closing Thought

Lovable didn’t transform our workflow because it’s magical. It transformed our workflow because we stopped treating it like magic.

Good inputs create great outputs.

The tool just accelerates the direction you’re already pointing.

If you want speed, clarity comes first.

Here you have some other guidelines to help you in your process:

• Lovable prompting guide

• Prompt directory: basic flows

• Tutorial: building websites with AI

When I started in design back in 2013, I used Adobe Photoshop to design websites and Adobe Acrobat to build interactive prototypes.

We were just photoshopping screenshots.

Then came Sketch and InVision, a new era of collaboration and chaos. Every project folder had at least one final_version.sketch, which was never actually final.

Then came Figma. Everything centralized: design, feedback, handoff, collaboration. It felt like the future.

But after a decade of debating which tools to use, I’ve realized something: it was never really about the tools.

The illusion of faster tools

Every new design tool promised speed and efficiency. For a while, that was true. But if you look at today’s teams moving the fastest, they’re not the ones following the traditional process:

1. Research

2. Ideation

3. Low-fi wireframes

4. High-fi design

5. Prototype

6. Validate

7. Repeat (until deadlines kill your optimism)

This model worked for years, but now it’s slow, rigid, and expensive.

A new workflow for AI-native designers

Today, tools like Lovable, v0, Bolt, Cursor, Base44, Figma Make, or MagicPath are reshaping how we work.

They take you from idea to working prototype in hours, even sometimes straight into production.

That forces a new kind of workflow:

1. Research: Understand the problem deeply.

2. Ideation: Shape potential solutions.

3. Prompt & Prototype: Describe your solution through prompts and let AI tools build it iteratively.

4. Validate: Test a real and interactive prototype with users and refine through new prompts.

Faster prototyping and validation

With AI tools, you no longer spend days pushing pixels or updating prototypes after every round of feedback.

You describe the new idea, or simply type the feedback, and a new version is ready in minutes.

And more importantly, the prototype evolves into a living product to test real flows, explore failure states, and rethink user paths.

No more guided prototypes where a wrong click gives you a blue box telling you where to go next.

This is where design becomes exciting again. Once the concept is validated and flows are clear, you can focus on what truly makes experiences memorable: micro-interactions, motion, and emotional resonance.

That’s the real shift, from designing screens to designing systems of behavior and emotion.

The real role of designers

Don’t panic. AI won’t replace us; it’ll replace the old way of designing.

AI can remix the past, but it can’t sense what people feel or imagine what doesn’t exist yet. That’s our job.

But if we spend all our time on operative tasks instead of exploring, validating, and crafting meaningful experiences, we’ll make ourselves irrelevant.

How are we doing it at Factorial?

A few months ago, our design team started using Lovable and Figma Make daily.

What used to take weeks now takes days, sometimes hours.

That shift has freed us to explore more ideas in parallel, validate them faster, and focus on the fine details that elevate the entire experience.

We didn’t replace Figma; we redefined its role:

• Lovable: builds early concepts in minutes, perfect for fresh ideas.

• Figma Make: creates more realistic prototypes once the direction is clear or components are ready.

• Figma: remains where we refine edge cases, error flows, and polish the system.

AI hasn’t replaced our process or our role. It’s expanded what we’re capable of.

Conclusion

The old design process was built for static tools.

This new one is built for living systems.

We’re not losing design, we’re losing the illusion that design only happens inside a canvas.

AI lets us return to what matters: solving real problems and crafting experiences that feel effortless, memorable, and deeply human.

Most designers still think “great design” means great aesthetics and usability.

But the truth? The best designers I’ve met don’t obsess on those, but on problems.

A few weeks ago, at Factorial, we ran a Product Design workshop that explored what it really means to be a great product designer today.

And it reminded me how outdated most of our mental models still are.

The old definition of “great design”

Fifteen years ago, great design just meant beautiful visuals. The designer was the creative genius who made things look good.

Then came the UX revolution. We stopped asking, “Does this look good?” and started asking, “Do users understand it? Can they use it easily?”

For a while, that was enough. UX became the holy grail. But the world moved again, faster than our vocabulary.

Today, great design isn’t about beauty or even usability. It’s about impact.

Impact doesn’t come from complexity. It comes from clarity.

The best designers aren’t the ones who can explain complex problems up to the last detail; they’re the ones who make them become simple.

Because solving a hard problem in a simple way is harder than it looks.

Simplicity is not a style. It’s a strategy. And that requires a completely different mindset.

Falling in love with the problem

Over the last five years of interviewing hundreds of designers, I’ve noticed a pattern:

The ones who make the biggest impact aren’t the most creative, technical, or experienced.

They’re the ones who see beauty in problems.

While others get frustrated by complexity, they lean in. They’re explorers, not decorators.

When you talk to them, they don’t sell themselves. They talk about customers. About friction points. About something they can’t stop thinking about.

They treat every “why” as a doorway.

Every “I don’t know” as an invitation.

This mindset, infinite curiosity, is the foundation of great product design.

1. Infinite curiosity

A great designer doesn’t live in Figma. They live in the world and they:

• Constantly ask why and how things work.

• Get more energy from discovery calls than from pixels.

• Love when users derail interviews, because that’s where the truth hides.

• Peek into engineering discussions not because they have to, but because they want to understand what’s possible.

This curiosity builds context, and context turns complexity into simplicity, the purest form of good design.

Try this yourself:

Next time you’re in a user interview, forget your script. Ask, “What’s frustrating you today?” Then follow that thread as far as it goes.

You’ll learn more in 20 minutes of real curiosity than in weeks of design reviews.

2. Ship fast, learn faster

A designer’s ego used to live in the final design. Now it should live in the feedback loop.

Great product designers don’t romanticize their ideas. They ship rough drafts, watch what happens, and adapt fast.

They know perfection is an illusion, and worse, a bottleneck.

Here’s what they do differently:

• Prioritize user reactions over personal taste.

• Release tiny experiments daily instead of perfect releases quarterly.

• Treat every version as disposable, except the learnings.

• Believe being roughly right today is better than being perfectly wrong tomorrow.

It’s a scientific mindset: design as a series of hypotheses, not masterpieces.

And it’s contagious. When one designer ships fast, the whole team learns faster.

3. Impact-Driven Design

Shipping isn’t the finish line, it’s the starting gun.

Great designers measure their success by impact, not output. They:

• Ask how each task moves a metric, not just the project forward.

• Stay involved after handoff, watching how users actually behave.

• Push teams to measure outcomes, not milestones.

• Celebrate user adoption and business impact, not launches.

Because launching something means nothing if doesn’t bring any value and no one uses it. Or worse, if no one cares.

This kind of ownership transforms how teams see design.

It shifts the question from “Is this ready to ship?” to “Is this solving something real?”

The New Definition of Great Design

If I had to summarize what makes a great product designer in 2025, it would be this:

A great product designer turns curiosity into clarity, clarity into action, and action into impact.

They bridge discovery and delivery.

They think like researchers, move like builders, and measure like founders.

And they remind everyone around them that design is not an important department, it’s a way of thinking through problems.

Closing Thought

The future of design doesn’t belong to those who make things look great.

It belongs to those who make things work great, for real people, in the real world.

And that starts with one question you should never stop asking:

Why?