Yes, you can design a website in Figma. Plenty of great websites start there, and if the site doesn't exist yet, it's often exactly where you should start.
It gets less clear once the website is already running. There's a login, data coming from somewhere, and years of code deciding what happens on the page. At that point, drawing another version of the site creates a gap between what you design and what people actually use.
What Figma is good at
Figma is at its best when you're exploring. You can try three versions of a pricing page in an afternoon, build a component library, or make a prototype and put it in front of people before anyone writes code.
Handoff is much better than it used to be. Dev Mode gives developers measurements, variables can become tokens, and Code Connect can connect a component in Figma with the one in your codebase. Figma can even publish websites directly from a file.
For a new site, all of that makes sense. But if you already have a working site with its own framework, data, CSS and deployment setup, the Figma file is still a separate version of it. Someone has to turn that version back into the real thing.
Your real content isn't in the file
Mockup content is usually well behaved. The product name fits, the table has four neat rows, and the card holds exactly the amount of text you expected.
Real content isn't so polite. An eight-character product name in Figma becomes a 62-character name from the database and suddenly takes two lines. A table that looked clean with four rows has 1,100 of them for one customer.
Then there are all the states that are easy to miss while designing: an empty account, a failed payment, or a form someone only filled in halfway.
This matters even more inside logged-in products. A dashboard is shaped by its data. If you design it with made-up values, you're testing the layout against made-up problems.
A Figma frame isn't a browser
A frame is a width you picked. A browser is every width you didn't.
Auto layout helps a design resize, but it doesn't run your website. It can't tell you that the real navigation wraps at 900 pixels, or that your sticky header covers the heading after someone clicks an anchor link.
The same goes for type. Figma can show the right font, size and line height. It can't show how that type loads and renders inside your page, with your CSS and the browser's own behavior around it.
A design can look perfectly responsive in the file and still feel wrong the moment you open the real site on a phone.
Someone still has to build what you drew
When you hand over a Figma file, the developer has to read it and recreate it in code. Good tools make that easier, but the basic job is still the same: one person makes the design, then someone else turns that design into the website.
Anything the file doesn't say clearly gets interpreted. What happens between the desktop and mobile frames, which existing CSS rule should change, whether a spacing value belongs to one page or to a shared component, and how any of it holds up with content that wasn't in the mockup.
Coding agents make the building faster, but they don't remove this gap. An agent can build a feature from a paragraph and then spend the next twenty minutes moving one heading around because words are a poor way to describe an exact visual change. We wrote more about that in why describing became the expensive part.
Screenshots don't solve it either. They show the result you want, but not how the existing site should change to get there.
Pixy starts with the real page
Pixy takes a simpler approach: if the site already exists, open the site and design there.
Add the script tag, which is safe to publish in your page source, or install the Chrome extension, then press ⌘⇧E. The page you're looking at becomes editable.
It isn't a copy. It's your page, with its own CSS, server response, session and content. Select a heading and move it, resize a card, change its fill. Edit the CSS rule it already matches, or change its markup.
You can add things there too. Draw a section where the section will actually live, drop in an image, add text, or group elements together. You're making the change in the same place where you can see everything it has to work with.
Resize the page and your real breakpoints respond. You can drag through any width or jump between phone, tablet, laptop and desktop sizes. A change made for the phone layout stays attached to that viewport instead of becoming a vague note for someone to figure out later.
Because you're working on the real page, other people can join you there too. They can see cursors and selections, talk through chat or camera, and leave a comment on the element they're actually talking about.
The handoff is the change itself
When you're done, your developer or agent doesn't have to study a picture and work out what you meant. Pixy has a structured record of what changed, where it changed, and at which viewport. The experiments you undo never reach it, only the changes you keep.
Your codebase still stays the source of truth. Pixy isn't replacing the project with another copy of it. It hands whoever builds the change a precise description of what to change inside the project you already have.
The agent handshake is a single call, so an agent can pick up those changes directly instead of trying to reconstruct them from a prompt or screenshot.
Figma still has a job
None of this makes Figma the wrong tool. If you're working on a brand, an icon set, an early concept, or a website that doesn't exist yet, a blank canvas is useful.
Pixy needs a page that can render. An empty route on localhost is enough, but there has to be a page.
Once that page exists, you have another option. Instead of drawing a second copy of the site and asking someone to rebuild it, you can make the design where it will actually live. The content, the breakpoints and the browser are the real ones from the first move.
So yes, design a website in Figma when you need to design a website that isn't there yet. When the website already exists, open it.
The page already exists. Design that one.
Try designing directly on this page, with the real content and browser in place.