メニュー
Use when designing a search feature for a website or application — to structure the input, autocomplete, results list, and zero/no-results states so users find what they need with minimal friction.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/jeffreytse/grimoire-core --skill design-search-uxコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use when comparing very differently-titled roles for compensation banding, leveling, or organizational design — score each role's inherent Know-How (knowledge, skills, experience required), Problem Solving (complexity and freedom of thinking, scored as a percentage of Know-How), and Accountability (freedom to act and magnitude of impact), because job titles and informal seniority perceptions vary inconsistently across departments and don't provide a comparable basis on their own.
Use when many people request your scarce time, mentorship, or expertise and you cannot evaluate their genuine commitment level from a conversation alone — require a specific, costly, objectively verifiable unit of self-directed output (a set number of completed attempts) before engaging, because genuine commitment is what a conversation cannot reliably reveal but a completed, verifiable body of work can.
Use when deciding how to allocate a manager's or leader's limited time across competing activities — before defaulting to whatever is most urgent, estimate each candidate activity's leverage (how many people's output it affects, for how long, and whether it requires your specific position), because a manager's actual output is the output of the organization under their influence, not their own individual task completion.
SOC 職業分類に基づく
SKILL.md を表示中
| name | design-search-ux |
| description | Use when designing a search feature for a website or application — to structure the input, autocomplete, results list, and zero/no-results states so users find what they need with minimal friction. |
| source | NNG "Search UX" (Pernice, 2020); Morville & Callender "Search Patterns" (O'Reilly, 2010); Baymard Institute "On-site Search UX" (2021, 70-guideline study across 60 major sites) |
| tags | ["search","search-ux","autocomplete","search-results","information-retrieval","zero-results","filters","ux-patterns"] |
Place search in the expected location, expose the input field (not just an icon), support autocomplete for large corpora, and design no-results states that recover users rather than abandoning them.
Adopted by: Baymard Institute's "On-site Search UX" (2021) is the most comprehensive empirical study — 70 guidelines tested across 60 major e-commerce sites; NNG's "Search UX" research (Pernice, 2020) covers placement, input design, and results across enterprise and consumer products; Google, Amazon, and Spotify have published case studies on search autocomplete and result quality improvements; Elasticsearch and Algolia both document UX patterns in their implementation guides Impact: Baymard Institute: 68% of major e-commerce sites fail basic on-site search UX — the majority of search UX problems are in placement, autocomplete, and no-results design, not result ranking; NNG: users who successfully use site search convert at 1.8× the rate of non-searchers (Chase 2016); Etsy's search UX redesign (2019) — fixing autocomplete and result highlighting — increased search conversion by 6%; Spotify's search interface redesign (2018) increased search session completion by 34% Why best: Search is the highest-intent interaction on a website — a user who types a query is expressing an explicit need; the design of the search UI determines whether that intent is fulfilled or abandoned; poor search design (hidden input, no autocomplete, empty no-results page) wastes the highest-value user action
Sources: Baymard Institute "On-site Search" (2021); NNG "Search UX Strategies" (Pernice, 2020); Morville & Callender "Search Patterns" (O'Reilly, 2010); Nielsen "10 Usability Heuristics" (1994) — Heuristic 1: Visibility of system status
Search placement is convention-driven — deviating from conventions requires measurable justification:
Desktop:
Mobile:
Input field vs icon only:
❌ Icon only (desktop):
[search icon] — requires a click to reveal the input field; hides a primary affordance
✅ Visible input field (desktop):
[🔍 Search products... ] — input always visible; no extra click required
✅ Icon with expand (mobile):
[🔍] — tapping expands to full-width input; acceptable on mobile where space is limited
Baymard: icon-only search on desktop increases search abandonment by 22% — the extra click interrupts intent. Expose the input field on desktop.
The input field width should accommodate the expected query length:
Recommended minimum width:
27 characters (fits "running shoes for women size 10")
Narrower fields cause users to shorten their queries to fit the visual box
Recommended default for desktop: 300–400px (≈ 30–40 characters)
Expand on focus if space-constrained — input grows to 400px when user clicks
Placeholder text:
✅ Shows what can be searched: "Search products, brands, or categories"
❌ Generic: "Search" (adds no information)
❌ Misleading: "What are you looking for?" (conversational UX pattern — only if the UI supports it)
Autocomplete (type-ahead suggestions) reduces search time and corrects spelling:
When to use autocomplete:
Autocomplete design rules:
Show: 5–8 suggestions (more creates scroll; fewer may miss the right match)
Highlight: bold the portion of each suggestion that matches the query
Group: if suggestions span types (products, categories, articles), use headers
Trigger: after 2+ characters (1 character is too broad; shows irrelevant suggestions)
Debounce: 150–250ms (prevents API call on every keystroke)
❌ Autocomplete without highlighting: "Running Shoes for Women" — which part matched?
✅ Autocomplete with matching bolded: "**Running** Shoes for Women" — query was "running"
Recent searches: Show the last 3–5 searches when the input is focused (before typing). Users frequently repeat searches. Label the section "Recent searches" — not the same list as autocomplete suggestions.
Results must communicate what was found, how many, and allow refinement:
Result count:
✅ "1,240 results for 'running shoes'"
✅ "Showing 1–20 of 1,240 results"
❌ No count → user doesn't know if the search worked or returned nothing
Query term highlighting: Highlight the query term within each result:
Search: "machine learning"
Result: "An introduction to **machine learning** algorithms and supervised classification"
Highlighting helps users confirm the result is relevant before clicking.
Sorting and filtering:
Result layout:
A blank screen on no results is an abandonment trigger. The no-results state must:
Example no-results layout:
We couldn't find anything for "red running shoez"
Did you mean: red running shoes?
Or try:
• Browse all Running Shoes →
• View new arrivals →
• Contact support
What never to show on no-results:
Most users cannot spell product or technical terminology correctly. Search must compensate:
If building on Elasticsearch, Algolia, or Typesense: all support these features in configuration — enable them. Do not require exact-match search as the default.
For large applications with distinct content types, provide scoped search:
[🔍 Search... ] [▼ All] ← scope selector
Scopes: All | Products | Articles | Help | Orders
Scoped search reduces noise when users know which type of content they're searching for. Default scope to "All" — do not default to a narrow scope that hides content.
When scoping is NOT needed: applications with a single content type (e-commerce with only products; a blog with only articles); adding scope selector adds UI complexity without benefit.