Research-backed frontend development

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.