Design research

Use for visual direction, interface reference selection, and component research. For a defect review of an existing interface, use ui-ux-review; for implementation, work within the project's frontend conventions.

Establish the design problem

Inspect the existing interface, framework, component inventory, tokens, and dependency versions. Ground the research in the user's audience, key task, content, brand constraints, and target devices. Preserve their chosen stack and design direction; ask only when missing context materially changes the recommendation.

Discover and verify

Use Designeer as a discovery directory for UI examples, design systems, and components. Browse the categories relevant to the task rather than collecting a broad catalogue. Follow promising links to their original site, documentation, and repository. Designeer is a discovery reference, not an assumed MCP service or installable skill. If it is unavailable, use original sources and state that limitation.

Separate visual inspiration from reusable code. For each shortlisted reference, record the original URL, date checked, relevant pattern, and how it serves the requested user task. A screenshot demonstrates appearance; it does not establish working interactions or permission to copy assets.

Before recommending code or assets for reuse, verify the original source's license and attribution obligations, commercial-use terms where relevant, maintenance status, framework/version fit, dependency cost, and SSR or client-only requirements. Check the actual component or asset license rather than assuming a directory listing or an open repository grants reuse rights. If terms or compatibility cannot be confirmed, mark them unresolved and choose another source or create an original implementation of the general pattern.

Assess accessibility through source documentation and, when feasible, a working demo: semantic structure, keyboard behavior, visible focus, contrast, zoom/reflow, accessible names, and reduced-motion behavior. Distinguish documented support from behavior actually tested. Do not treat attractive visuals or a library's accessibility claim as complete evidence for the final interface.

Produce an actionable brief

Recommend a coherent direction and explain the selections in terms of the user's task. Include:

• Page hierarchy and key interactions, with loading, empty, error, and success states where relevant.
• Concrete typography, color roles, spacing, layout, and motion guidance mapped to existing tokens; identify any justified additions.
• Responsive behavior and accessibility acceptance criteria for the target devices.
• A short reference table: original source, pattern to adapt, verified reuse terms, compatibility, accessibility evidence, and unresolved issues.
• Component mapping: existing project component first, a small original implementation next, and a new dependency only when its benefit justifies the cost.

Keep the brief specific enough to implement without guessing the hierarchy or interaction behavior. Link evidence near the decision it supports. Research alone does not authorize installing packages, running copied commands, importing remote registries, creating accounts, or changing integrations. Proceed into implementation only within the user's requested scope and normal project authorization.