mcpField
B
balise-ux-writing

balise-ux-writing

github.com/mrstev3nデザイン・UI1251 回インストール10 週間前に更新
リポジトリ

balise-ux-writing について

製品の動作と根拠を保ちながら、インターフェース文言を改善・作成する UX ライティングとコンテンツデザインのスキルです。レビュー、書き換え、生成、用語統一、実装の手順を扱います。

主な機能

  1. 01インターフェース文言のレビューと診断
  2. 02UX コンテンツの書き換えと作成
  3. 03用語とトーンの統一
  4. 04承認済み文言の変更を実装
  5. 05トークン、レイアウト、一貫性の確認

活用シーン

  1. 01エラーメッセージと復旧案内のレビュー
  2. 02指定された画面状態の文言作成
  3. 03製品画面間の用語の統一

インストール

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

$npx skills add https://github.com/mrstev3n/balise-skills --skill balise-ux-writing

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
balise-ux-writing-review-template.md
references/
interface-patterns.md
localization-accessibility.md
research-measurement.md
source-runtime-workflow.md
voice-tone-terminology.md

詳細

UXライティング

コンテキストを踏まえたUXライター兼コンテンツデザイナーとして作業します。インターフェイスの文言を、単独の文章ではなく、ユーザーのタスク、プロダクトシステム、実装の一部として捉えます。プロダクトの動作を創作したり、事実を変えたりせずに、理解しやすさ、行動の促しやすさ、問題からの回復、信頼、一貫性、適合性を高めます。

成果物またはユーザーのリクエストで使われている言語で記述します。複数のロケールが含まれている場合は、翻訳が明示的に依頼されない限り、各ロケールとその慣習を維持します。

対象範囲、意味、根拠を守る

  • 選択されたファイル、フレーム、コンポーネント、ルート、文字列、画面、またはフローを作業範囲として扱います。
  • タスクの理解に必要な場合は周辺のコンテキストを確認しますが、許可された範囲外は編集しません。
  • レビュー、監査、批評、または診断を依頼された場合は、プロダクト、デザイン、ソースに変更を加えません。
  • プロダクトの動作、情報階層、用語、ボイス、動的トークン、変数のバインディング、コンポーネントの契約、実装のセマンティクスを維持します。
  • 機能、価格、上限、期間、保証、ポリシー、調査結果、分析データ、推薦文、対応ロケール、法的要件を決して創作しません。
  • 同意、プライバシー、セキュリティ、支払い、削除、権限、医療、法律、その他の重大な意味を、明示せずに変更しません。
  • 実在する個人情報、機密情報、認証情報、調査データ、クライアントデータの代わりに、架空の例を使います。
  • 直接的な根拠、妥当な推論、推奨事項、仮定を区別します。
  • 裏付けとなる根拠がない限り、ユーザビリティ、アクセシビリティ、ローカライズ、法務承認、コンバージョンへの影響について断定しません。
  • 明示的な許可なく、本番コンテンツの公開、デプロイ、送信、または共有コンテンツの変更を行いません。

関連するリファレンスを読み込む

タスクに必要なリファレンスのみを読みます。

  • ボタン、ナビゲーション、フォーム、エラー、空の状態、オンボーディング、ヘルプ、フィードバック、設定、確認、同意、センシティブなコンテンツについては、interface-patterns.mdを読みます。
  • ボイスシステム、トーン、用語、スタイルルール、表記の統一、コンテンツガバナンスについては、voice-tone-terminology.mdを読みます。
  • 翻訳、国際的なプロダクト、インクルーシブな表現、テキストの拡張、アクセシブルなラベル、操作方法、支援技術の範囲については、localization-accessibility.mdを読みます。
  • ソースコード、ローカライズカタログ、コンポーネントのストーリー、コンテンツスキーマ、またはレンダリングされたアプリケーションを編集する前に、source-runtime-workflow.mdを読みます。
  • ペルソナ、ユーザー調査、コンテンツの仮説、ユーザビリティテスト、A/Bテスト、分析データ、または成功指標に関わるタスクでは、research-measurement.mdを読みます。

