ui-design
Design, build, or improve web and mobile interfaces using real product examples from UIZZE’s 800,000+ web and iOS screens. Use for UI design, UX design, frontend or web design, mobile app UI, responsive layouts, design systems, redesigns, visual polish, interface critique, and requests like “make this UI better.”
Install
npx skills add https://github.com/uizze/uizze --skill ui-designNew interface or major redesign
Adapted by Uizze from the licensed Impeccable new-work workflow; see the archive's NOTICE and MODIFICATIONS.md.
Establish what must remain true
Read the brief, representative screens, components, tokens, assets, and existing product/design documentation. Separate product facts from visual choices.
- An addition to an established surface inherits its identity. Solve the new task, hierarchy, content, and states without an identity exercise.
- A new surface inside an established product inherits its visual system but may need a different composition.
- An approved redesign may replace the visual language, not the product's truth, working behavior, or explicit brand commitments.
- A new product needs a chosen direction, not a default dashboard or landing-page template.
Choose the surface's main purpose: persuade, operate, read, or experience. A purchase page must communicate a real offer and action; an operational screen must expose tasks and state; reading needs structure and wayfinding; an experiential surface must lead with the work itself. These purposes guide the composition, not a prescribed aesthetic.
Decide before building
Ask only what changes the result: audience, job, primary action, real content, constraints, and what must not change. Do not re-ask settled facts or request CSS values from the user.
For an open-ended whole surface or new identity, propose two or three substantially different, product-grounded directions. Describe the first viewport, information density, type/colour character, and the interaction that matters. Include a real tradeoff. Get the user's choice before committing a new identity; an already supplied direction or explicit delegation of that choice is enough. Do not present colour-swapped versions of the same template.
Use relevant real-product references when available, and inspect them. Extract the structural lesson: how a table exposes comparison, how a form recovers from errors, how an onboarding step teaches the next action. A reference is evidence, not a licence to copy a brand.
Write a short design contract in the working plan or an existing development brief: purpose, composition, typography/colour/material roles, responsive changes, required states, and a verifiable finish condition. Keep it out of browser-delivered content. Do not create a documentation system for a small task.
Build the chosen direction
Start with the first meaningful viewport, using realistic content and actual assets. It must communicate the product's task or offer immediately, with an obvious next action. Do not replace missing product substance with decorative cards, empty charts, gradients, or invented metrics.
If the user provided or approved a visual comp, compare against that actual image at its dimensions. Measure layout regions, spacing, type scale, asset crops, and control placement. It is a spatial target, not just a mood. Keep text and controls semantic and usable. Do not ship a screenshot of the comp as a fake working interface. Do not fabricate features or commercial claims found in generated imagery.
Carry the selected visual language through navigation, inputs, buttons, content and secondary states. Distinction can come from composition, product-specific content, strong typography, imagery or interaction; it need not come from unusual controls. Do not quietly dilute the approved direction into the first familiar template.
Use available project assets and licensed materials. Verify image/font sources and provide a functional fallback; do not fetch or install dependencies without the task's authority. For genuinely new design systems, capture the final reusable decisions in the project's normal design documentation. Preserve existing DESIGN.md unless an update is in scope.
Complete and verify
Apply craft [blocked], and operate [blocked] or iOS [blocked] where relevant. Implement reachable loading, empty, error, disabled, success and recovery states, not a decorative collection of impossible states.
Make responsive choices structural: decide what stacks, collapses, scrolls, or remains fixed. Use the real copy, long values, and small screens. Implement the actual primary interaction; a convincing screenshot with inert controls is unfinished.
Render the built result at representative sizes. Inspect full context and detail crops, not only a thumbnail. Compare the hierarchy, composition and interaction with the design contract and supplied reference. Wait for fonts/images and capture settled states; broken captures are not design evidence.
Fix material gaps in one batch, then inspect the changed result again. Continue only while resolving named issues within the agreed scope; if a pass makes no progress, report the limitation and the next decision. Do not announce a complete visual pass when rendering, a required state, or the requested target was not checked.