search
Build search experiences that help users find what they need quickly, even when they are uncertain about what they are looking for. The goal is not perfect relevance on the first try; it is guiding users from intent to outcome through forgiving search and clear results.
Consult the search and filtering UX reference for autocomplete patterns, filter architecture, result presentation, and zero-results recovery. Consult the search and findability reference for site search, autosuggest, command palettes, and intent-aware findability. Consult the collection browsing and filtering reference for long result lists, faceted browsing, and filter overlays. Consult the predictive and intent-driven UI reference for recommendations, smart defaults, and resume flows.
MANDATORY PREPARATION
Users start this workflow with /search. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what users typically search for, what common queries fail, and how large the searchable dataset is.
Assess Search Needs
Understand the search context before designing the interface:
- Search intent: Are users looking for a specific item (known-item search), exploring a category (exploratory), or trying to complete a task (transactional)?
- Dataset size: Small datasets (< 100 items) may not need search; filtering or categorization may suffice. Large datasets need faceted search and ranking.
- Query patterns: What do users actually type? Common misspellings, synonyms, and abbreviations should be handled.
- Failure modes: What happens when search returns nothing? When it returns too much?
More from aladicf/better-web-ui
critique
Evaluate an interface from a UX perspective, assessing hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring and actionable feedback. Use when the user wants an overall design or UX review—not when the main need is measurable accessibility/performance diagnosis, or final micro-detail polish.
31polish
Perform a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping. Use when the work is functionally complete and needs finishing touches—not when the hierarchy, structure, tone, or technical foundation still need major changes.
31frontend-design
Create distinctive, production-grade frontend interfaces with strong hierarchy, thoughtful systems, and polished implementation that avoid generic AI aesthetics. Use when the user wants to build or redesign web pages, flows, components, or full app surfaces, or when another better-web-ui skill needs shared project design context before other better-web-ui skills.
30empty-state
Design focused empty states for zero-data, no-results, permission, and error situations with clear value framing, strong CTAs, and less dead chrome. Use when the user mentions blank pages, zero-data screens, no results, permission states, or dead controls—not broader onboarding strategy.
29normalize
Audit and realign UI to match design system standards, spacing, tokens, and patterns. Use when the user mentions consistency, design drift, mismatched styles, tokens, or wants to bring a feature back in line with the system.
29colorize
Build or refine UI color systems, warmth, semantic color, and color-based hierarchy in designs that are too gray, monochromatic, or missing color meaning. Use when the user mentions dull colors, gray UI, missing warmth, weak semantic color, or a need for stronger color hierarchy.
29