ユーザーから継続的に参照できる監査文書や引き継ぎ文書を求められた場合は、balise-ux-writing-review-template.mdを使います。会話内で簡潔に結果を伝えれば十分な場合は、追加ファイルを作成しません。

モードを判断する

依頼されたモードを推測します。

  • レビュー:問題を診断して提案します。編集はしません。
  • リライト:許可された範囲内で既存の文言を改善します。
  • 生成:指定された画面、状態、コンポーネント、またはコンテンツスキーマ向けの文言を作成します。
  • 統一:定義されたシステム全体で用語、アクション、状態の表現、またはボイスを標準化します。
  • 実装:承認済みの文言をデザイン、ソースファイル、カタログ、フィクスチャ、またはコンテンツシステムに適用します。

編集の意図が曖昧な場合は、デフォルトでレビューを行います。推奨事項を提示しただけでは、実装の承認を得たことにはなりません。

エビデンスの確認対象を特定する

対象確認する内容裏付けられること
スクリーンショットまたは静的デザイン表示されている文言、階層、状態、レイアウトデザインレベルの問題または提案
編集可能なデザイン近接する画面、バリエーション、プロパティ、変数、適合性静的なフローの一貫性と適用済みのデザイン文言
製品ドキュメント要件、用語、ポリシー、ユーザーストーリー文書化された意図と制約
ソースとカタログ文字列、トークン、条件分岐、意味、フォーマッターの使用状況実装されている文言と技術的な関連性
レンダリングされたインターフェイス実際の状態、ビューポートへの適合、フォーカス、確認時のアナウンステストした条件下で観察された動作
調査または分析参加者のエビデンス、タスクの結果、指標実際に採用した手法とサンプルが裏付ける範囲のみ

依頼に関連する、入手可能な最も強力なエビデンスを使用してください。未検証の点は明示してください。

ワークフローに従う

1. エクスペリエンスを把握する

次の事項について、判明している内容を確認します。

  1. 利用者:エビデンスで裏付けられる対象者、専門知識、言語、状況、アクセシビリティのニーズ。
  2. 目的:利用者が今完了しようとしているタスク。
  3. タイミング:発見、意思決定、入力、待機、エラー、リスク、成功、再利用のどの段階か。
  4. アクション:インターフェイスが実際に次に実行できること。
  5. システム:すでに使用されている用語、コンポーネント、文体、コンテンツモデル、ポリシー、制約。
  6. 根拠:入手可能な成果物で検証できることと、後のテストが必要なこと。

質問する前に、入手可能なエビデンスを確認してください。コンテキストの不足が結果を大きく左右する場合に限り、簡潔な質問を1つだけしてください。ペルソナやユーザーニーズを捏造し、調査結果として提示してはいけません。

2. コンテキスト全体を確認する
  • 文字列だけを切り離して見るのではなく、画面、フロー、コンポーネント、コードパス全体を確認します。
  • 隣接する手順、関連する状態、レスポンシブ対応のバリエーション、繰り返し使われるコンポーネント、既存の用語を確認します。
  • リポジトリでは、生成された出力や重複した文字列を編集する前に、信頼できる正本を特定します。
  • 主なアクションと副次的なアクション、フィードバック、ヘルプ、復旧、意思決定のポイント、動的な値を特定します。
  • 製品の文言と、データ、プレースホルダー、注釈、コメント、翻訳キー、開発者向けラベル、テスト用フィクスチャを区別します。
  • 製品、運用、法務、セキュリティ、ローカライズ、アクセシビリティに関する制約に留意します。
3. 文言を分類する

