clarify
不明瞭なUXコピーやエラーメッセージ、マイクロコピー、ラベル、説明文などを改善し、インターフェースをより理解しやすく、使いやすくすることで、ユーザー体験を向上させるSkill。
📜 元の英語説明(参考)
Improve unclear UX copy, error messages, microcopy, labels, and instructions. Makes interfaces easier to understand and use.
🇯🇵 日本人クリエイター向け解説
不明瞭なUXコピーやエラーメッセージ、マイクロコピー、ラベル、説明文などを改善し、インターフェースをより理解しやすく、使いやすくすることで、ユーザー体験を向上させるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o clarify.zip https://jpskill.com/download/19777.zip && unzip -o clarify.zip && rm clarify.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/19777.zip -OutFile "$d\clarify.zip"; Expand-Archive "$d\clarify.zip" -DestinationPath $d -Force; ri "$d\clarify.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
clarify.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
clarifyフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[Skill 名] clarify 不明瞭、紛らわしい、または不適切に書かれたインターフェーステキストを特定し、改善することで、製品をより理解しやすく、使いやすくします。
必須準備
frontend-design スキルを使用してください。これにはデザイン原則、アンチパターン、および Context Gathering Protocol が含まれています。続行する前にプロトコルに従ってください。まだデザインコンテキストが存在しない場合は、まず teach-impeccable を実行する必要があります。さらに、対象ユーザーの技術レベルと、その状況におけるユーザーの精神状態を収集してください。
現在のコピーを評価する
テキストが不明瞭または効果的でない原因を特定します。
-
明確さの問題を見つける:
- 専門用語: ユーザーが理解できない技術用語
- 曖昧さ: 複数の解釈が可能
- 受動態: 「ファイルがアップロードされました」対「ファイルをアップロードしました」
- 長さ: 長すぎる、または短すぎる
- 仮定: ユーザーが持っていない知識を仮定している
- コンテキストの欠如: ユーザーが何をすべきか、なぜすべきか分からない
- トーンの不一致: フォーマルすぎる、カジュアルすぎる、または状況に不適切
-
コンテキストを理解する:
- 対象ユーザーは誰ですか?(技術者向け?一般向け?初めてのユーザー?)
- ユーザーの精神状態はどのようなものですか?(エラー時にストレスを感じている?成功時に自信を持っている?)
- アクションは何ですか?(ユーザーに何をしてもらいたいですか?)
- 制約は何ですか?(文字数制限?スペースの制限?)
重要: 明確なコピーはユーザーの成功を助けます。不明瞭なコピーはフラストレーション、エラー、サポートチケットを生み出します。
コピー改善計画
より明確なコミュニケーションのための戦略を作成します。
- 主要なメッセージ: ユーザーが知るべき唯一のことは何ですか?
- 必要なアクション: ユーザーは次に何をすべきですか(もしあれば)?
- トーン: どのように感じさせるべきですか?(親切?謝罪?励まし?)
- 制約: 長さの制限、ブランドのトーン、ローカライズの考慮事項
重要: 優れた UX ライティングは目に見えません。ユーザーは言葉に気づくことなく、すぐに理解できるべきです。
コピーを体系的に改善する
これらの一般的な領域でテキストを洗練します。
エラーメッセージ
悪い例: "Error 403: Forbidden" 良い例: "このページを表示する権限がありません。アクセスするには管理者にお問い合わせください。"
悪い例: "Invalid input" 良い例: "メールアドレスには @ 記号が必要です。例: name@example.com"
原則:
- 何が問題だったのかを平易な言葉で説明する
- 修正方法を提案する
- ユーザーを責めない
- 役立つ場合は例を含める
- 該当する場合はヘルプ/サポートにリンクする
フォームのラベルと指示
悪い例: "DOB (MM/DD/YYYY)" 良い例: "生年月日"(形式を示すプレースホルダー付き)
悪い例: "Enter value here" 良い例: "あなたのメールアドレス" または "会社名"
原則:
- 明確で具体的なラベルを使用する(一般的なプレースホルダーではない)
- 例で形式の期待値を示す
- なぜ尋ねているのかを説明する(明らかでない場合)
- 指示はフィールドの後ではなく、前に置く
- 必須フィールドの表示を明確にする
ボタンと CTA テキスト
悪い例: "Click here" | "Submit" | "OK" 良い例: "アカウントを作成" | "変更を保存" | "了解しました、ありがとうございます"
原則:
- アクションを具体的に記述する
- 能動態を使用する(動詞 + 名詞)
- ユーザーのメンタルモデルに合わせる
- 具体的にする("Save" は "OK" よりも良い)
ヘルプテキストとツールチップ
悪い例: "This is the username field" 良い例: "ユーザー名を選択してください。これは後で設定で変更できます。"
原則:
- 価値を追加する(ラベルを繰り返すだけではない)
- 暗黙の質問に答える(「これは何ですか?」または「なぜこれが必要なのですか?」)
- 簡潔だが完全にする
- 必要に応じて詳細なドキュメントにリンクする
空の状態
悪い例: "No items" 良い例: "まだプロジェクトがありません。最初のプロジェクトを作成して開始しましょう。"
原則:
- なぜ空なのかを説明する(明らかでない場合)
- 次のアクションを明確に示す
- 行き止まりではなく、歓迎する雰囲気にする
成功メッセージ
悪い例: "Success" 良い例: "設定が保存されました!変更はすぐに反映されます。"
原則:
- 何が起こったかを確認する
- 次に何が起こるかを説明する(関連する場合)
- 簡潔だが完全にする
- ユーザーの感情的な瞬間に合わせる(大きな成功を祝う)
ロード状態
悪い例: "Loading..."(30秒以上) 良い例: "データを分析中...通常30〜60秒かかります"
原則:
- 期待値を設定する(どのくらいかかるか?)
- 何が起こっているかを説明する(明らかでない場合)
- 可能な場合は進捗状況を表示する
- 適切な場合はエスケープハッチを提供する(「キャンセル」)
確認ダイアログ
悪い例: "Are you sure?" 良い例: "「Project Alpha」を削除しますか?これは元に戻せません。"
原則:
- 具体的なアクションを述べる
- 結果を説明する(特に破壊的なアクションの場合)
- 明確なボタンラベルを使用する("Yes" ではなく "プロジェクトを削除")
- 確認を使いすぎない(リスクのあるアクションのみ)
ナビゲーションと経路案内
悪い例: "Items" | "Things" | "Stuff" のような一般的なラベル 良い例: "あなたのプロジェクト" | "チームメンバー" | "設定" のような具体的なラベル
原則:
- 具体的で説明的であること
- ユーザーが理解できる言葉を使用する(内部の専門用語ではない)
- 階層を明確にする
- 情報の手がかりを考慮する(パンくずリスト、現在の場所)
明確さの原則を適用する
すべてのコピーは以下のルールに従うべきです。
- 具体的にする: "Enter value" ではなく "Enter email"
- 簡潔にする: 不要な言葉を削除する(ただし明確さを犠牲にしない)
- 能動的にする: "Changes will be saved" ではなく "Save changes"
- 人間的にする: "System error encountered" ではなく "Oops, something went wrong"
- 役立つようにする: 何が起こったかだけでなく、ユーザーに何をすべきかを伝える
- 一貫性を持たせる: 同じ用語を全体を通して使用する(多様性のために変えない)
決してしてはいけないこと:
- 説明なしに専門用語を使用する
- ユーザーを責める("You made an error" → "このフィールドは必須です")
- 曖昧にする(説明なしに "Something went wrong")
- 不必要に受動態を使用する
- 長すぎる説明を書く(簡潔にする)
- エラーにユーモアを使用する(代わりに共感する)
- 技術的な知識を仮定する
- 用語を変える(1つの用語を選び、それに固執する)
- 情報を繰り返す(イントロを繰り返す見出し、冗長な説明)
- プレースホルダーを唯一のラベルとして使用する(ユーザーが入力すると消えるため)
改善点の検証
コピーの改善が機能するかどうかをテストします。
- 理解度: ユーザーは理解できますか?
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
MANDATORY PREPARATION
Use the frontend-design skill — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run teach-impeccable first. Additionally gather: audience technical level and users' mental state in context.
Assess Current Copy
Identify what makes the text unclear or ineffective:
-
Find clarity problems:
- Jargon: Technical terms users won't understand
- Ambiguity: Multiple interpretations possible
- Passive voice: "Your file has been uploaded" vs "We uploaded your file"
- Length: Too wordy or too terse
- Assumptions: Assuming user knowledge they don't have
- Missing context: Users don't know what to do or why
- Tone mismatch: Too formal, too casual, or inappropriate for situation
-
Understand the context:
- Who's the audience? (Technical? General? First-time users?)
- What's the user's mental state? (Stressed during error? Confident during success?)
- What's the action? (What do we want users to do?)
- What's the constraint? (Character limits? Space limitations?)
CRITICAL: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
Plan Copy Improvements
Create a strategy for clearer communication:
- Primary message: What's the ONE thing users need to know?
- Action needed: What should users do next (if anything)?
- Tone: How should this feel? (Helpful? Apologetic? Encouraging?)
- Constraints: Length limits, brand voice, localization considerations
IMPORTANT: Good UX writing is invisible. Users should understand immediately without noticing the words.
Improve Copy Systematically
Refine text across these common areas:
Error Messages
Bad: "Error 403: Forbidden" Good: "You don't have permission to view this page. Contact your admin for access."
Bad: "Invalid input" Good: "Email addresses need an @ symbol. Try: name@example.com"
Principles:
- Explain what went wrong in plain language
- Suggest how to fix it
- Don't blame the user
- Include examples when helpful
- Link to help/support if applicable
Form Labels & Instructions
Bad: "DOB (MM/DD/YYYY)" Good: "Date of birth" (with placeholder showing format)
Bad: "Enter value here" Good: "Your email address" or "Company name"
Principles:
- Use clear, specific labels (not generic placeholders)
- Show format expectations with examples
- Explain why you're asking (when not obvious)
- Put instructions before the field, not after
- Keep required field indicators clear
Button & CTA Text
Bad: "Click here" | "Submit" | "OK" Good: "Create account" | "Save changes" | "Got it, thanks"
Principles:
- Describe the action specifically
- Use active voice (verb + noun)
- Match user's mental model
- Be specific ("Save" is better than "OK")
Help Text & Tooltips
Bad: "This is the username field" Good: "Choose a username. You can change this later in Settings."
Principles:
- Add value (don't just repeat the label)
- Answer the implicit question ("What is this?" or "Why do you need this?")
- Keep it brief but complete
- Link to detailed docs if needed
Empty States
Bad: "No items" Good: "No projects yet. Create your first project to get started."
Principles:
- Explain why it's empty (if not obvious)
- Show next action clearly
- Make it welcoming, not dead-end
Success Messages
Bad: "Success" Good: "Settings saved! Your changes will take effect immediately."
Principles:
- Confirm what happened
- Explain what happens next (if relevant)
- Be brief but complete
- Match the user's emotional moment (celebrate big wins)
Loading States
Bad: "Loading..." (for 30+ seconds) Good: "Analyzing your data... this usually takes 30-60 seconds"
Principles:
- Set expectations (how long?)
- Explain what's happening (when it's not obvious)
- Show progress when possible
- Offer escape hatch if appropriate ("Cancel")
Confirmation Dialogs
Bad: "Are you sure?" Good: "Delete 'Project Alpha'? This can't be undone."
Principles:
- State the specific action
- Explain consequences (especially for destructive actions)
- Use clear button labels ("Delete project" not "Yes")
- Don't overuse confirmations (only for risky actions)
Navigation & Wayfinding
Bad: Generic labels like "Items" | "Things" | "Stuff" Good: Specific labels like "Your projects" | "Team members" | "Settings"
Principles:
- Be specific and descriptive
- Use language users understand (not internal jargon)
- Make hierarchy clear
- Consider information scent (breadcrumbs, current location)
Apply Clarity Principles
Every piece of copy should follow these rules:
- Be specific: "Enter email" not "Enter value"
- Be concise: Cut unnecessary words (but don't sacrifice clarity)
- Be active: "Save changes" not "Changes will be saved"
- Be human: "Oops, something went wrong" not "System error encountered"
- Be helpful: Tell users what to do, not just what happened
- Be consistent: Use same terms throughout (don't vary for variety)
NEVER:
- Use jargon without explanation
- Blame users ("You made an error" → "This field is required")
- Be vague ("Something went wrong" without explanation)
- Use passive voice unnecessarily
- Write overly long explanations (be concise)
- Use humor for errors (be empathetic instead)
- Assume technical knowledge
- Vary terminology (pick one term and stick with it)
- Repeat information (headers restating intros, redundant explanations)
- Use placeholders as the only labels (they disappear when users type)
Verify Improvements
Test that copy improvements work:
- Comprehension: Can users understand without context?
- Actionability: Do users know what to do next?
- Brevity: Is it as short as possible while remaining clear?
- Consistency: Does it match terminology elsewhere?
- Tone: Is it appropriate for the situation?
Remember: You're a clarity expert with excellent communication skills. Write like you're explaining to a smart friend who's unfamiliar with the product. Be clear, be helpful, be human.