Improve an existing screen with AI
Use design references to solve a specific problem while preserving the components, behavior and identity your product already has.
Give the change a job
Start with a moment where the screen makes someone work too hard. A broad request to modernize an interface gives an agent permission to change almost everything. A specific problem gives you a way to judge whether the work helped.
This guide uses a fictional support-request queue. An operator needs to find an urgent, unassigned request and open it. The existing screen has a search field, filters, a table and a side panel. Subjects are truncated, every status badge is visually loud, and row actions compete with the request itself.
The brief is to make triage easier while keeping search, sorting, selection, permissions and the side panel working as before. A new dashboard, new navigation or new priority rules would be separate work.
Find the system that already exists
Have the agent inspect the running screen and its source before showing it references. Include an ordinary row, a long subject, an unassigned request and an empty result. Capture the same states again after the change so the comparison is meaningful.
Ask it to locate the actual table, text, badge and action components, plus the tokens they use. A screenshot cannot establish whether a spacing value is shared, whether a row is keyboard accessible or which element owns the click handler. If the agent cannot run the app, its plan should identify those limits.
Inspect the support-request queue in this project before changing it. My goal is to make urgent, unassigned requests easier to find and open. Identify the relevant route, components, typography, spacing and status styles. Inspect the running page if available. List the current search, sorting, selection and row-opening behaviors that must survive. Report what you could not inspect. Do not edit yet.
Give each reference one responsibility
Create a focused Taste collection for this queue. Choose one reference for readable rows and another for restrained status treatment. Add notes explaining each choice. A collection of ten attractive dashboards with different navigation patterns gives the agent more decisions to reconcile.
For the row reference, a useful note would be: let the subject take the flexible width, keep the owner easy to scan, and allow a second line when needed. For the status reference: use quieter treatment for routine states while retaining clear text labels. Keep your product's existing meaning for priority colors.
A reference does not need to resemble the whole product. Its value here is a particular relationship between content and emphasis. Ask the agent to inspect the images and notes; if it cannot see an image, it should not invent its layout.
Choose three decisions you can defend
In this example, the proposed patch has three parts: give subjects flexible width with up to two visible lines, reuse the existing quiet badge variant for routine status, and align the current row actions consistently. Keep the action labels and their keyboard access.
Each choice has a cost. Taller rows reduce the number visible at once; check whether reading subjects matters more than maximum density for this task. Quieter badges can obscure urgency if applied indiscriminately, so preserve the established priority signal. Hiding actions until hover may look cleaner but makes them harder to discover on touch screens.
Map each proposed change to an existing component or token. If the current table cannot support the change without a substantial rewrite, reduce the scope rather than quietly replacing the table.
Read my Taste collection named “Support queue”. Inspect its references and notes, then map the useful ideas to this project's existing components. Propose at most three changes for the triage task. For each, name the current component, the proposed change, the user benefit, the tradeoff and the check that would demonstrate it works. Preserve branding, navigation, data behavior and permissions. Do not introduce a new component library.
Check the patch against awkward content
Once the proposed changes make sense, ask the agent to implement that scope. Review the diff as well as the screen: an unrelated global token change can improve this page while disturbing several others. Shared component changes deserve checks wherever that component is used.
- Compare the same request data and viewport before and after. A cleaner screenshot with shorter text is not evidence of improvement.
- Find and open an urgent, unassigned request without relying on color alone. Check that visible labels still communicate its state.
- Try the original search and selection tasks. Confirm that wrapping text has not covered controls or changed their click targets.
- Keep only changes that support the brief. Record any unresolved tradeoff instead of treating a polished screenshot as proof that the task became faster.
Implement the agreed queue changes using the existing components and tokens. Keep all current controls and handlers. Verify a short subject, a long subject, an unassigned request, an empty result and a narrow viewport. Recheck sorting, filtering, row opening, selection and keyboard access. Show the changed files and report which checks actually ran. Flag anything that still needs manual review.
What success looks like
You can explain every changed element in terms of the triage task, identify the existing component it uses, and show the states and behaviors you checked.
Use the workflow in your coding tool
If Taste is not connected yet, use the guide for your client. Connection setup is separate from inspecting the project and agreeing on a useful change.