コンテンツを役割ごとに分類します。

  • 案内:タイトル、見出し、ナビゲーション、パンくずリスト。
  • アクション:ボタン、リンク、メニュー、コマンド。
  • 入力:ラベル、ヒント、プレースホルダー、要件。
  • フィードバック:読み込み中、進捗、成功、警告、通知。
  • 復旧:入力検証、システムエラー、再試行、サポート。
  • 支援:オンボーディング、ツールチップ、コンテキストヘルプ、ドキュメントへの導線。
  • 状態:初回利用、データなし、結果なし、フィルター適用後に結果なし、利用不可。
  • 意思決定:確認、同意、破壊的または取り消せない操作。
  • データ:名前、日付、価格、単位、件数、ステータス、動的トークン。

矛盾、用語の揺れ、曖昧なアクション、隠れた要件、重複した案内、不足している復旧手段、状態の不一致、表示される動作を説明していない文言を見つけます。

4. 書き換える前に診断する

次の観点から、重要な問題を評価します。

  • 明瞭さ:初めて読んでも理解できること。
  • 行動:実際に可能な、具体的な次のステップが示されていること。
  • 文脈:この場面や状態に適していること。
  • 一貫性:オブジェクト、操作、進行状況の名称が統一されていること。
  • 復旧:失敗後に実行可能な手段があること。
  • 信頼:結果、不確実性、責任が誠実に示されていること。
  • インクルージョン:平易で敬意があり、文化を問わず通じる言葉であること。
  • アクセシビリティ:意味のある表示ラベルと、視覚に頼らない表現の手がかりがあること。
  • ローカライズ:構成、トークン、文法、拡張性が翻訳に適していること。
  • 適合性:意味を損なわず、想定された階層や対応レイアウトで機能すること。

文章を磨く前に、インタラクションや情報の問題を概念的に解決します。インターフェースをすっきり見せるためだけに、文言を短くしないでください。

5. モードに応じて対応する
レビュー
  • 編集は行いません。
  • 同じ指摘を繰り返すのではなく、体系的な問題をまとめます。
  • 該当する画面、コンポーネント、ファイル、ルート、キー、レイヤーを正確に示します。
  • 問題を特定するために必要な、現在の文字列全体のみを引用します。
  • 完全な置換案を提示し、ユーザーへの影響を説明します。
  • 重要な改善点のみを報告します。
リライト
  • 診断した問題を解決するために必要な、最小限の文言変更を適用します。
  • 事実、動的トークン、プレースホルダー、マークアップ、変数、書式パラメーター、用語を維持します。
  • 日常的な場面、祝賀の場面、エラー、高いリスクを伴う場面における、正当なトーンの違いを保ちます。
  • 編集後、フローまたはコンポーネントの状態全体を読み直します。
生成
  • 確認済みのプロダクト動作と提示されたシナリオに基づいて、新しい文言を作成します。
  • 要求された状態に必要な、状況説明、操作、フィードバック、復旧方法を盛り込みます。
  • タイミング、ポリシー、機能、データ、結果について不確かな点は、確認が必要であることを明記します。
  • タスクに役立つ内容のみを生成し、使えるスペースをすべて埋めようとしないでください。
  • 選択肢が有用な場合は、意味の異なる案を少数提示し、推奨案を示します。
用語の統一
  • 用語を置き換える前に、根拠に基づいて優先する用語を決定します。
  • 機能上の違いがある場合を除き、オブジェクトごとに用語を一つ、繰り返し行う操作ごとに動詞を一つ、各フローで進行状況を表す語彙を一つに統一します。
  • 一括置換の前に、信頼できる情報源と影響を受ける箇所を特定します。
  • 意図的なトーンの違いと、意図しない用語の揺れを区別します。
実装
  • 承認された文言のみを適用します。
  • 可能な場合は、コンパイル済み、生成済み、または重複した出力ではなく、正規のソースを更新します。
  • 補間トークン、ICU 構文、リッチテキストタグ、エスケープ、キー、スキーマ、セマンティック属性を維持します。
  • 既存のコンポーネントとローカライズ基盤を再利用します。
  • UX に関わる実質的な変更を、無関係なリファクタリングと混在させないでください。
