jpskill.com
💬 コミュニケーション コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して clarify.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → clarify フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] clarify 不明瞭、紛らわしい、または不適切に書かれたインターフェーステキストを特定し、改善することで、製品をより理解しやすく、使いやすくします。

必須準備

frontend-design スキルを使用してください。これにはデザイン原則、アンチパターン、および Context Gathering Protocol が含まれています。続行する前にプロトコルに従ってください。まだデザインコンテキストが存在しない場合は、まず teach-impeccable を実行する必要があります。さらに、対象ユーザーの技術レベルと、その状況におけるユーザーの精神状態を収集してください。


現在のコピーを評価する

テキストが不明瞭または効果的でない原因を特定します。

  1. 明確さの問題を見つける:

    • 専門用語: ユーザーが理解できない技術用語
    • 曖昧さ: 複数の解釈が可能
    • 受動態: 「ファイルがアップロードされました」対「ファイルをアップロードしました」
    • 長さ: 長すぎる、または短すぎる
    • 仮定: ユーザーが持っていない知識を仮定している
    • コンテキストの欠如: ユーザーが何をすべきか、なぜすべきか分からない
    • トーンの不一致: フォーマルすぎる、カジュアルすぎる、または状況に不適切
  2. コンテキストを理解する:

    • 対象ユーザーは誰ですか?(技術者向け?一般向け?初めてのユーザー?)
    • ユーザーの精神状態はどのようなものですか?(エラー時にストレスを感じている?成功時に自信を持っている?)
    • アクションは何ですか?(ユーザーに何をしてもらいたいですか?)
    • 制約は何ですか?(文字数制限?スペースの制限?)

重要: 明確なコピーはユーザーの成功を助けます。不明瞭なコピーはフラストレーション、エラー、サポートチケットを生み出します。

コピー改善計画

より明確なコミュニケーションのための戦略を作成します。

  • 主要なメッセージ: ユーザーが知るべき唯一のことは何ですか?
  • 必要なアクション: ユーザーは次に何をすべきですか(もしあれば)?
  • トーン: どのように感じさせるべきですか?(親切?謝罪?励まし?)
  • 制約: 長さの制限、ブランドのトーン、ローカライズの考慮事項

重要: 優れた 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" のような一般的なラベル 良い例: "あなたのプロジェクト" | "チームメンバー" | "設定" のような具体的なラベル

原則:

  • 具体的で説明的であること
  • ユーザーが理解できる言葉を使用する(内部の専門用語ではない)
  • 階層を明確にする
  • 情報の手がかりを考慮する(パンくずリスト、現在の場所)

明確さの原則を適用する

すべてのコピーは以下のルールに従うべきです。

  1. 具体的にする: "Enter value" ではなく "Enter email"
  2. 簡潔にする: 不要な言葉を削除する(ただし明確さを犠牲にしない)
  3. 能動的にする: "Changes will be saved" ではなく "Save changes"
  4. 人間的にする: "System error encountered" ではなく "Oops, something went wrong"
  5. 役立つようにする: 何が起こったかだけでなく、ユーザーに何をすべきかを伝える
  6. 一貫性を持たせる: 同じ用語を全体を通して使用する(多様性のために変えない)

決してしてはいけないこと:

  • 説明なしに専門用語を使用する
  • ユーザーを責める("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:

  1. 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
  2. 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:

  1. Be specific: "Enter email" not "Enter value"
  2. Be concise: Cut unnecessary words (but don't sacrifice clarity)
  3. Be active: "Save changes" not "Changes will be saved"
  4. Be human: "Oops, something went wrong" not "System error encountered"
  5. Be helpful: Tell users what to do, not just what happened
  6. 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.