UIのライティングでやってはいけない16のこと

Nick Babich

Nickはロシアのセントピーターズバーグ出身のソフトウェアデベロッパー/ブロガーです。彼による他の記事はこちらをご参照ください。

この記事はNick Babichからの翻訳転載です。配信元または著者の許可を得て配信しています。

Effective Writing For Your UI: Things to Avoid
1jxp2sdxgpelbue5pf_q_xq

Image credit: Material Design

UIのラベルやテキストは、正確且つ簡潔なライティングによって使いやすくなり、信頼度が高まります。

では、ラベルやテキストのライティングにおいてやってはいけないこととは何でしょうか? 今回はUIライティングで避けるべき16個のポイントをご紹介します。

1. 特殊な言い回しと専門用語

ユーザーの知らない用語や馴染みのない言い回しはユーザーの認知的負荷を増やしてしまいます。「ギークな会話」を避ける為にベストを尽くしましょう。安全策を取って、すべての読者に向けて書くということ、そしてビギナー、ベテラン問わず通じるような一般的な言葉を用いましょう。

以下は特殊な言い回しをエラーメッセージに使用した例です。

1ljkkrnhoqgs9pms9hhm0sg

システム用語のオンパレードで、誰がこのメッセージの対象者なのか明確ではありません。システム管理者か、あるいは従業員なのでしょうか。 Image Credit:IDW

もちろん、これは状況によります。もしこのメッセージを見て理解できるユーザーが対象なのであれば問題ありません。そうでなければ、今すぐにでも単純で直感的になるように変更しましょう。

2. 長過ぎる詳細文

ほとんどの場合、冒頭ですべての詳細を述べる必要はありません。ユーザーが機能を探索し、実際にその情報が必要になったときにはじめて、機能の詳細を開示する方が良いでしょう。

実践的なコツとしては、

 ・すべてのメッセージについて、「これはユーザーが本当に知る必要のある情報だろうか?」と自分に問いかけてみましょう

 ・読みやすいようになるべく短い文章で構成する。可能であれば文は30単語以下となるようにする。

1qzg2dn8auzvd0ym7yvhk-w

なるべく簡潔な(Concise)な文章にする。 Image Credit: dailyrindblog

3. 動作を説明する為に未来形

プロダクトの挙動を説明するのには現在形を利用しましょう。過去や未来の時制での記載が必要なときは、なるべくシンプルな動詞を使いましょう。

悪い例:“Message has been sent”(メッセージは送信されています)

良い例:“Message sent”(メッセージを送信しました)

4. 「Me/My」と「You/Your」を混在させる

同じ文脈で異なる立場のユーザーが現れることは、混乱の原因となります。

悪い例:“Change your preferences in My Account.”(あなたの「わたしのアカウント」で設定を変更する)

良い例:“Change personal preferences in My Account.”(「わたしのアカウント」の個人設定を変更する)

5. 数字を表す単語を利用する

数字を表す単語ではなく、数字を使ってスペースを節約しましょう。

悪い例:“You have three messages”(3つのメッセージが届いています)

良い例:“You have 3 messages”

6. 「私たち」という言い方をする

あなたやアプリケーションがユーザーに何をしているかではなく、ユーザー自身とユーザーがアプリケーションを利用して何ができるかという点に焦点を当てましょう。

悪い例:“To get you started, we’re showing you popular posts on Facebook.”(まず手始めに、私たちがFacebookの人気投稿をご紹介します)

良い例:“Get started with these popular posts on Facebook.”(手始めにFacebookの人気投稿を見てみましょう)

しかしながら、このルールには例外があります。例えば申し立てのレビューや提案への対応など、人が実際にユーザーの為に何か作業を行う場合です。このようなケースでは、「We(私たち)」の利用は適切です。

悪い例:“Your appeal will be reviewed, and you will receive a response within a few days.”(あなたの要望はレビューされ、数日以内に返答がくるでしょう)

良い例:“We’ll review your appeal and respond within a few days.”(あなたの要望をレビューしたのち、私たちから数日以内に回答いたします)

7. すべての文字を大文字にする

全ての文字が大文字が大文字になっているテキストは、読解を考慮しないロゴや頭字語のような文脈では問題ありません。しかし、読解を考慮するメッセージの場合は、ユーザーにそれを読む事を強要してはいません。

Miles Tinker氏が彼の歴史的作品であるLegibility of Printで言及したように、すべて大文字の印刷はすべて小文字の場合と比べて読むスピードを非常に遅くします。さらに、ほとんどの読み手はすべて大文字は読みにくいと判断します。

小文字のほうが言葉となったときに特徴的な形を形成しやすいため、読みやすいとされています。小文字は単語単位での読み取りを許可する一方、全て大文字の場合は一文字づつ読み取られる傾向があります。

15mbg1w_5jcghsvjwndqbog

すべて大文字のテキストはユーザーにとって読みづらい

