--- lastModified: 2026-10-13 --- # Designing UI With Amp Use Amp to explore UI designs, refine a direction, and build it in your app. Start with a screenshot and describe what you want people to be able to do. Amp uses its image tool, [Painter](/docs/tools#painter), to generate mockups when you ask for UI ideas. It can also [build an interactive prototype](#try-an-interactive-prototype) that you can click through in the conversation. You can compare designs before committing to an implementation, then keep working in the same thread to turn the chosen design into code. ## Start With Your UI and a Goal Attach a screenshot of the page you want to improve, or ask Amp to run your app and take one. Explain what is difficult to use and what should stay the same. ```prompt This sidebar needs to show who's online and let teammates chat. Chat is too hard to find. Explore better layouts using this screenshot. Keep our colors and typography. Don't write code yet. ``` You can [attach images](/docs/prompting#images). If you are starting from scratch, describe the screen and its purpose instead. Add a reference image if you have a visual style in mind, and say which parts Amp should borrow. ## Compare Different Layouts Ask for alternatives that change how the UI works, rather than only its colors or spacing. Include the states you need to judge the design, such as an open menu. ```prompt Use Painter to compare three directions: people above chat, chat with an avatar row, and a compact dock that expands. Show the avatar menu open so I can see where people's active threads go. Label the alternatives A, B, and C. ``` Amp can ask Painter to put several variants in one comparison image. For larger screens, ask for separate images so you can read each design. Painter generates one image per call, so Amp makes multiple calls for separate images. Check whether each design supports the task you described. Image models can invent controls or leave out requirements; a polished image does not mean the design is complete. ## Refine a Direction Choose an image and describe what to keep and what to change. You can refer to a labeled variant in the same thread without rewriting the original request. ```prompt Take B further. Keep chat as the main view and put the online faces in one row above it. Show the same design with the avatar menu closed and open. Remove the navigation above the faces. ``` Amp passes the selected image back to Painter as a reference along with instructions for the revision. When available, it can also include your original screenshot to preserve your app's styling. Painter accepts up to three reference images per call. You can combine parts of different variants too: ```prompt Use B's layout with A's message composer. Keep B's avatar row and open-thread menu unchanged. ``` Continue with specific feedback on the result. For a precise change to the working UI, such as adjusting padding or fixing a button, ask Amp to edit the code directly instead of generating another mockup. ## Try an Interactive Prototype You do not need to change your app to try an interaction. In an [orb](/docs/orbs) thread, ask Amp to prototype the screen, and it replies with a working prototype that you can click and type into in the conversation. ```prompt Prototype option B here so I can try it. Use fake data. Let me open the avatar menu, switch between the full and compact layouts, and send a message. ``` Amp writes the prototype as one self-contained HTML page with its own CSS and JavaScript, in an `amp-view` code block in its reply. The Amp web app shows the page inline in a sandboxed frame that follows your light or dark theme. The prototype has no network access and cannot reach your app, code, or data, so it uses sample data and saves nothing. The Amp CLI does not render it. Ask for changes the same way you refine a mockup, and Amp replies with an updated prototype. Painter, prototypes, and portals each answer a different question: - **Painter** generates images. Use it to compare how several directions look. - **An interactive prototype** runs in the conversation. Use it to check how an interaction works, such as where a menu opens, before you write app code. - **A portal** shows your real app running in the orb. Use it to review the implementation with your own components and data. ## Build and Review the UI When you have a direction you like, ask Amp to implement it using your app's existing components. The generated image or prototype is a design reference, not part of your app. ```prompt Implement this sidebar using our existing components. Make the avatar menu show that person's active threads. Check keyboard navigation and the narrow layout, and run the relevant tests. ``` Review the running app as well as the screenshots. In an [orb](/docs/orbs), ask for a [portal](/docs/orbs/portals) so you can try it yourself: ```prompt Start the dev server and give me a portal link to the sidebar. Show it with enough messages to scroll and with the avatar menu open. ``` Use the portal's floating review button to select an element and send feedback to the same thread. Test interactions in the app as well. A mockup or prototype cannot tell you whether your app's menu works or focus moves correctly with your real components. ## Create Supporting Assets Painter can also generate images for the UI. Ask for a transparent background when an isolated asset will sit over your app's background. ```prompt Use Painter to create a paper-airplane illustration for the empty chat state. Match the blue in our screenshot. Give it a transparent background with no shadow, and check it on light and dark backgrounds. ``` Painter supports transparent PNGs. Amp should check the file's transparency as well as its appearance before delivering it; a white or checkerboard background alone is not proof. Keep the background for a complete composition, such as a UI mockup or poster. An app icon with its own designed background should stay opaque too. See [Painter](/docs/tools#painter) for the available background options.