How to make Gemini better at UI design

To make Gemini better at UI design, give it one product workflow, durable project context, a reusable UI skill, focused visual references, and checks it can run against the real application.

Do not ask Gemini to invent the product and its visual system in one prompt. Define the user, content, actions, states, and constraints first. Then let Gemini apply those decisions in code and correct the rendered result.

This Guide uses Gemini CLI terminology because it provides concrete project context, skill, planning, and command workflows. Check the access note below before following the CLI steps.

Check which Gemini coding surface you have

Gemini access changed on June 18, 2026.

Google’s official transition announcement says Gemini CLI and Gemini Code Assist IDE extensions stopped serving requests for individual users on free, Google AI Pro, and Google AI Ultra plans. Those users moved to Antigravity CLI.

Gemini CLI and Gemini Code Assist remain supported for organizations using Gemini Code Assist Standard or Enterprise, Gemini Code Assist for GitHub through Google Cloud, and users with supported paid API-key access.

This means:

• Follow the exact GEMINI.md, .gemini/skills/, and Gemini CLI commands in this Guide only when your account still has a supported Gemini CLI workflow.
• If you were moved to Antigravity CLI, use the product contract, reference selection, implementation passes, and review method, but follow Antigravity’s current setup documentation for instruction and skill files.
• Do not assume configuration files transfer between Gemini Chat, Gemini CLI, Gemini Code Assist, and Antigravity.

Naming the surface is the first step. “Use Gemini” is not enough to define which files, tools, or review loop are available.

What you will build

The running example is a support inbox for a software product.

The finished workflow lets a support lead:

1. Find unresolved conversations.
2. Filter by priority and assignment.
3. Open a conversation without losing list context.
4. Assign the conversation to a teammate.
5. Recover from loading and request failures.

The page must support loading, no conversations, no filter results, request error, details open, assignment pending, assignment success, assignment error, and permission denied states.

Before you start

You need:

• supported access to Gemini CLI
• a frontend repository that runs locally
• the route and data flow for the target workflow
• the project’s development, lint, type, test, and build commands
• realistic data or fixtures
• one relevant InterfaceKit system
• screenshots or renders at 1440px, 768px, and 390px

Start Gemini CLI at the repository root so it can discover the intended workspace context:

cd /path/to/your-project
gemini

Replace /path/to/your-project with the real project directory.

The official Gemini CLI documentation covers installation, authentication, commands, tools, and current capabilities.

Step 1: Write the product contract

Do not start with “create a modern support dashboard.”

Write the decisions the interface must express:

Route: /support/inbox
User: A support lead
Outcome: Find an unresolved conversation and assign it to the right teammate
Primary action: Open conversation
Secondary action: Assign teammate
Data:
- Customer
- Subject
- Priority
- Status
- Assignee
- Last message time
- Channel
Rules:
- Only leads can reassign conversations
- A conversation cannot be assigned twice while a request is pending
- Closed conversations remain visible when explicitly filtered
Required states:
- Loading
- No conversations
- Populated inbox
- No filter results
- Request error
- Conversation open
- Assignment pending
- Assignment success
- Assignment error
- Permission denied
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, API contracts, analytics, and keyboard behavior

The contract replaces broad aesthetic guesses with product facts.

Step 2: Define done with observable checks

Write acceptance criteria before implementation:

• Customer, subject, priority, status, assignee, and recency can be scanned.
• Filters remain connected to the conversation list.
• Opening a conversation preserves enough list context to continue triage.
• Assignment names the teammate and conversation.
• Pending assignment cannot submit twice.
• Permission restrictions explain which role can reassign.
• Empty, no-results, and error states give the correct next action.
• Long customer names and message previews do not break the layout.
• The workflow works with a keyboard.
• The information priority survives all three target widths.
• Project checks pass.

These checks tell Gemini what completion means beyond producing a screenshot.

Step 3: Put durable context in GEMINI.md

Gemini CLI uses hierarchical GEMINI.md files for persistent project context. The official GEMINI.md guide explains global, workspace, and just-in-time context.

Add a short GEMINI.md at the repository root:

# Frontend UI

- Inspect existing components before creating new ones.
- Use tokens from `src/styles/tokens.css`.
- Do not add a UI or icon library without approval.
- Preserve route, data, analytics, and accessibility behavior during visual work.
- Make loading, empty, error, success, disabled, and permission states reachable.
- Review changed UI at 1440px, 768px, and 390px.
- Do not commit generated review screenshots.
- Run `npm run lint`, `npm run test`, and `npm run build` before finishing.
- Report commands, results, renders reviewed, and remaining gaps.

Replace the paths and commands with the project’s real values.

For a monorepo, add another GEMINI.md inside the frontend directory:

# Web application

- Routes live in `src/routes`.
- Reuse components from `src/components`.
- Use the existing fixture system for visual states.
- Keep desktop, tablet, and mobile behavior in the same component.
- Review the running route before reporting completion.

Gemini CLI can discover more specific context when it accesses that area.

Inside an interactive session:

/memory show

