BabichNickはロシアのセントピーターズバーグ出身のソフトウェアデベロッパー/ブロガーです。彼による他の記事はこちらをご参照ください。Babichからの翻訳転載です。配信元または著者の許可を得て配信しています。DesignUIのラベルやテキストは、正確且つ簡潔なライティングによって使いやすくなり、信頼度が高まります。今回はUIライティングで避けるべき16個のポイントをご紹介します。特殊な言い回しと専門用語ユーザーの知らない用語や馴染みのない言い回しはユーザーの認知的負荷を増やしてしまいます。「ギークな会話」を避ける為にベストを尽くしましょう。安全策を取って、すべての読者に向けて書くということ、そしてビギナー、ベテラン問わず通じるような一般的な言葉を用いましょう。以下は特殊な言い回しをエラーメッセージに使用した例です。システム用語のオンパレードで、誰がこのメッセージの対象者なのか明確ではありません。システム管理者か、あるいは従業員なのでしょうか。Credit:IDWもちろん、これは状況によります。このメッセージを見て理解できるユーザーが対象なのであれば問題ありません。なければ、今すぐにでも単純で直感的になるように変更しましょう。長過ぎる詳細文ほとんどの場合、冒頭ですべての詳細を述べる必要はありません。ユーザーが機能を探索し、実際にその情報が必要になったときにはじめて、機能の詳細を開示する方が良いでしょう。・すべてのメッセージについて、「これはユーザーが本当に知る必要のある情報だろうか?」と自分に問いかけてみましょう・読みやすいようになるべく短い文章で構成する。可能であれば文は30単語以下となるようにする。簡潔な(Concise)な文章にする。動作を説明する為に未来形プロダクトの挙動を説明するのには現在形を利用しましょう。過去や未来の時制での記載が必要なときは、なるべくシンプルな動詞を使いましょう。「Me/My」と「You/Your」を混在させる同じ文脈で異なる立場のユーザーが現れることは、混乱の原因となります。数字を表す単語を利用する数字を表す単語ではなく、数字を使ってスペースを節約しましょう。「私たち」という言い方をするあなたやアプリケーションがユーザーに何をしているかではなく、ユーザー自身とユーザーがアプリケーションを利用して何ができるかという点に焦点を当てましょう。Facebook.”(手始めにFacebookの人気投稿を見てみましょう)しかしながら、このルールには例外があります。申し立てのレビューや提案への対応など、人が実際にユーザーの為に何か作業を行う場合です。このようなケースでは、「We(私たち)」の利用は適切です。すべての文字を大文字にする全ての文字が大文字が大文字になっているテキストは、読解を考慮しないロゴや頭字語のような文脈では問題ありません。読解を考慮するメッセージの場合は、ユーザーにそれを読む事を強要してはいません。Printで言及したように、すべて大文字の印刷はすべて小文字の場合と比べて読むスピードを非常に遅くします。ほとんどの読み手はすべて大文字は読みにくいと判断します。小文字のほうが言葉となったときに特徴的な形を形成しやすいため、読みやすいとされています。小文字は単語単位での読み取りを許可する一方、全て大文字の場合は一文字づつ読み取られる傾向があります。すべて大文字のテキストはユーザーにとって読みづらいしたがって、通常の文章と同じような大文字の使い方をすべてのタイトル、ヘッダー、ラベル、メニューに使いましょう。絶対に「絶対」と言わない事は守るべき偉大なルールです。information”(重要な情報のみ配信します)また、「自慢」はやめましょう。機能の説明まではいいですが、それがいかに素晴らしいかは控えましょう。エクスクラメーションマークエクスクラメーションマーク(感嘆符)は叫んでいるような印象を与えるので、避けるべきです。picture,”「あなたは彼もしくは彼女の写真をみる事ができます」)。可能な場合に性別を指定し、his(彼)かher(彼女)を使いましょう。一般的な前置き言葉数を減らしましょう。ユーザーが理解しやすいシンプルで直接的な言葉を使うべきです。to’などの余分な一般的な前置きフレーズは除外しましょう。「本当にしますか」この種の問いかけは質問に何かの価値を付与する事はほとんどありませんし、ほとんどの場合ユーザーに利益がありません。文化的に特有の言語は翻訳が難しい場合があり、いくつかの状況では不適切な場合があります。ダイアログでの「OK」ボタンダイアログボックスというのはユーザーに彼らがどちらの行動をしたいか質問するだけではありません。それぞれのボタンについて明確にする事でもあります。「OK」ボタンが多くのダイアログで標準的な慣例である一方、ほとんどのアプリケーションはダイアログボックスによりユーザーフレンドリーなアプローチをしています。彼らが行いたい行動の確認の為に「OK」ボタンをユーザーに提供する代わりに、特定の動作が示されたボタンを用意する方がより効率的です。全てのユーザーが質問やメッセージを読むわけではないので、このアプローチはユーザーエラーの可能性を低減します。「写真を削除」ダイアログのボタンであれば以下となります。漠然としたエラーメッセージエラーメッセージは避けて通れません。それらもUX観点でも調和した一部としなければいけません。エラーメッセージは人間に向けて書かれてあるように聞こえ、そしてそれを達成する為にエラーメッセージは次の事を明確に宣言してください:・何が間違っており、何故それが起きたのか・エラーを解消する為に次に行うべきステップは何か典型的なエラーはユーザーになぜ不正なのかを伝えずに「データが不正です」と表示します。メッセージが明確である事を確認して下さい。ユーザーを責めるユーザーはミスをするものです。彼らのせいにするのはやめましょう。「このファイルが存在しないということをもう3回も言いました。そのせいでこの意味のないウィンドウを出す羽目になってとても怒っています。usabillaユーザーがエラーについて直接的に責められる事のないようなメッセージを書きましょう。エラー自体ではなくユーザーの問題に焦点を当てましょう。(このメールアドレスは利用できません。スペルが正しいか確認して下さい)まとめあなたのアプリのテキストはUIを補完するものであるべきです。シンプルで簡潔、直接的で効率的にしましょう。それは文化や言語にかかわらず、どこの誰からも理解可能であるべきです。MILKはより良いサービスやプロダクトを作りたい人のためのメディアです。