clarify について
clarifyは、デザイナーやプロダクトチーム向けのUIコピー編集スキルです。明瞭さ、事実性、アクセシビリティ、フロー全体での用語の一貫性を確認します。
主な機能
- 01フロー全体を踏まえたUI文言の監査
- 02メッセージの情報階層の整理
- 03操作・フォーム・エラー文言の改善
- 04読み込み・空・成功状態の確認
- 05アクセシビリティとローカライズへの配慮
- 06実際のレイアウトでの文言検証
活用シーン
- 01曖昧なUIラベルの明確化
- 02エラーからの復旧案内の改善
- 03ユーザーフロー全体の文言確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ shipshitdev/ skills --skill clarifyインストール後、Claude Code で/clarifyを入力して読み込まれたか確認します。
同梱ファイルplugin.jsonREADME.md
詳細
Clarify
許可された対象範囲内でのみ、コピーの編集を行います。
わかりにくいインターフェースの文言を書き直し、何が起きたのか、何が重要なのか、次に何をすればよいのかをユーザーが理解できるようにします。事実としての意味、製品用語、ブランドの語調を維持します。
文言を監査する
文字列を個別に見るのではなく、やり取りの流れ全体を確認します。次の点を特定します。
- あいまいな名詞、動詞、操作;
- 社内用語や、ユーザーが知っていることを前提とした表現;
- あいまいなラベル、結果、システムの状態;
- 影響、復旧方法、所要時間に関する情報の不足;
- 用語や大文字・小文字の表記ゆれ;
- 重複する見出し、導入文、補足説明、確認メッセージ;
- 現実的な表示幅や翻訳で問題が生じる文言;
- ストレス、リスク、成功、緊急性を考慮していない語調。
製品のコンテキストと周囲のUIから、対象ユーザーとタスクを推測します。事実に関する主張、法的な意味、またはドメイン固有の可能性がある用語を変更する前に、確認してください。
メッセージの優先順位を決める
各状態について、次の点を決めます。
- ユーザーが今知る必要のある最も重要な事実;
- 次に実行できる操作;
- 判断に影響する補足情報;
- この状況に適した語調。
それぞれの要点は一度だけ伝えます。見出しですでに状態を説明している場合、導入文には新しい情報を加えるか、導入文を省きます。
機能に応じて書き直す
操作とナビゲーション
結果が明らかでない場合は、具体的な動詞と目的語を使います。ラベルには、実行のきっかけとなる操作ではなく、何が起きるかを示します。製品全体を通して、同じ概念には同じ名詞と動詞を使います。
破壊的な操作では、対象と結果を明示します。安全に取り消せる場合は、確認よりも取り消しを優先します。確認が必要な場合は、Yes、No、OK、Submit を使わず、メッセージとボタンの両方に操作名を明記します。
フォーム
常に表示されるラベルを使います。プレースホルダーは入力例であり、ラベルの代わりにはなりません。形式や利用条件の要件は、送信前に示します。情報を求める理由の説明は、その理由が明らかでない場合に限ります。必須項目と任意項目の扱いに一貫性を持たせます。
バリデーションでは、ユーザーを責めずに、対応が必要な箇所と修正方法を伝えます。関連する説明は入力欄の近くに置き、エラーはアクセシブルな方法で通知します。
エラーと権限
対応可能なエラーメッセージでは、次の点を伝えます。
- 何に失敗したのか;
- 有用で、原因が判明している場合はその理由;
- 復旧方法、または残されている代替手段。
内部コードを主要なメッセージとして表示しないでください。システムが判断できない原因や解決を約束しないでください。プライバシー、支払い、削除、アクセスの喪失、作業の阻害には真摯に対応します。親しみやすさは歓迎されますが、冗談は避けてください。
読み込み中、空の状態、成功の状態
読み込み中の文言では、実際に行っている処理を示し、待ち時間が重要な場合は誠実な見通しを伝えます。確定的な進捗を表示できる場合は表示します。進捗を捏造してはいけません。
空の状態では、初回利用、検索結果なし、フィルター、権限、失敗を区別します。状態を説明し、次に役立つ操作を提示します。
成功メッセージでは完了した結果を確認し、ユーザーの次の行動に影響する場合に限って、その後の結果を伝えます。通常の成功メッセージは簡潔にします。
ヘルプと操作説明
補足説明では、コントロールの説明を繰り返すのではなく、暗黙の疑問に答えます。まれにしか必要とされない詳細には、段階的な開示を使います。リンクテキストは、文脈を離れても意味が通じるようにします。アイコンのみのコントロールには、アクセシブルな名前を付けます。
語調、アクセシビリティ、ローカライズ
語調には一貫性を持たせ、状況に応じて調整します。対象ユーザーが本当に理解している用語を平易な表現に置き換えず、わかりやすい言葉を使います。
- 連結された断片ではなく、翻訳可能な完全なメッセージを書きます。
- 翻訳者が順序を入れ替えられるように、変数と数値を適切に構造化します。
- 早まって省略せず、文言が長くなる余地を確保します。
- 代替テキストでは画像の情報を伝え、装飾目的の画像には空の代替テキストを使います。
- スクリーンリーダー向けの名前を、表示ラベルとその結果に一致させます。
- 句読点、色、アイコンだけでメッセージを伝えないようにします。
製品全体で用語の不一致が見られる場合は、簡潔な用語集を作成します。インターフェースでは、文学的な効果を狙って言葉を使い分けないでください。
検証
フローを文脈に沿って読み、以下をテストします。
- プロダクトに関する隠れた知識がなくても理解できること。
- エラー、空の状態、判断が必要な場面で、次の行動が明確であること。
- 事実が正確で、用語が一貫していること。
- 対象の画面幅や200%のズームでも読みやすいこと。
- 長い名前、ローカライズによる文字数の増加、複数形、動的な値に対応していること。
- アクセシブルネームや、通知される状態の変化が適切であること。
- 影響や感情的な文脈に適したトーンであること。
最終的な文言は、意味や復旧手段を損なわない範囲でできるだけ短くします。
最終調整には、利用可能な polish スキルの使用を推奨します。