プロダクトのテキストを書くときに気をつけていること（UI編）

こちらのtakejuneさんのエントリーに触発されて、プロダクトのテキスト（UIやヘルプなど）を書くときに自分が気をつけていることも書いてみます。

書き出すと長くなってしまったので、UIとヘルプで回を分けます。今回はUIのテキストについて。細かい文章の書き方よりも、もう少し抽象的な、考え方や姿勢の話。

ユーザー視点

UIとヘルプの両方で共通するのは、ユーザーの視点で書くこと。これが一番重要。もっとも基本的な鉄則で、かつ最も難しいものでもある。気を抜くと、つい自分の視点だけで物事を見てしまいがち。自分の視点（開発者の視点）ではなくユーザーの視点で書く。

書籍『アイデアのちから（日経BP社）』に、脚本家ノラ・エフロンによるジャーナリズムの授業の話が紹介されている。
ノラ・エフロンは、生徒に「新聞記事のリード（要旨）を書く」という課題を与え、次のストーリー（事実）を読み上げた。

『ビバリーヒルズ高校のピーターズ校長は今朝、職員一同に研修旅行の知らせを告げた。来週木曜、職員全員でサクラメントへ行き、新しい教育法に関する研修に参加する。当日は人類学者のマーガレット・ミードや大学学長のロバート・Ｍ・ハッチンズ、カリフォルニア州知事のパッド・ブラウンによる講演も予定されている。』

生徒はそれぞれ『木曜日、サクラメントで・・・」とリードを書いていく。
さて、ノラ・エフロンが考える、このストーリーのリードは何か。

この記事のリードは『来週の木曜日は休校となる』だ

これはジャーナリズムの授業だけれど、読み手の視点で書くというのは、プロダクトのライティング（UXライティング／テクニカルライティング）にも共通する重要な要素。
プロダクトの機能仕様を書くのではなく、この機能はユーザーから見てどういう意味を持つかを考えて書く。

UIテキストの書き方

UIテキストは、大きくナビゲーショナルなテキストとインフォメーショナルなテキストに分かれるので、私が気をつけていることを分けて書く。

UIのテキストは、UI全体で統一感があることが望ましい。なので、ある程度プロダクトができてきてから、全体を俯瞰して個々のテキストを入れていったほうが書きやすい。
けれど、だからといって開発の下流工程で待ち受けていると、テキストが無いところにテキストを追加するとか、テキストの表示位置を変えるなどの大きな変更がしづらくなる。
なので、上流工程である程度テキストを固めながら、最後の工程で全体を俯瞰してブラッシュアップするのが良い。

ナビゲーショナルなテキスト（ボタンやリンクのラベルとか）

ボタンやリンクには、押すと何が起こるか想像できるラベルを付ける
押すと何が起こるかを、ボタン／リンクのラベルだけで理解できることも重要。
以下はよくあるNG例：

削除してよろしいですか？
[OK] [キャンセル]

このようなラベルを付けると、ボタンを見るだけでは、それを押すと何が起こるのか想像できない。画面全体を読まなければならなくなる。つまりユーザーにとって負荷が高いUI。
ユーザーはあまりテキストを読まないので、何も考えず[OK]を押してしまうこともある。以下のようなラベルにしよう。

削除してよろしいですか？
[削除する] [キャンセル]

ボタンやリンクを押す目的を理解できるラベルを付ける
ボタンやリンクについては、それを押す目的（なぜそれをしなければならないのか）がわかるラベルを付けることも重要。
evernoteのUXライター、ジェシカ・コーリアさんが挙げる例がわかりやすい。

たとえばジェシカは、自分の銀行のウェブサイトを開くたびに、ユーザーがなにか情報を開くためのリンクに「パネルを開く」と書かれているのが気になって仕方がないといいます。「パネルってなに！？ なぜここで自分はそれを開くことが期待されているの？」といつもツッコミをいれながら使っているそうです。

リンクを押すとパネルが開くことはわかっても、何のために、どういうときにパネルを開くべきなのかがわからなければ、意味がない。[プロフィールを開く]など、ユーザーの目的に沿ったラベルにする。

