Screenshot inspiration vs live components for UI design

When you look for UI ideas, you usually end up in one of two places. One is a gallery of screenshots from real apps and sites, often organised by screen type or flow. The other is a library of live components: buttons, cards, menus, transitions and effects that run in the page in front of you.

Both are useful, and they answer different questions. This page compares the approaches, not particular products, with an eye on what happens when an AI coding agent has to turn the idea into code.

The short version#

What screenshot galleries are good at#

Screenshots show design in context. You see how a real team laid out onboarding, how dense their settings page is, what their empty states say and how a checkout flows from one step to the next. That's the information you need early on, when the question is "how do products like mine usually handle this?" rather than "which button should I use?".

They also show real content. A layout that looks great with placeholder text can fall apart with long names, prices and error messages, and a screenshot of a shipped product has already met those problems. For research into flows, information architecture and category conventions, a good screenshot gallery is hard to beat.

Where screenshots stop#

• No motion. A still image can't show how a menu opens, how one page hands over to the next or how a button answers a press. Recordings help, but you still have to work out the timing by eye.
• No values. Colours, spacing, radii and type sizes are estimates. Two people, or two agent sessions, will estimate them differently.
• Missing states. You see one moment. Focus rings, disabled buttons, loading and error states are usually out of shot.
• No code. Everything has to be rebuilt. When you paste a screenshot into an agent, it rebuilds a lookalike, and the next screen starts from a fresh guess. Alternatives to pasting design screenshots covers that problem in detail.

What live components are good at#

A live component answers the questions a screenshot can't. You see the spring when a card lifts, how a modal enters and leaves, and how a toast arrives. In the Wuizard app you can open a component and use it, and for many components tune their settings live while the code follows your changes. You can also preview the library in one of your sheets' tokens, so you judge components as they'd look in your product rather than in a demo theme.

Most importantly for AI-built apps, the thing you chose is the thing that gets built. Put a component in a slot of your sheet and your agent fetches that exact source with get_slot, with your values filled in, instead of approximating it from a picture. The micro-interactions and page transitions topics are good places to see the difference motion makes.

Where live components stop#

• One component isn't a product. A library shows parts. How they fit together into flows, and what your screens actually say, is still your work.
• Less real-world context. Components are shown with neutral sample content, not under the pressure of a real product's data.
• Narrower breadth. A component library covers what's in it. The web as a whole, as seen through screenshot galleries, covers far more.
• React first. Wuizard's components are React, Tailwind and Motion. translate_asset returns Vue, Svelte, SwiftUI or vanilla JS versions, but translations beyond the ones that already exist count against your plan.

Use both, at different stages#

These approaches fit together better than they compete:

1. Research with screenshots. Look at how products in your category structure the flows you're about to build.
2. Decide with live components. Choose the actual button, card, modal transition and toast, seeing them move in your own colours.
3. Build from the decision. Put the choices in a sheet, so your agent fetches them instead of guessing.

If a particular site is the inspiration, you can skip a step: paste its URL into Extract and it reads the colours, type, radii and motion into a starting sheet. It copies values, never code, and the result is a starting point to make your own.

How to decide#

• You're working out a flow or a layout. Use screenshots. They show context that components can't.
• You're choosing how things look and move. Use live components. Motion and states are the details a picture leaves out.
• An agent is writing the code. Give it something exact. A picture gets you a lookalike; a component in a sheet gets you that component. The MCP setup guide shows how to connect your agent.