Review the combined context. If you changed a file during the session, reload it:

/memory reload

Do not put the current support contract or temporary screenshots in GEMINI.md. They belong to the task.

Step 4: Create a Gemini UI design skill

Gemini CLI supports Agent Skills as on-demand workflows. Workspace skills can live under .gemini/skills/ or the interoperable .agents/skills/ alias.

Create .gemini/skills/ui-implementation/SKILL.md:

---
name: ui-implementation
description: Build or improve product UI with project components, focused references, reachable states, responsive renders, and evidence-based correction.
---

# UI implementation

1. Read the product contract and applicable `GEMINI.md` context.
2. Inspect the route, component system, tokens, data conventions, and checks.
3. Map the supplied InterfaceKit references to existing project code.
4. List missing product decisions before editing.
5. Build the page frame and content hierarchy.
6. Implement the workflow and every required state.
7. Apply foundations through the existing token system.
8. Run the application and review 1440px, 768px, and 390px.
9. Compare structure, hierarchy, density, components, states, and styling.
10. Fix concrete differences and rerender.
11. Run project checks and review the diff.
12. Report evidence, deliberate deviations, and remaining gaps.

Do not add product sections, component libraries, or visual foundations that
are not supported by the task, repository, or supplied references.

The official Gemini CLI skills documentation explains skill discovery, activation, consent, and workspace paths.

Reload and inspect the available skills:

/skills reload
/skills list

Gemini asks for consent before activating a skill and reading its bundled resources. Review the name, purpose, and path before approving it.

A good Gemini UI design skill packages a repeatable process. A skill full of visual adjectives still leaves Gemini to invent the page structure and product behavior.

Step 5: Select one InterfaceKit system

Browse InterfaceKit and choose a product system with comparable behavior and density.

For the support inbox, collect:

• application frame
• inbox or resource-list block
• filter toolbar
• priority and status treatments
• conversation details panel
• assignment form
• loading, empty, error, and feedback patterns
• typography, spacing, color, border, and radius foundations

Create a reference map:

Do not combine disconnected screenshots from several products. One coherent Gemini design system reference gives the page, components, and foundations a shared logic.

Step 6: Add focused files and images

Tell Gemini which files own the current behavior:

Use the ui-implementation skill.

Read:
- docs/support-inbox-contract.md
- src/routes/support/inbox.tsx
- src/components/FilterToolbar.tsx
- src/components/ConversationList.tsx
- src/components/Drawer.tsx
- src/styles/tokens.css

Also inspect the supplied InterfaceKit frame, inbox, filter, details,
assignment, state, and foundation references.

In an interactive Gemini CLI prompt, use @ file references to add local context. Add the relevant reference and current screenshots, then label them:

@reference-desktop.png
@current-desktop.png

The first image is the InterfaceKit reference.
The second image is the current support inbox.
Compare structure and hierarchy before suggesting visual polish.

Do not add every screenshot in the library. Focused context makes it easier to identify which source supports a decision.

Step 7: Start in Plan Mode

Gemini CLI provides a read-only Plan Mode for inspecting a project and agreeing on a strategy before implementation. Its official Plan Mode documentation describes the workflow and restrictions.

Launch directly in Plan Mode:

gemini --approval-mode=plan

Or enter it from an interactive session:

/plan build the support inbox workflow

Then ask for a specific analysis:

Use the ui-implementation skill.

Read the active GEMINI.md context, product contract, target route,
existing components, tokens, and supplied references.
Do not edit application files.

Return:
1. Current route and data flow.
2. Components and foundations to reuse.
3. Reference patterns mapped to project code.
4. Missing product decisions.
5. State transitions for conversation details and assignment.
6. Responsive behavior at 1440px, 768px, and 390px.
7. Accessibility risks.
8. An implementation and verification plan.

Name every new component or variant you expect to add.

Review and edit the plan before approving implementation. Remove any section that does not support the contract.

Step 8: Build in three passes

Separate structure, behavior, and visual foundations.

Pass 1: Frame and hierarchy

Implement only the support inbox frame and static content structure.

Reuse the existing application shell.
Apply the supplied content rail, page-header alignment, filter position,
conversation-list structure, details region, and responsive layout.
Use realistic support content.

Do not connect assignment or tune decorative details yet.
Run the app and review 1440px, 768px, and 390px.
Report hierarchy, overflow, and reuse problems.

The page should explain the triage workflow before color and polish.

Pass 2: Workflow and states

Implement the support inbox through the existing data, permission,
and mutation patterns.

Support loading, no-conversations, populated, no-filter-results,
request-error, conversation-open, assignment-pending, assignment-success,
assignment-error, and permission-denied states.

Make every state reachable for review.
Preserve focus when the details panel opens and closes.
Prevent duplicate assignment requests.
Do not add visual foundations in this pass.

Review each state in the running application. A code branch is not proof that the state works.

Pass 3: Foundations and polish

Apply the supplied typography, spacing, color roles, borders, radius,
and elevation through the project token system.

