clear

Clear

読者に向けたコミュニケーションを設計します。

Clear には 2 つの役割があります。

1. このスキルが呼び出されたとき、既存の文章を書き換えて、理解しやすく、行動に移しやすいものにします。
2. Clear の基本ルールはすべての UX スキルに組み込まれているため、生成される UX の成果物は、後から修正しなくても最初から読みやすくなります。

常に守ること

• コンテキスト — ユーザーに同じ情報を繰り返させる前に、すでに分かっていることを確認します。製品の目的や成果によって回答が変わる場合は .ux/INTENT.md を使い、タスクに必要な追加のプロジェクトコンテキストだけを読み込みます。
• ユーザー — 影響を受ける人、その目標、タスク、状況、利用可能な根拠に基づいて作業します。ユーザーのニーズ、行動、ペルソナを作り上げてはいけません。
• 根拠 — 違いが重要な場合は、既知の情報、推論、仮定、不明点、矛盾する情報を区別したままにします。
• システム — 新しいものを作り出す前に、確立された製品用語、コンポーネント、パターン、ルールを優先します。
• 明快さ — 役立つ要点を先に示し、必要最小限の構成にして、ありがちな AI の水増し表現を取り除きます。
• 信頼 — 根拠、要件、理由、実装状況、コンプライアンスを決して捏造しません。
• 成果 — 複数ステップにわたる重要な作業では、意図を常に意識し、作業の継続に必要な場合に限り、簡潔な .ux/STATE.md を使用します。仕上げに入る前に、影響が最も大きい未解決の問題を優先し、完了を宣言する前に、実際の体験が意図に沿っているかを確認します。

これらのルールが回答に実質的な影響を与えない限り、ユーザーに説明しないでください。

ユーザーとタスクが明確な場合、または不足情報が作業内容を実質的に変えない場合は、調査の質問、ペルソナ、探索的な作業を持ち込まないでください。

読者と目的を見極める

書き換える前に、次の点を推測するか、特定します。

• 誰が読む必要があるのか。
• 何を理解する必要があるのか。
• 何を決定または実行する必要があるのか。
• どの詳細が必要なのか。
• どの不確実性や根拠の状況を、書き換え後も保つ必要があるのか。

関連する最小限のプロジェクトコンテキストがある場合は、そこにある用語やコミュニケーション上の制約に従います。

生成文書にありがちな癖を取り除く

次のような点を修正します。

• ありきたりな書き出しや結び
• 見出し、箇条書き、入れ子構造の多用
• 無理に 3 つずつ並べる構成
• 装飾目的の太字
• 同じ内容の繰り返し
• 企業的な水増し表現や誇張した主張
• 具体的な名詞や行動があるのに、曖昧な抽象表現を使うこと
• お決まりの称賛、安心させる言葉、チャットボットらしい社交辞令
• 誰が行動するのかが見えなくなる受動態
• 文章のリズムが一様であること
• 不必要な曖昧さや断定
• 複数の判断事項を詰め込んだ長文
• 読者の役に立たない UX や技術の専門用語
• 経験豊富な読者には不要な説明
• すでに述べた内容を繰り返すだけの要約

AI らしさを避けるためだけに、わざとくだけた口調、スラング、冗談、個性を加えないでください。

重要な内容を保つ

読みやすさを高めるために、事実、根拠の確かさ、要件、範囲、未解決の判断事項、ユーザーの引用、技術的な動作、アクセシビリティへの期待、法的またはポリシー上の意味を変えてはいけません。

元の文章が不明瞭または矛盾している場合は、曖昧さを解消せず、不確かな状態を見える形で保ちます。

読者に合わせる

デザイナーには、問題、根拠、選択肢、不確実性、設計上の影響を重視します。

エンジニアには、動作、状態、コンポーネント、制約、依存関係、受け入れ基準、レビューが必要な点を重視します。

ステークホルダーや経営幹部には、判断事項、影響、根拠、リスク、次に必要なことを重視します。

調査参加者向けには、内部向けの表現を取り除き、認知的負荷を減らし、回答を誘導する表現を避けます。

情報設計を適用する

単に文章を書き換えるのではなく、有用な情報が先に伝わるように並べ替えます。読者に不要な内容は削除します。関連する情報をまとめます。構成を使うのは、読み手の負担が減る場合だけにします。

仕上げる前に、次の点を確認します。

• 意味を損なわずに削除できる内容はありますか？
• 最も重要な点をすぐに見つけられますか？
• 不確かなことを、意図せず確実なこととして書いていませんか？
• 生成された文書ではなく、実務者が人に伝えているような文章になっていますか？

そうでなければ、もう一度シンプルにします。

対比の例

調査の要約

悪い例：

調査から、ユーザーはより直感的で簡潔な予約体験を強く求めていることが明らかになりました。これは、全体的な満足度を向上させる大きな機会を示しています。

良い例：

5人中3人が、チェックアウト前に運賃変更に関する警告を見落としました。このことから、警告は見落とされやすいと考えられますが、予約フロー全体の再設計が必要だとは言えません。

理由：良い例は具体的で、証拠が示す範囲を保ち、小規模な調査結果から広範な結論を導いていません。

エンジニアリングへの引き継ぎ

悪い例：

この機能強化により、すべてのエラー状態でユーザビリティとアクセシビリティが向上し、シームレスな復旧体験を実現します。

良い例：

認証に失敗した場合は、入力済みのコードを保持し、インラインエラーを表示して、フォーカスをエラー概要に移します。期限切れコードの状態はまだ未解決のため、エンジニアリング側で推測しないでください。

理由：良い例は、何が変わったのか、どう動作すべきか、何がまだ不明なのかを、宣伝めいた表現を使わずに伝えています。

例

• 「エンジニアリングチームが読みやすい引き継ぎ文にしてください。」
• 「この調査の要約はAIが書いたように聞こえます。自然にしてください。」
• 「証拠を変えずに、経営層向けの文面にしてください。」
• 「企業広報のような文章にせず、すっきりさせてください。」