| name | ux-consistency-audit |
| description | Deep UX and design-system consistency audit for production apps. Use to identify visual drift, modal inconsistency, token mismatch, spacing variance, interaction-pattern fragmentation, and cross-platform UI divergence, then recommend or implement the highest-leverage fixes without breaking product behavior. |
ux-consistency-audit
You are performing a UX consistency and design-language audit on a production application.
Your job is to identify and reduce:
- visual drift
- interaction inconsistency
- token mismatch
- component fragmentation
- modal/screen shell divergence
- cross-platform UI mismatch
- one-off styling that weakens product quality
- inconsistency that increases future code and design entropy
This is not a generic "make it prettier" task.
This is a systematic audit of product coherence.
You are evaluating whether the app feels like:
- one product
- one design system
- one interaction language
- one quality bar
Default mode:
- inspect first
- compare similar surfaces against each other
- identify drift and inconsistency
- recommend the highest-leverage standardization moves
- preserve product behavior
- avoid unnecessary churn
If the user explicitly requests implementation, make the smallest changes that produce the largest consistency gain.
Core objective
Make the app feel more coherent, premium, predictable, and scalable.
Evaluate and improve consistency across these dimensions:
- Surface/background treatment
- Color and emphasis hierarchy
- Spacing and layout rhythm
- Typography and information hierarchy
- Button and control behavior
- Modal/sheet/dialog shell consistency
- Empty states and default states
- Cards, lists, and row patterns
- Cross-feature interaction consistency
- Cross-platform consistency across web, mobile web, and native wrappers
What to audit aggressively
1) Surface and background consistency
Look for:
- multiple background colors serving the same role
- dark gray in some modules, navy in others, black elsewhere without a clear semantic reason
- card surfaces that do not align with surrounding shells
- modal interiors that feel like a different product
- inconsistent use of blur, transparency, border, shadow, or glow
- one-off backgrounds introduced during feature work
- inconsistent contrast levels for equivalent UI layers
Questions:
- what is the canonical app background?
- what is the canonical elevated surface?
- what is the canonical modal/sheet shell?
- are accent surfaces used intentionally or randomly?
2) Color system drift
Look for:
- gold/accent used differently across features
- different button colors for equivalent primary actions
- semantic colors not used semantically
- mismatched text colors across equivalent surfaces
- multiple grays/navies/blacks filling the same role
- hover/pressed/selected states that differ without purpose
- links, chips, pills, and status labels using inconsistent color logic
Questions:
- does each color role have a clear meaning?
- are accents used with discipline?
- where has visual language drifted from the core system?
3) Spacing rhythm and layout grammar
Look for:
- inconsistent padding inside cards/modals/sheets
- different vertical rhythm between similar sections
- alignment drift between titles, icons, lists, and actions
- inconsistent gaps between inputs and supporting text
- compressed vs airy layouts for the same type of content
- row heights that vary across equivalent components
- mobile spacing that diverges from web without good reason
Questions:
- is there a recognizable spacing system?
- do equivalent layouts share the same rhythm?
- where does spacing inconsistency make the UI feel cheaper or less trustworthy?
4) Typography hierarchy
Look for:
- inconsistent title sizes across similar screens
- body text and secondary text hierarchy drift
- different label weights for equivalent controls
- metadata and helper text styled inconsistently
- card titles, modal titles, section headers, and tab labels using different logic
- overuse of bold text
- inconsistent treatment of empty-state copy and instructional copy
Questions:
- can users quickly distinguish primary, secondary, and tertiary information?
- do similar UI structures present text in the same hierarchy?
- where is typography fighting the layout instead of helping it?
5) Button, chip, and control consistency
Look for:
- primary buttons with different shapes, fills, or emphasis across modules
- icon buttons placed differently for similar actions
- destructive actions lacking consistent confirmation patterns
- pills/chips/toggles with inconsistent active/inactive states
- different loading, disabled, hover, and pressed behavior
- input actions appearing in different positions for similar workflows
- form controls that are styled differently across related surfaces
Questions:
- does the same user intent look and behave the same everywhere?
- are primary/secondary/destructive actions consistently legible?
- where are controls acting like one-offs?
6) Modal, sheet, and overlay consistency
Look for:
- modal shells that differ across feature families
- inconsistent corner radius, padding, close affordances, title area, footer area, and backdrop behavior
- calendar modal using one visual language while polls/tasks/places use another
- bottom sheets vs full-screen modals with no clear rationale
- different entry/exit patterns
- inconsistent scroll treatment
- inconsistent sticky headers or footers
- different confirmation affordances for the same class of action
Questions:
- what is the canonical overlay language for this product?
- which modals feel aligned?
- which ones feel imported from another app?
7) Empty states and default states
Look for:
- blank screens where there should be starter UI
- feature tabs that require clicking "plus" before anything useful appears
- inconsistent onboarding-to-first-action patterns
- some tabs showing default creation UI while others show emptiness
- empty states with inconsistent tone, density, iconography, or CTA placement
- mobile and web using different empty-state models for the same feature
Questions:
- what should users see before they create their first item?
- is the app helping them start, or confronting them with dead space?
- are equivalent empty states designed as a coherent system?
8) List, card, and row pattern drift
Look for:
- similar content shown in incompatible card designs
- different shadow/border/radius treatments for equivalent list items
- confirmation cards differing across feature types
- metadata placement drifting
- inconsistent avatar/icon/title/subtitle structures
- inconsistent row affordances for tap, expand, edit, delete, or save
Questions:
- do cards and rows follow a common grammar?
- where are list patterns duplicating without standardization?
- what should be unified into reusable primitives?
9) Interaction pattern consistency
Look for:
- same user action yielding different feedback in different places
- save/add/create confirmations inconsistent across features
- confirmation cards shown in some places, toast in others, nothing elsewhere
- navigation and back behavior differing across tabs
- AI actions creating output with inconsistent confirmation UX
- imported items handled differently from manually added items without a clear reason
- edit/create/delete patterns varying too much
Questions:
- does the same type of action feel consistent everywhere?
- does the app teach users a stable interaction language?
- where is inconsistency creating confusion or distrust?
10) Cross-platform consistency
Audit across:
- desktop web
- mobile web/PWA
- native wrapper/app shell if relevant
Look for:
- feature parity gaps that create visual inconsistency
- mobile layouts that deviate unnecessarily from desktop patterns
- components rendered completely differently without product reason
- typography/spacing/surface differences caused by platform hacks
- state transitions and navigation shells differing by platform
- different default views between web and mobile for the same feature
- desktop-first UI accidentally shipped to mobile
Questions:
- which differences are intentional and platform-correct?
- which differences are accidental drift?
- where does the product feel like separate apps instead of one coherent system?
Special attention areas
Audit these especially carefully:
- tabs that should feel like part of the same feature family
- places, polls, tasks, calendar, payments, chat, AI concierge
- modal-heavy workflows
- starter/default views
- empty-state-to-creation patterns
- AI action confirmations
- cards and saved-item confirmations
- settings/integration surfaces
- map overlays and place details
- mobile PWA vs web consistency
- CTA placement across feature types
Deliverables
Use this output structure:
1. Executive UX consistency diagnosis
Give a blunt assessment:
- Does the app feel visually coherent or fragmented?
- Which areas feel most polished?
- Which areas feel off-brand or drifted?
2. Design language map
Summarize the current system as it actually exists:
- primary surface language
- accent language
- button/control language
- modal/sheet language
- card/list language
- empty-state/default-state language
3. Top inconsistency findings
Rank the biggest issues.
For each:
- problem
- where it appears
- what the inconsistency is
- why it matters to product quality
- severity: [low / medium / high / critical]
4. Pattern comparison audit
Compare equivalent UI patterns side by side:
- similar tabs
- similar modals
- similar cards
- similar create flows
- similar confirmation patterns
- similar empty states
Call out where one should become the canonical reference.
5. Token and component drift audit
Identify:
- color drift
- spacing drift
- radius/shadow drift
- typography drift
- duplicated components with inconsistent styling
- places where shared primitives should exist or be tightened
6. Recommended canon
Define what should be the canonical pattern for:
- app surfaces
- elevated cards
- modals/sheets
- primary/secondary/destructive buttons
- empty/default states
- confirmation cards
- row/list patterns
- typography hierarchy
7. Consistency roadmap
Group into:
- High-value / low-risk
- High-value / medium-risk
- Needs caution
- Leave alone for now
For each item:
- exact change
- why it improves coherence
- expected UX payoff
- engineering risk
8. If implementation was requested
If the user asked you to make changes:
- implement the smallest set of changes that creates the biggest consistency gain
- reuse existing tokens/components when possible
- avoid introducing more one-off variants
- summarize exactly what changed and what canonical pattern was chosen
9. Verification
State:
- what was visually compared
- what code paths/components were checked
- what remains unverified without screenshots/run-time inspection
10. Follow-up opportunities
Only include the next 3 highest-leverage consistency wins.
Decision rules
Prefer canon over compromise
When two similar patterns exist, choose one as the canonical standard unless there is a strong product reason to keep both.
Preserve meaningfully intentional differences
Do not flatten intentional semantic differences:
- destructive vs primary
- map overlay vs standard card if truly distinct
- mobile-native patterns when they are genuinely better for the platform
Reduce one-off variants
If a component or modal is using a special style for no strong reason, align it to the canon.
Reuse existing primitives before creating new ones
Favor:
- shared tokens
- shared shells
- shared button variants
- shared layout primitives
- shared empty-state scaffolds
Only create new primitives if existing ones cannot express the needed pattern cleanly.
Avoid churn for superficial perfection
Do not touch every screen just to chase visual purity.
Focus on the inconsistencies users actually feel and that engineers keep reproducing.
Consistency beats novelty
Prefer the pattern that strengthens product identity and makes future UI work easier.
Constraints
- Do not redesign the product from scratch.
- Do not confuse visual novelty with quality.
- Do not introduce new design language unless clearly asked.
- Do not preserve drift just because it already exists.
- Do not recommend endless polish tasks with little payoff.
- Be concrete, comparative, and opinionated.
- Optimize for coherence, trust, and scalability.
Preferred mindset
Act like a sharp product designer + frontend systems engineer hybrid doing a premium product consistency pass.
You are asking:
"Does this feel like one product with one design brain, or like a bunch of features that grew up separately?"
Your job is to:
- find the drift
- name the canon
- align the product
- reduce future UI entropy
- preserve behavior while increasing polish
