ユーザーエクスペリエンスを向上させるWebアプリのコンテキストで:事実をできるだけ簡単に説明するコピーを使用するか、カジュアルな言葉で話すコピーを使用しても、結果としてより冗長になる可能性がありますか?
状況によって答えが異なる場合があるため、以下に3つの例を示します。
短くてシンプル:[〜#〜] open [〜#〜]
カジュアル:[〜#〜]開く[〜#〜]ドキュメント
短くてシンプル:エラー:送信できません。 もう一度試す
カジュアル:おっと!メッセージを送信できませんでした。 もう一度やり直しますか??
短くてシンプル:[〜#〜]キャンセル[〜#〜]、 [〜#〜]保存[〜#〜]、[〜#〜]閉じる[〜#〜]
カジュアル:[〜#〜] save [〜#〜]最初に保存しますか[〜#〜]閉じる[〜#〜]保存せずに?気にしないで、連れて行って[〜#〜]戻る[〜#〜]。
3つの例を挙げましたが、他にもあります。短くてシンプルなのがいいですが、カジュアルな言葉遣いは、ユーザーが理解しやすく、わかりやすくなる可能性があります。
フォローアップの質問:
ほとんどの場合、カジュアルなテキストの方が優れていますか?
いつ他の方法を使うべきですか?
このテーマで行われた研究はありますか?
それはアプリケーション自体に依存します。それは正式な文脈であり、言語と指示は正式でなければなりません。ほとんどのユーザーは、次のような銀行や政府を信用しません:「おい、社会保障番号が正しくありません。正しいものを入力してください」。極端なケースだと思います。一方、一部のユーザーは、お気に入りのオンラインTシャツストアで、指示にカジュアルで非公式な言葉を使用することを望んでいる可能性があります。
また、対象となるユーザーによっても異なります。それがeveryoneの場合は、指示とエラーメッセージに注意する必要がありますが、対象のユーザーが30歳までの若い男性をポーカーでプレーするように絞り込まれている場合は、はるかに簡単です。次に、日常生活で使用する言語を使用する必要があります。 ContextおよびIntended userは、使用する言語の種類を決定するものです。
Benny と Baa の両方が正しいのですが、問題は、実際には " size "についてであり、 "何が入っているか。 "つまり、テキストとそのテキストの量。
私は簡潔な答え(ラベル)を信じていますが、UIはすっきりしています。ただし、さまざまなユーザーがいるため、次のステップや特定のボタンの機能を理解するために、もう少し情報が必要な人が常にいます。
私は実際に両方のUIの「ファクト」(たとえば、保存、閉じる、キャンセル)を使用し、より詳細なホバーテキスト(「保存をクリックしてデータを保存してこのフォームを閉じる」、「閉じる」をクリックしてこのフォームを閉じる)データを保存せずに。」、「[キャンセル]をクリックしてこのダイアログボックスを閉じ、このフォームに戻ります。注:この時点ではデータは保存されていません。).
ホバーテキストに関する重要な考慮事項-ホバーテキストの遅延を増やして、ユーザーが本当に必要な場合にのみポップアップするようにします。そうでなければ、それは、特にそれを必要としない人にとっては苦痛です!ホバーテキストがUIの重要な部分を覆っているので、アプリケーションを何度呪いましたか? (...うーん多分それは私が負担しているのろいだけです!)
ちなみにこれは多少関係があるので。私たち全員がADA準拠の設計コンセプトを使用していることを願っています。より詳細な「Altタグ」を使用すると、視覚障害者(および他の身体障害者)がアプリケーションを「よく見る」のに役立ちます。
これは、政府のWebサイトの設計者が使用することになっているチェックリストです。これは、ユーザーがウェブサイトやアプリケーションにどのようにアクセスできるかを判断するための優れた指標です。
宜しくお願いします、
いくつかのカジュアルな言語の例の問題は、単語の数がどのように増加するかであり、これは一般に「悪いこと」です。
トピックに関する2000年のJoel Spolskyは次のとおりです。
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
実際、ユーザーは何も読みません。
これは少し厳しいように聞こえるかもしれませんが、ユーザビリティテストを実行すると、画面に入力した単語を単に読まないユーザーがかなりいることがわかります。なんらかのエラーボックスをポップアップすると、彼らは単にそれを読みません。これはプログラマーとしてあなたを困惑させるかもしれません、なぜならあなたは自分とユーザーとの対話を行っていると想像するからです。ねえ、ユーザー!そのファイルを開くことができません。そのファイル形式はサポートされていません!
それでも、経験から、ダイアログボックスに入力する単語が多いほど、実際に読む人が少なくなることがわかります。
どちらもユーザーエクスペリエンスに優れているとは言えません。それはすべて、作成するアプリケーションのタイプによって異なります。
専門サービスについては、専門用語を使用しています。法律事務所がクライアント向けのクライアント向け請求サイトを持っている場合、クライアントに「おっと、その日付のタイムシートが見つかりません!」と表示されたくないでしょう。それは非常に専門外に聞こえます。
一方、カジュアルで楽しいことを意図したサイトでは、カジュアルで楽しい言葉を使うのが適切です。 Twitterは、非常に多様な群衆が自由時間に使用する単純なWebアプリケーションです。カジュアルな言葉遣いはそこでうまくいきます。
そうは言っても、それはメッセージ/機能/アクションの特定のコンテキストにも依存すると思います。人々は「保存」または「キャンセル」というボタンを簡単にスキャンでき、ユーザーはこれらのボタンの意味を知っています。これらのアクションをよりカジュアルにする必要は必ずしもありません。混乱を招き、ボタンを簡単に識別できなくなる可能性があるためです。
カジュアルな話は、特にサイトのトーンがあなたの言葉で賢くて機知に富むことができる場合、永続的な印象を残すことができます。 MailChimpのようなサイトや他のサイトが物事の巧妙な言い方を見つけたとき、私はそれが大好きです。それはユーザーとの良好な関係を築くのに本当に役立ち、しばしば彼らを笑わせることができます。私たちは皆、同じ古い同じ古い簡略化されたものを見てきました。それを面白くして、戻ってきてもらいましょう!
他の人が指摘したように、あなたの声はあなたのサイトの聴衆に依存するべきです。
しかし、あなたの質問は実際に、アクション実行言語をどのように説明すべきかを尋ねているようです。
「キャンセル|保存|閉じる」はあまり役に立ちません。キャンセルとクローズの違いは何ですか?このダイアログボックスを閉じるだけですか?
「保存して閉じる|保存せずに閉じる|キャンセルして編集を続行する」のようなものは、さらに役立ちます。
また、「メッセージを送信できませんでした。もう一度やり直しますか?」 「エラー。送信できません。もう一度お試しください」よりもはるかにユーザーフレンドリーです。
アクション実行およびエラー処理言語をコンテキストに組み込むことは、常に優れたユーザーエクスペリエンスです。
Benny Skogbergは質問1と2に非常によく答えました。
3番目の質問に答えるために、Aarron Walter(MailChimpのユーザーエクスペリエンスディレクター)がこのトピックに関する本を書いています。