Compare the current renders with the labeled references.
Correct component density, hierarchy, alignment, and responsive behavior.
Preserve the verified workflow.

Rerender at 1440px, 768px, and 390px.
List each correction and its evidence.

This order prevents visual polish from hiding incomplete behavior.

Step 9: Make every state reachable

Create a review matrix:

Use the project’s existing fixture, story, preview, test-data, or development-state approach. Ask Gemini to propose the smallest local-only method if one does not exist.

Step 10: Decide responsive behavior explicitly

Do not ask Gemini to “make it responsive” without defining what should happen.

Drag through intermediate widths after checking 1440px, 768px, and 390px. Toolbars often fail between named breakpoints.

Step 11: Correct Gemini with evidence

Use four parts:

Observed problem
At 390px the customer name disappears before the message subject,
and the assignment action appears above the conversation context.

Reference
The supplied compact inbox pattern keeps customer and priority together,
then shows subject and recency before local actions.

Required change
Place customer and priority in the first row, subject and recency in the
second, and move assignment into the opened conversation.

Constraints
Keep desktop structure, data fields, component APIs, and keyboard order.
Rerender at 390px and 430px.

Correct in this order:

1. Missing or wrong behavior.
2. Page structure and hierarchy.
3. Responsive failure and overflow.
4. Component misuse.
5. Typography and spacing.
6. Color, borders, radius, shadow, icons, and motion.

A focused Gemini UI design prompt gives the model less room to trade one problem for another.

Step 12: Verify behavior and code

Ask Gemini to run the exact commands in GEMINI.md.

The final report should include:

• files changed
• existing components reused
• components or variants added
• states reviewed and how they were reached
• viewport sizes inspected
• screenshots compared
• keyboard workflow result
• lint, type, test, and build commands with results
• deliberate deviations from the reference
• anything that remains unverified

Review the actual command output and application. Do not accept “all checks pass” without the evidence.

Step 13: Test the system on a second route

Apply the same frame, filter behavior, list density, status language, details pattern, and responsive rules to the customer list or assignment queue.

Ask Gemini to report:

• which components and foundations were reused
• which existing variant needed extension
• which new product decision was unavoidable
• which page-local styles can now be removed

The second route shows whether Gemini built a system or one tuned composition.

What to do when Gemini UI is still weak

Is Gemini better than ChatGPT for UI/UX?

There is no stable brand-level answer. Gemini and ChatGPT each have several surfaces, models, tools, instruction systems, and permission setups.

Compare the exact products on the same task:

• same repository
• same product contract
• same InterfaceKit references
• same required states
• same breakpoint sizes
• same accessibility checks
• same build and test commands

Score system reuse, workflow completeness, responsive behavior, visual accuracy, correction quality, and maintainability. Repeat the comparison when either product changes materially.

The result from your workflow is more useful than a permanent ranking.

Direct answers about Gemini UI design

How do I use Gemini for UI/UX design?

Use a supported Gemini coding surface to inspect the project, plan the workflow, apply a coherent reference system, implement complete states, compare responsive renders, and run verification. Keep user research, product priority, and final judgment explicit.

Is Gemini good for UI design?

Gemini can be useful for UI implementation when it has repository context, visual references, reachable states, and a review loop. It is less dependable when “make it beautiful” is the complete brief.

How do I make Gemini better at UI designs?

Give Gemini a product contract, short GEMINI.md context, a focused UI skill, exact project files, one InterfaceKit system, responsive decisions, and evidence-based corrections.

What should a Gemini UI design skill contain?

A Gemini UI design skill should define the inputs, inspection steps, implementation order, state coverage, render sizes, comparison method, project checks, and evidence required at the end.

What should a Gemini UI design prompt include?

Include the user outcome, relevant files and references, product rules, required states, breakpoint behavior, constraints, and done criteria. Tell Gemini what it may decide and what must remain unchanged.

Can Gemini UI design AI generate the whole product?

Gemini can generate a large amount of UI code, but generation does not supply missing product evidence or prove the workflow is correct. Build and review one complete workflow, then test whether the system transfers to a second route.

Gemini UI checklist

• The current Gemini surface and account access are confirmed.
• The task defines one user, outcome, workflow, and state set.
• Done criteria describe observable behavior.
• Root and nested GEMINI.md files contain scoped durable context.
• /memory show displays the intended instruction chain.
• The UI skill lives under .gemini/skills/ or .agents/skills/.
• /skills list shows the intended skill.
• One InterfaceKit system owns the visual direction.
• Project files, references, and screenshots are focused.
• Gemini inspects and plans before a multi-file edit.
• Structure, behavior, and styling are separate passes.
• Every required state is reachable.
• Desktop, tablet, mobile, and intermediate widths are reviewed.
• Corrections cite visible evidence.
• Keyboard behavior and accessibility are checked.
• Project commands run and their output is reviewed.
• A second route tests whether the system is reusable.

Continue with How to prompt AI for UI design, or compare the same workflow in Claude Code, Codex, Kimi, or Cursor.

Browse InterfaceKit kits and give Gemini a coherent product system to apply.