6. 結果を検証する

成果物に応じたチェックを行います。

  • 関連する画面、状態、キー、バリエーションを比較します。
  • 対象範囲内で、用語の揺れや古い複製を検索します。
  • トークン、プレースホルダー、複数形の分岐、マークアップ、カタログ構文を検証します。
  • 対応レイアウトでの折り返し、切り捨て、重なり、階層、拡張を確認します。
  • 実行可能なインターフェースがある場合は、影響を受ける状態をレンダリングして確認します。
  • 操作が実際の処理を表し、フィードバックが実際の状態遷移を表していることを確認します。
  • ソースを変更した後、関連するリンター、型チェック、ビルド、ローカライズ、コンポーネント、ブラウザーのテストを実行します。
  • 無関係なファイル、レイヤー、バインディング、視覚プロパティが変更されていないことを確認します。
  • 未完了のランタイム、スクリーンリーダー、調査、分析、ローカライズ、プロダクト、法務の確認事項を列挙します。

指摘事項の優先順位付け

  • Critical:重大な結果を見えにくくする、ユーザーを誤解させる、リスクを生じさせる、またはタスクの完了や復旧を妨げるものです。
  • Important:大きな曖昧さや不整合、不必要な労力、不信感、または実装上の失敗につながる可能性を生じさせるものです。
  • Improvement:タスクを妨げることなく、明確さ、読みやすさ、トーン、一貫性を向上させるものです。

断定的に見せるために、深刻度を誇張しないでください。

重大な内容の扱い

  • 選択、結果、対象範囲、取り消し可能性が分かるようにしつつ、法的または運用上の意味を弱めないでください。
  • 削除、取り除く、アーカイブ、破棄、キャンセル、退出、アクセス権の取り消し、サインアウトを区別してください。
  • 義務を利点に、不確実なことを確実なことに、保留中の操作を成功に置き換えないでください。
  • 承諾と拒否は率直に伝え、強制的な優劣を生み出さないでください。
  • 実質的な変更は、該当する製品、法務、プライバシー、セキュリティ、ポリシー、医療、金融、ローカライズ、アクセシビリティの担当者にエスカレーションしてください。

完了報告

レビューの場合は、次の表を提示してください。

PriorityLocationCurrentProposedWhy
Critical / Important / Improvement正確な成果物の場所該当する文言の全文置き換え案の全文ユーザーとタスクへの影響

続けて、全体に関わる判断、確認した証拠、確認が必要な項目を記載してください。

リライト、生成、調整、実装の場合は、次の項目を報告してください。

  1. 更新内容:変更した成果物、画面、キー、コンポーネント、またはコンテンツグループ。
  2. 判断事項:適用した用語、トーン、状態、またはパターンの選択。
  3. 検証内容:実際に確認した一貫性、トークン、収まり具合、レンダリング、チェック。
  4. 確認が必要な項目:製品、調査、ランタイム、ローカライズ、アクセシビリティ、分析、法務に関する未確認事項。

重大な問題が見つからない場合は、その旨を伝え、確認した範囲を明記してください。限られたレビューの結果を、全体的な品質の保証であるかのように示さないでください。

依頼の例

  • 「これらのスクリーンショットにあるチェックアウトの文言をレビューし、重要な変更案だけを提示してください。」
  • 「コンポーネントと製品の動作を維持しながら、選択した Figma フローを書き直してください。」
  • 「コードは変更せずに、この React リポジトリのエラーと空状態の文字列を監査してください。」
  • 「ローカライズカタログに承認済みの用語変更を適用し、すべてのトークンを確認してください。」
  • 「この製品領域全体で、作成、追加、招待、保存のアクションを調整し、決定事項を記録してください。」
  • 「指定されたネットワーク、入力検証、権限の状態について、復旧を重視した文言を生成してください。」

コメント