記述スタイル

エラー メッセージの表現方法、ヘルプ ドキュメントの記述方法、ボタンに対して選択したテキストは、アプリの使いやすさに大きな影響を与えます。 記述スタイルによって、ユーザー エクスペリエンスが不快にも快適にもなる大きな違いが生まれます。

音声とトーンの原則

調査によると、人々はフレンドリーで、役に立ち、簡潔な書き方に最も反応します。 この研究の一環として、Microsoft は、すべてのコンテンツに適用される 3 つの音声とトーンの原則を開発し、Fluent デザインの不可欠な部分です。

暖かくリラックスする

何よりも、ユーザーを怖がらせる必要はありません。 非公式で、カジュアルで、理解できない用語を使用しないでください。 問題が発生しても、ユーザーを責めないでください。 代わりにアプリが責任を負い、ユーザーのアクションを優先する優れたガイダンスを提供する必要があります。

手を貸す準備をする

常に文章に共感を示してください。 何が起こっているのかを説明し、不要な情報をオーバーロードすることなく、ユーザーが必要とする情報を提供することに重点を置く必要があります。 また、可能であれば、問題が発生した場合は常に解決策を提供してください。

鮮明で明確にする

ほとんどの場合、テキストはアプリの焦点ではありません。 人々を導き、何が起こっているのか、そして次に何をすべきかを教えるためにそこにあります。 アプリでテキストを書き込むときにこれを見失わないようにし、ユーザーがすべての単語を読むと想定しないでください。 対象ユーザーになじみのある言語を使用して、一目で理解しやすいことを確認します。

重要な情報をリードする

ユーザーは、テキストを一目で読んで理解できる必要があります。 不要な紹介で単語を埋め込まない。 重要なポイントを最も見やすくし、アイデアに追加する前に常にアイデアの中核を提示します。

アクションを強調する

アプリはアクションによって定義されます。 ユーザーはアプリを使用するときにアクションを実行し、アプリはユーザーに応答したときにアクションを実行します。 テキストでアプリ全体で アクティブな音声 が使用されていることを確認します。 人と機能は、物事を行うのではなく、物事を行うものとして記述する必要があります。

短くて甘い

ユーザーはテキストをスキャンし、多くの場合、大きな単語のブロック全体をスキップします。 必要な情報やプレゼンテーションを犠牲にせず、必要以上の単語を使用しないでください。 これは、多くの短い文やフラグメントに依存することを意味する場合があります。 それ以外の場合は、長い文の単語と構造に関する特別な選択を意味します。

スタイル規則

自分をライターと見なさない場合は、これらの原則と推奨事項を実装しようとするのは威圧的な場合があります。 しかし、簡単で簡単な言語を使用することは、優れたユーザー エクスペリエンスを提供するための優れた方法です。 また、単語を構造化する方法がまだ不明な場合は、いくつかの役に立つガイドラインを次に示します。 さらに詳しい情報が必要な場合は、 Microsoft スタイル ガイドを参照してください。

ユーザーのアドレス指定

ユーザーに直接話します。

• 常にユーザーを "you" と指定します。
• "we" を使用して、独自の視点を参照します。 これは歓迎され、ユーザーがエクスペリエンスの一部のように感じるのに役立ちます。
• アプリを作成する唯一のユーザーであっても、"I" または "me" を使用してアプリの視点を参照しないでください。

略語

省略形は、アプリ全体で製品、場所、または技術的概念を複数回参照する必要がある場合に役立ちます。 ユーザーが理解している限り、スペースを節約し、より自然に感じることができます。

• ユーザーが一般的だと思われる場合でも、省略形に既に慣れていると想定しないでください。
• 新しい省略形がユーザーに初めて表示される場合の意味を常に定義します。
• 互いに類似しすぎる省略形は使用しないでください。
• アプリをローカライズする場合や、ユーザーが第 2 言語として英語を話す場合は、省略形を使用しないでください。

短縮系

人々は収縮に慣れ、それらを見て期待しています。 これらを回避すると、アプリが形式的すぎるように見えたり、詰まったりする可能性があります。

• テキストに合わせて自然に収まる場合は、収縮を使用します。
• 単にスペースを節約するために不自然な収縮を使用しないでください。

期間