したがって、通常の文章と同じような大文字の使い方をすべてのタイトル、ヘッダー、ラベル、メニューに使いましょう。

悪い例:“SEARCH SETTINGS”(検索設定)

良い例:“Search settings”

8. 「絶対」と過剰表現

絶対に「絶対」と言わない事は守るべき偉大なルールです。

悪い例:“We’ll never send you promo emails”(宣伝メールは絶対に送信しません)

良い例:“You’ll receive only important information”(重要な情報のみ配信します)

また、「自慢」はやめましょう。機能の説明まではいいですが、それがいかに素晴らしいかは控えましょう。

悪い例:Amazing deals at places you’ll love”(あなたがきっと気に入るであろう場所での素晴らしい割引

良い例:“All your savings in one place”(すべての割引がひとまとめに)

9. エクスクラメーションマーク

エクスクラメーションマーク(感嘆符)は叫んでいるような印象を与えるので、避けるべきです。

悪い例:“Learn about the new features of the app!”(アプリの新しい機能について学習しましょう!)

良い例:“Welcome”(ようこそ)

10. 性別の曖昧さ

英語は性別の曖昧さを許容する、数少ない言語のうちの一つです(例えば、“you can see their picture”「あなたは彼らの写真を見る事ができます」)が、ほとんどの外国語はより特定的です(例えば、“you can see his or her picture,”「あなたは彼もしくは彼女の写真をみる事ができます」)。

可能な場合に性別を指定し、his(彼)her(彼女)を使いましょう。

11. 一般的な前置き

言葉数を減らしましょう。ユーザーが理解しやすいシンプルで直接的な言葉を使うべきです。'you must’ や’ due to the fact that’、’in order to’などの余分な一般的な前置きフレーズは除外しましょう。

悪い例:Would you like to save your changes?”(変更を保存しますか?)

良い例:“Save changes?”

12. 「本当にしますか」

この種の問いかけは質問に何かの価値を付与する事はほとんどありませんし、ほとんどの場合ユーザーに利益がありません。

悪い例:Are you sure you want to delete this photo?”(本当にこの写真を削除しますか?)

良い例:“Delete this photo?”(この写真を削除しますか?)

13. 文化的に特有な慣用句

文化的に特有の言語は翻訳が難しい場合があり、いくつかの状況では不適切な場合があります。

悪い例:“You really hit it out of the park!”(ホームランをかっ飛ばしたね!*)

良い例:“Great job!”(お見事!)

*素晴らしい結果を出したことを表す慣用句

14. ダイアログでの「OK」ボタン

ダイアログボックスというのはユーザーに彼らがどちらの行動をしたいか質問するだけではありません。それぞれのボタンについて明確にする事でもあります。

「OK」ボタンが多くのダイアログで標準的な慣例である一方、ほとんどのアプリケーションはダイアログボックスによりユーザーフレンドリーなアプローチをしています。彼らが行いたい行動の確認の為に「OK」ボタンをユーザーに提供する代わりに、特定の動作が示されたボタンを用意する方がより効率的です。さらに、全てのユーザーが質問やメッセージを読むわけではないので、このアプローチはユーザーエラーの可能性を低減します。

例えば、「写真を削除」ダイアログのボタンであれば以下となります。

悪い例:“OK | Cancel”

良い例:“Remove | Keep” (取り除く | 保留)

15. 漠然としたエラーメッセージ

エラーメッセージは避けて通れません。しかしそれらもUX観点でも調和した一部としなければいけません。エラーメッセージは人間に向けて書かれてあるように聞こえ、そしてそれを達成する為にエラーメッセージは次の事を明確に宣言してください:

 ・何が間違っており、何故それが起きたのか

 ・エラーを解消する為に次に行うべきステップは何か

1tag0vok8pivu66heoasyfg

典型的なエラーはユーザーになぜ不正なのかを伝えずに「データが不正です」と表示します。メッセージが明確である事を確認して下さい。Image Credit : Material Design

16. ユーザーを責める

ユーザーはミスをするものです。彼らのせいにするのはやめましょう。

0rejjlfw20hesqdcv

「このファイルが存在しないということをもう3回も言いました。そのせいでこの意味のないウィンドウを出す羽目になってとても怒っています。もうやらないで下さい。」Image credit: usabilla

ユーザーがエラーについて直接的に責められる事のないようなメッセージを書きましょう。エラー自体ではなくユーザーの問題に焦点を当てましょう。

悪い例:“You’ve provided an incorrect email.”(あなたは正しくないメールアドレスを提供しました)

良い例:“This email address cannot be used. Please ensure that the spelling is correct.” (このメールアドレスは利用できません。スペルが正しいか確認して下さい)

まとめ

あなたのアプリのテキストはUIを補完するものであるべきです。シンプルで簡潔、直接的で効率的にしましょう。それは文化や言語にかかわらず、どこの誰からも理解可能であるべきです。


Welcome to UX MILK

UX MILKはより良いサービスやプロダクトを作りたい人のためのメディアです。

このサイトについて