Design the states you can't mock up

Some parts of your product were never meant to be mock-ups.

A logged-in dashboard only looks the way it does because you're signed into a particular account. It has real projects, real numbers, permissions, notifications, and history. An open dropdown only exists because you clicked something a moment ago. A payment error might appear only after a very specific sequence of events.

These aren't unusual edge cases. They're a large part of the product people use every day:

• logged-in pages with real account data
• open menus, dropdowns, and popups
• validation and payment errors
• empty, loading, and success states
• search results and generated content
• notifications and changing counters
• screens that depend on permissions or account type

You can recreate all of them in a design file. But the moment you do, you're no longer designing the state itself. You're designing a copy of it.

The copy is never quite the same

The usual workflow starts innocently enough. Open the product, get to the state you need, take a screenshot, then rebuild enough of it in a design tool to start working.

While rebuilding, small things change. A long project name becomes a shorter placeholder because it's easier to work with. A dropdown gets six neat items instead of the 40 it has in a real account. The error message fits perfectly because you typed it yourself. A modal floats over a clean background instead of the page someone had scrolled halfway down.

None of these changes looks serious on its own. But together they remove the messy context that often caused the design problem in the first place.

There's a practical cost too. Before you can improve anything, you have to recreate something that already exists. Then you have two versions to think about: the real product and the design file. As the product changes, the distance between them grows.

For early ideas, that separation can be useful. For a state that already exists and needs fixing, it often isn't.

Start with the real state instead

Pixy takes the opposite approach. Instead of bringing the product into a design tool, it brings design tools to the product.

Get the website into the exact state you want to work on. Log into the right account, open the menu, trigger the error, scroll to the right place. Then press ⌘⇧E.

You're still on the same page, in the same session, with the same data. Nothing needs to be recreated or moved somewhere else. Pixy simply makes what's already in front of you editable.

That matters for states that normally disappear as soon as you interact with them. In design mode:

• an open menu can stay open while you select and edit it
• animations can pause instead of moving past the moment you need
• your logged-in session stays active
• real content and server data stay on the page
• the surrounding page stays exactly where you left it

A state that normally lasts a fraction of a second can stay there for as long as you need it.

Design what's actually there

Once the state is held in place, you can work on it the way you would expect. Move an element, resize it, adjust its spacing, or rewrite the copy while seeing exactly how the real text behaves. Change typography, colors, radius, opacity, and other visual properties without leaving the page.

And because this is the website rather than an image of it, you're not limited to changing its appearance. You can work with the structure underneath it too.

• Edit CSS when the rule itself needs to change.
• Edit HTML when the structure needs to change.
• Add an element when something is missing.
• Remove something the state doesn't need.
• Change a shared rule and see every matching element update.

The difference becomes especially useful when real content starts pushing against the design. You don't need to imagine what happens when the title is too long or the menu contains 40 projects. If that's what's on the page, that's what you're designing.

Keep the state while the viewport changes

The same problem rarely exists at only one screen size. That open menu might be perfectly fine on a laptop and completely fall apart on a phone.

Instead of recreating the state again in a mobile frame, resize the page. Pixy keeps the state in front of you while the site's own CSS responds through its own breakpoints.

The content doesn't suddenly become placeholder content just because you've switched to 390 pixels. The long account name is still long. The menu still has all its items. The popup is still open over the same page.

You can move through:

• phone
• tablet
• laptop
• desktop
• any custom width in between

You're looking at the same product state at different widths, not maintaining several drawings of what you think that state should do.

The handoff knows what changed

A screenshot can show the final result, but someone still has to interpret it: which element moved, whether the gap is 16 pixels or 20, whether the new spacing is global or only for mobile, and which rule in the code produces the thing in the image.

Pixy already knows, because the changes happened on the page. As you work, it records the information your developer or AI agent needs:

• which element changed
• which property changed
• the value before
• the value after
• the viewport where you made the change

If a change needs context that can't be expressed as a value, leave a comment on the element. And if you tried several ideas before finding the one that worked, those experiments don't need to become part of the handoff. What matters is what you decided to keep.

Instead of handing over a picture and asking someone to reproduce it, you're handing over a clear description of what should change in the product.

Not everything needs to become a mock-up

Design files are great when you're exploring something that doesn't exist yet. But once a product is running, many design problems already exist in their most useful form: inside the product itself.

The dashboard with three years of account history is already there. So is the menu with too many projects, the payment error, the popup that breaks at phone width, and the empty state nobody has looked at since launch.

You shouldn't have to recreate those states before you're allowed to design them.

Get a page from your project into the state you care about, press ⌘⇧E, and work on what's actually there.

Some parts of your product were never meant to be mock-ups. With Pixy, they don't have to be.