In this lesson
Before the agent starts building the application, see how it will look. It is easier to say “this button is hidden” or “I want a simpler screen” when you have an image in front of you.
What you will gain
- First screens shown graphically. You will see what the user has in front of them and how they move to the next step.
- Shared visual rules. Colors, text, buttons, and forms will fit together across the app. This set of elements and rules is called a design system.
- Directions saved for the agent. It will read the decisions and accepted graphics when building the next screen.
For the ideas app, a list of ideas and an add-idea view are enough at first. Also show an empty list: a new user needs to know where to start.
Show what should fit your project
Stay in your project chat. Add screenshots or links to two or three examples you like. Say what you want to take from them: a readable layout, calm colors, large buttons. Add a logo, agreed colors, or a brand appearance description if you have one. You do not need any of these materials to start.
The agent should first read who you are building for and what that person needs to do. An app used in the field on a phone needs a different layout from a tool for working with a large table at a desk.
Before designing screens, read the product description, plan, and project instructions. Briefly say who will use the application, in what conditions, and what their most important task is. Do not guess missing information—ask about what affects appearance and use. Check whether we already have screen designs, brand rules, a design system, or ready interface elements. If so, use them and name the source. Attached inspiration: [what I like and why; or: I do not have inspiration yet]. Propose one visual direction and explain why it fits this project. Do not build the application yet.
Agree on appearance and view the first screens
You do not need a large catalogue immediately. Agree a small set with the agent that it will use later. If the project already has its own design system, start there.
| What you agree | Example for an ideas app |
|---|---|
| Colors, type, and spacing | One main-button color, readable text, and even space between ideas |
| Shared elements | “Add idea” button, text field, idea card, and saved message |
| Layout and transitions | List → adding → return to list with a new idea |
| What is visible when something changes | Empty list, saving, successful save, failed save |
| Phone and usability | Comfortable buttons, text without zooming, keyboard use, and a clear error |
Based on the decisions, show a graphical proposal of the first screens for the scenario: [scenario from the plan]. I want to see mockups as images, not only a written description. If you do not have a tool for making images, say so before starting and propose a way to show a mockup. First show one direction: a board with colors, typography, a button, a form field, and an example message, plus the most important screens. If the brand appearance is not agreed, we may compare at most three directions and choose one. Use example text that fits the project. Show the screen on desktop and phone, the empty view, and saving, error, and success messages. Choose shared elements compatible with the technology in the plan. If you need a library of ready buttons and forms, first check whether the project already has one. If not, compare at most three libraries compatible with the selected technology and recommend one. Explain in plain language what they fit, whether they are maintained, how they support accessibility, whether they can have your own appearance, and what they mean for maintenance. Give limits and check current information in official sources. Do not install anything yet. Show mockups in the conversation and wait for my feedback. Do not build working application functions yet.
Review the result and be specific: “On the phone I want to see Add idea immediately”, “The text is too small”, “This message does not tell me what to fix.” The agent shows a revised version in the same conversation. You can speak if that is more convenient.
When the layout works for you, ask for a small clickable preview with example data. Move from the list to adding and back. At this stage you check layout and use. Real data saving is built in lesson 6.
Save the choice and move to building
I accept these screens and visual rules: [name a specific version]. Save them in the “Interface” section of the existing docs/plan.md. Include user tasks, the screen map, visual source, colors, typography, spacing, shared elements, important states, phone, keyboard use, how messages are written, and the order for showing later screens in Live Demo. Save accepted graphics in the project and link to them in the plan. If you cannot save them, say what you need. Mark open decisions explicitly. In the project AGENTS.md, briefly record where to read interface rules and graphics before building another screen. Name the selected library if we agreed it. Do not create a second plan or a second copy of the rules. Tell me which first piece we will build in lesson 6 and how we will compare it with the accepted design. Do not start implementation yet.
Check before moving on: you can point to accepted screens, find the button starting the main task, and move through the whole scenario in the preview. The agent shows the saved rules and graphics and explains how it will apply them in the next screen. “It will be modern and readable” is not enough.
If you are building a tool without screens, ask the agent to record in the plan that this step does not apply and move to building.