ピリオドで終わるテキストは、そのテキストが完全な文であることを意味します。 大きなテキスト ブロックにはピリオドを使用し、完全な文よりも短いテキストでは使用しないようにします。

• ピリオドを使用して、ヒント、エラー メッセージ、ダイアログで文全体を終了します。
• ボタン、ラジオ ボタン、ラベル、またはチェック ボックスのテキストをピリオドで終了しないでください。

大文字の使用

大文字は重要ですが、使いすぎやすいです。

• 固有名詞を大文字にする。
• アプリ内のすべてのテキスト文字列の先頭 (すべての文、ラベル、タイトルの先頭) を大文字にします。

エラー メッセージ

アプリで問題が発生した場合、ユーザーは注意を払います。 ユーザーはエラー メッセージに遭遇したときに混乱したり、不満を感じる可能性があるため、音声とトーンが特に大きな影響を与える可能性がある領域です。

何よりも、エラー メッセージがユーザーを責めないようにすることが重要です。 しかし、理解できない情報で彼らを圧倒しないことも重要です。 ほとんどの場合、エラーが発生したユーザーは、可能な限り迅速かつ簡単に実行していた内容に戻りたいと考えています。 したがって、書き込むエラー メッセージは次のようになります。

• 会話のトーンを使用し なじみのない用語や技術的な専門用語を避けることで、暖かくリラックスしてください。

• 次に何が起こるかをユーザーに伝え 現実的なソリューションを提供することで、ユーザーに能力の最大限の問題を伝えることで、手を貸す準備をします。

• 余分な情報を排除して 鮮明にしてください。

ダイアログ

ボタン

音声エクスペリエンス

Cortana などの音声エクスペリエンスのテキストを記述する場合も、同じ一般的な原則と推奨事項が適用されます。 これらの機能では、読み上げられた単語を補完する他の視覚的なデザイン要素をユーザーに提供できないため、優れた書き込みの原則はさらに重要です。

• 会話のトーンでユーザーを引き付けることで 暖かくリラックスしてください。 他のどの分野よりも、話された経験が暖かく、近づきやすくなります。そして、ユーザーが話すことを恐れていないものであることが重要です。

• ユーザーが不可能と尋ねたときに代わりの提案を提供して 手を貸す準備をしてください。 エラー メッセージと同様に、問題が発生し、アプリが要求を満たせなかった場合は、代わりにユーザーが尋ねることができる現実的な代替手段をユーザーに提供する必要があります。

• あなたの言語をシンプルに保つことで 鮮明で明確にしてください。 音声エクスペリエンスは、長い文や複雑な単語には適していません。

アクセシビリティとローカライズ

アクセシビリティとローカリゼーションを念頭に置いて作成されたアプリは、より多くのユーザーにリーチできます。 これはテキストだけでは実現できないものですが、簡単でフレンドリーな言語は素晴らしいスタートです。 詳細については、 アクセス可能性の概要 および ローカライズのガイドラインを参照してください。

• さまざまな経験を考慮して 手を貸す準備をしてください。 国際的な対象ユーザーには意味のないフレーズを避け、ユーザーができることとできないことを想定する単語を使用しないでください。

• 通常とは異なる特殊な単語が不要な場合は避けることで 鮮明で明確にしてください。 テキストが単純であるほど、ローカライズが容易になります。

ライター以外の場合の手法

ユーザーに優れたエクスペリエンスを提供するために、トレーニング済みまたは経験豊富なライターである必要はありません。 あなたに快適に聞こえる言葉を選ぶ - 彼らは他の人にも快適に感じるでしょう。 しかし、時には、それは聞こえるほど簡単ではありません。 立ち往生した場合、これらの手法が役立ちます。

• アプリについて友人と話しているとします。 アプリについてどのように説明しますか? その機能についてどのように話すか、指示を与えますか? アプリをまだ使用していない実際のユーザーに説明することをお勧めします。

• まったく異なるアプリについて説明する方法を想像してみてください。 たとえば、ゲームを作成する場合は、財務アプリやニュース アプリについて説明するために何を言うか、書き込むかを考えてください。 使用する言語と構造のコントラストにより、実際に書いている内容に適した単語に関するより多くの洞察を得ることができます。

• 同様のアプリを見て、インスピレーションを得てください。

正しい言葉を見つけることは、多くの人が苦労する問題なので、自然に感じるものに簡単に解決できない場合は気分が悪くはありません。