mcpField
C
clarify

clarify

github.com/shipshitdevデザイン・UI3884 回インストール今日更新
リポジトリ

clarify について

clarifyは、デザイナーやプロダクトチーム向けのUIコピー編集スキルです。明瞭さ、事実性、アクセシビリティ、フロー全体での用語の一貫性を確認します。

主な機能

  1. 01フロー全体を踏まえたUI文言の監査
  2. 02メッセージの情報階層の整理
  3. 03操作・フォーム・エラー文言の改善
  4. 04読み込み・空・成功状態の確認
  5. 05アクセシビリティとローカライズへの配慮
  6. 06実際のレイアウトでの文言検証

活用シーン

  1. 01曖昧なUIラベルの明確化
  2. 02エラーからの復旧案内の改善
  3. 03ユーザーフロー全体の文言確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shipshitdev/skills --skill clarify

インストール後、Claude Code で/clarifyを入力して読み込まれたか確認します。

同梱ファイルplugin.jsonREADME.md

詳細

Clarify

許可された対象範囲内でのみ、コピーの編集を行います。

わかりにくいインターフェースの文言を書き直し、何が起きたのか、何が重要なのか、次に何をすればよいのかをユーザーが理解できるようにします。事実としての意味、製品用語、ブランドの語調を維持します。

文言を監査する

文字列を個別に見るのではなく、やり取りの流れ全体を確認します。次の点を特定します。

  • あいまいな名詞、動詞、操作;
  • 社内用語や、ユーザーが知っていることを前提とした表現;
  • あいまいなラベル、結果、システムの状態;
  • 影響、復旧方法、所要時間に関する情報の不足;
  • 用語や大文字・小文字の表記ゆれ;
  • 重複する見出し、導入文、補足説明、確認メッセージ;
  • 現実的な表示幅や翻訳で問題が生じる文言;
  • ストレス、リスク、成功、緊急性を考慮していない語調。

製品のコンテキストと周囲のUIから、対象ユーザーとタスクを推測します。事実に関する主張、法的な意味、またはドメイン固有の可能性がある用語を変更する前に、確認してください。

メッセージの優先順位を決める

各状態について、次の点を決めます。

  1. ユーザーが今知る必要のある最も重要な事実;
  2. 次に実行できる操作;
  3. 判断に影響する補足情報;
  4. この状況に適した語調。

それぞれの要点は一度だけ伝えます。見出しですでに状態を説明している場合、導入文には新しい情報を加えるか、導入文を省きます。

機能に応じて書き直す

操作とナビゲーション

結果が明らかでない場合は、具体的な動詞と目的語を使います。ラベルには、実行のきっかけとなる操作ではなく、何が起きるかを示します。製品全体を通して、同じ概念には同じ名詞と動詞を使います。

破壊的な操作では、対象と結果を明示します。安全に取り消せる場合は、確認よりも取り消しを優先します。確認が必要な場合は、Yes、No、OK、Submit を使わず、メッセージとボタンの両方に操作名を明記します。

フォーム

常に表示されるラベルを使います。プレースホルダーは入力例であり、ラベルの代わりにはなりません。形式や利用条件の要件は、送信前に示します。情報を求める理由の説明は、その理由が明らかでない場合に限ります。必須項目と任意項目の扱いに一貫性を持たせます。

バリデーションでは、ユーザーを責めずに、対応が必要な箇所と修正方法を伝えます。関連する説明は入力欄の近くに置き、エラーはアクセシブルな方法で通知します。

エラーと権限

対応可能なエラーメッセージでは、次の点を伝えます。

  1. 何に失敗したのか;
  2. 有用で、原因が判明している場合はその理由;
  3. 復旧方法、または残されている代替手段。

内部コードを主要なメッセージとして表示しないでください。システムが判断できない原因や解決を約束しないでください。プライバシー、支払い、削除、アクセスの喪失、作業の阻害には真摯に対応します。親しみやすさは歓迎されますが、冗談は避けてください。

読み込み中、空の状態、成功の状態

読み込み中の文言では、実際に行っている処理を示し、待ち時間が重要な場合は誠実な見通しを伝えます。確定的な進捗を表示できる場合は表示します。進捗を捏造してはいけません。

空の状態では、初回利用、検索結果なし、フィルター、権限、失敗を区別します。状態を説明し、次に役立つ操作を提示します。

成功メッセージでは完了した結果を確認し、ユーザーの次の行動に影響する場合に限って、その後の結果を伝えます。通常の成功メッセージは簡潔にします。

ヘルプと操作説明

補足説明では、コントロールの説明を繰り返すのではなく、暗黙の疑問に答えます。まれにしか必要とされない詳細には、段階的な開示を使います。リンクテキストは、文脈を離れても意味が通じるようにします。アイコンのみのコントロールには、アクセシブルな名前を付けます。

語調、アクセシビリティ、ローカライズ

語調には一貫性を持たせ、状況に応じて調整します。対象ユーザーが本当に理解している用語を平易な表現に置き換えず、わかりやすい言葉を使います。

  • 連結された断片ではなく、翻訳可能な完全なメッセージを書きます。
  • 翻訳者が順序を入れ替えられるように、変数と数値を適切に構造化します。
  • 早まって省略せず、文言が長くなる余地を確保します。
  • 代替テキストでは画像の情報を伝え、装飾目的の画像には空の代替テキストを使います。
  • スクリーンリーダー向けの名前を、表示ラベルとその結果に一致させます。
  • 句読点、色、アイコンだけでメッセージを伝えないようにします。

製品全体で用語の不一致が見られる場合は、簡潔な用語集を作成します。インターフェースでは、文学的な効果を狙って言葉を使い分けないでください。

検証

フローを文脈に沿って読み、以下をテストします。

  • プロダクトに関する隠れた知識がなくても理解できること。
  • エラー、空の状態、判断が必要な場面で、次の行動が明確であること。
  • 事実が正確で、用語が一貫していること。
  • 対象の画面幅や200%のズームでも読みやすいこと。
  • 長い名前、ローカライズによる文字数の増加、複数形、動的な値に対応していること。
  • アクセシブルネームや、通知される状態の変化が適切であること。
  • 影響や感情的な文脈に適したトーンであること。

最終的な文言は、意味や復旧手段を損なわない範囲でできるだけ短くします。

最終調整には、利用可能な polish スキルの使用を推奨します。

コメント