Apply this skill to every frontend, UI, or UX task, even a small fix or a request for advice. Scale the work to the change; the research exemptions below do not exempt a task from using the skill.
Make an interface that fits its subject, users, and primary task. Aim for a considered visual identity and straightforward interactions. Respect the brief, existing design system, stack, and scope: a design request does not require implementation, and a review does not authorise edits.
Research before designing
For a new interface, substantial change, or unresolved design decision:
- Search online for at least two independent products that solve a similar problem for similar users. Include a reference with strong visual execution. Inspect the relevant screen or flow, not merely the product's marketing homepage.
- Actually view screenshots or rendered screens from both products. Live sites, official screenshots, help articles with images, app-store galleries, and recorded demos can provide evidence. Open images at a readable size. Search snippets, page text, image descriptions, and screenshots saved but never viewed do not count as visual inspection.
- For interactions, navigation, or motion, also examine a relevant video or exercise a live demo. Inspect the before, during, and after states; use timestamped video frames when playback is unavailable. A transcript alone cannot show animation or layout changes. Static composition work need not include a video.
- Search for and read relevant UX/UI best practices from at least one authoritative source, such as platform design guidance, an established design system, W3C accessibility guidance, or usability research. Read the guidance itself; a title, search snippet, or metadata-only response does not count. Match it to the actual problem: forms, filtering, touch controls, navigation, data density, and so on. Competitor behaviour is an observation, not proof of good usability.
Before proposing even a preliminary direction, keep a short research note with source URLs, screens or video timestamps actually viewed, visual observations from both products, a relevant recommendation from the guidance text, and the decisions these support. Check that any proposed interaction is also informed by a video or live interaction you actually inspected. If evidence is missing or a fetch failed, try another source or available tool. Calling a proposal "untested" does not replace this research. Do not substitute remembered conventions or a list of links for research. A request for a quick answer or "just the code" does not remove this preparation.
Reuse qualifying research already gathered for the task. A typo, spacing correction, or other narrow fix that preserves the design only needs inspection of the affected interface. Respect requests not to browse; if access remains unavailable after alternatives, identify the missing evidence and proceed from supplied material without claiming the research was completed. Keep research notes out of the product UI.
Choose a direction and build
Turn the evidence into a brief direction: the main user task, information hierarchy, layout, type, palette, and relevant interaction states. Explain which patterns to adapt or avoid and why. Learn from references without copying their identity or assets.
Choose typography, spacing, imagery, and colour for this subject. Avoid interchangeable card grids, decorative labels, and fashionable effects added without a purpose. Expressive work needs deliberate detail; restrained work needs precise proportions and alignment. Keep motion useful and respect reduced-motion preferences.
Implement within the existing project conventions. Make controls work, use appropriate semantic elements, and account for keyboard or controller focus, readable contrast, target sizes, and responsive layouts. Include the loading, empty, error, and recovery states that the feature can encounter. Use realistic content and apply natural-writing to copy; the same research can support both skills.
Inspect the result
Run the changed interface, exercise its main interactions, and actually view captures at the relevant screen sizes. Check hierarchy, spacing, legibility, overflow, focus, and state feedback against the brief and research. Fix visible problems and recapture the affected states. Run appropriate project checks; code inspection alone does not establish visual quality.
For design-only work, check the proposed layout and states against the evidence and clearly distinguish the proposal from tested behaviour. For reviews, report supported findings. Keep the handoff brief: what changed, the sources behind important choices, what was verified, and any material limits. Follow polite-browser-use when operating browsers and view-video when inspecting recordings, if available.