オブジェクトベースかタスクベースかでUIを区別する
UIには、オブジェクトベースのものとタスクベースのものがある。両者の違いについては、ソシオメディアの上野学さんの記事に詳しい。

両者の違いを意識して、言葉を使い分ける必要がある。上野さんが解説するように、オブジェクトベースのUIでは「名詞→動詞」の順序が基本。逆にタスクベースのUIでは、「動詞→名詞」の順序になる。

たとえば、オブジェクトベースのUIでファイルの一覧を開くリンクがあったとする。このリンクに「ファイルの一覧を開く」と付けるのは望ましくない。ユーザーの目的は、ファイルの一覧を開くことではなく、その先（ファイルというオブジェクトに対して編集や削除などの操作をする）にあるからだ。

動詞については、「する」を付けるかどうかの議論がある。たとえば、「作成」にするのか「作成する」にするのか。これはどちらでも良いと思うが、個人的には、『基本的には「する」を付けない。重要なアクションにだけピンポイントで「する」を付ける』のが良いと思っている。文字量を減らしてミニマルにしつつ、言葉に変化を付けて、重要な言葉を目立たせる。

インフォメーショナルなテキスト

インフォメーショナルなテキストというのは、UI上の説明文、通知、警告、エラーメッセージなどのことを指す。

テキストは最小限にする
言葉は火のようなもの。強力だけど、多すぎる火は何も生み出さない（突然ナウシカ風）。つまり読まれない。それだけでなく、テキストが多すぎると雑然とした印象のUIになってしまう。
UIに書く説明テキストは最小限にして、詳細はヘルプを参照してもらう。モバイルアプリやWebサービスであれば、Webヘルプへの誘導もやりやすい。

コンテキストを意識する
複雑なプロダクトでは、ユーザーに伝えなければならない情報は山ほどある。一方で、ユーザーが一度に受け入れられる情報量には限りがある。一度にすべての情報を伝えるのは無理で、各画面で少しずつユーザーに情報をインプットしていく必要がある。

また、テキストの量は最小限にすべきだが、想定する読み手のレベルを下げれば下げるほど、テキストは多くなる（初心者には多くの説明が必要になる）。

大切なのは、コンテキストを意識すること。つまり、「誰が（どの程度の製品知識を持った人が）、どういう状況で、何をしようとしているのか」を意識して、各画面のテキストを書く。

通知

通知はとにかく文を短くする。1文字でも少なくする。瞬時に読めることが大事。

警告
警告は、その役割からして、重要な内容を伝えることが多い。だけど、残念ながらユーザーはあまり読まない。
読み飛ばされることを意識して書くことが大切。読んでもらえる可能性が高いのは、次の2つだ。
・最初の1文
・ボタンのラベル

なので、最初の1文に最も伝えたいことを書く。
また、ボタンのラベルも工夫しよう。冒頭で例に出した削除ボタンのラベルは、さらに工夫できる。

改善前：

一度削除したデータは元に戻せません。削除してよろしいですか？
[削除する] [キャンセル]

改善後：

一度削除したデータは元に戻せません。削除してよろしいですか？
[元に戻せないことを了承して削除する] [キャンセル]

エラーメッセージ
状況（何が起こったのか）、その原因、対処の3つを伝える。
ユーザーを責める表現にしないことにも気を付ける。責任はエラーを誘発したシステムのほうにある。文章はユーザーを主語にして書くのが基本だが、エラーメッセージは例外。受動態にする（主語をなくす）のも一つの手。
❌ 誤ったアイテムを選択しました。
⭕ 誤ったアイテムが選択されました。

最後に

プロダクトのライティングをしていると、言葉がユーザーに与える影響の大きさと共に、その限界も感じます。
たとえば、先に例に挙げた削除の警告文については、そもそもゴミ箱機能（データの復元機能）があるべきという話もあるでしょう。
とはいえ、言葉を少し変えるだけでも大きな効果を見込めることは間違いなく、言葉を通じてユーザーをサポートしていくのがプロダクト開発に関わるライターの仕事だと思っています。

次回は、ヘルプの書き方で気をつけていることを書きます。