見知らぬ人たちのための画面
現在取り組んでいる「班長ノート」は、特定の組織に所属する人だけが使うものではなく、半導体の建設現場で働く日雇い作業員の方々や班長の方々を対象としたアプリです。現場で人を募集したり、働きたいときに仕事を探したりする方々。私とはこれまでほとんど接点がなく、ややなじみの薄い領域にいる方々です。そのため、このアプリを作り始めた当初から、どこか途方に暮れるような感覚がありました。
専門家向けのソフトウェアを作るときは、ユーザーはすでに業務の文脈を理解しているという前提で画面を設計できます。しかし、班長ノートではその前提をそのまま当てはめるのは難しいです。ユーザー層の年齢やスマートフォンの利用スキルをあらかじめ決めつけるのではなく、初めて画面を見たときに、どのような点を不慣れに感じる可能性があるのかをより詳しく考える必要がある、ということです。ユーザーがすでに知っているという前提なしに画面を設計しなければならない。この違いは、思っていた以上に大きいものでした。画面を一つ作る際に考慮すべきことの種類そのものが変わるからです。
理解してもらえるだろうか、という不安
だから、画面をつくるたびに、ほのかな不安がつきまといます。このボタンを押すと何が起きるのか、すぐに分かるだろうか。この文言を見て、次に何をすればいいのか迷わないだろうか。もしかすると、この言葉を見慣れないと感じるのではないか。そんな問いを、何度も自分に投げかけることになります。
たとえば、入力フィールドのプレースホルダーを一つ決めるだけでも、かなり悩みました。テキスト入力欄には「〜を入力してください」、選択フィールドには「〜を選択してください」、数字だけを受け付ける欄には「数字のみ入力してください」のように、フィールドの性質に応じて案内文を変えるべきかどうかを考えました。ユーザーからすれば些細なことに見えるかもしれません。しかし、今この欄に何を書けばいいのかを一目で分かるかどうかは、こうしたところで分かれると思ったからです。「入力」という一言で済ませれば楽ですが、それでは数字だけを受け付ける欄に文字を入力しようとして、エラーになるユーザーが出てくるかもしれないと思いました。
特にUIを設計するときは、慣れ親しんだデザインの文法、たとえばアイコンだけあれば直感的に理解してもらえるだろうとか、この程度のインタラクションなら今どき誰でも慣れているだろうといった感覚を、そのまま適用してよいのか、毎回あらためて検討するようになります。こうした感覚は、スマートフォンやさまざまなアプリを毎日使う中で自然に身についたものであり、ターゲットユーザーの感覚と必ずしも一致するわけではないからです。
この不安は、実は悪いものではありませんでした。むしろ、この不安があったからこそ、画面をつくるときにユーザーの立場で、もう一度考えるようになりました。ユーザーはスマートフォンやアプリの利用に不慣れだろうという前提ではなく、このアプリが扱う業務や画面の流れそのものについては、私よりもユーザーのほうがはるかによく知っている領域であり、反対に私はこのドメインに不慣れな人間なのだという事実を、常に意識するようになりました。そうすると自然に、「これくらいは当然分かるだろう」という自分側の思い込みを減らせるようになりました。そして、その過程で一つの方向性が生まれました。親切に書こう。そして、次の行動へ自然に導こう。ユーザーが画面を見て立ち止まらず、次に何をすればよいかを自分で判断しなくても済むように、文言で案内しようという考えです。
ところが、受け取ったフィードバックは正反対でした
問題はそのあとでした。ボタンの文言について、できるだけ簡潔な語尾にしてほしいというフィードバックを受けました。親切に、説明するように書きたかったのですが、実際に求められたのは短く簡潔な語尾でした。たとえば最初は「ログインしに行く」のように、次の行動をやわらかく促すトーンでボタンの文言を書いていました。このボタンを押したとき、実際にログインが完了するのではなく、ログインの手続きへ進むものだったため、「ログイン」という名詞形よりも、「〜しに行く」のように移動のニュアンスを含む語尾を使うのが適切だと思ったのです。
ところが、フィードバックは「ログイン」程度に短くしてほしいというものでした。最初は、短いとあまりにも硬く冷たく感じられないだろうか、ユーザーはこれを見てログインがすぐに完了するのか、それともログインページへ移動するのか、迷わないだろうか、と心配になりました。こうしたフィードバックが、私の考えていた親切さと、実際に求められている簡潔さとは、異なる方向を示していたからです。親切であることを、説明を十分に付け加えることと同じものだと考えていました。しかし、ボタンという場所では、それがかえって逆効果になる可能性があるということに、そのときはまだ気づいていませんでした。
似たようなフィードバックは、ホーム画面にもありました。ホーム画面の上部に「こんにちは〜ユーザーさん、今日もお疲れさまです！」のようなあいさつ文を入れたところ、こうした文言は必要ないというフィードバックを受けました。実際、このようなあいさつは多くのアプリでよく使われているパターンなので、当然あるべき要素だと思っていました。名前を呼んであいさつをすると、アプリが自分を認識してくれているように感じられ、人と人とのように話しかけてくれる親しみやすさを与えられると考えていたからです。サービスの初期段階で、ユーザーが馴染みにくさを感じないよう、トーンをやわらかく始めるための仕掛けとしてよく使われるのも、そうした理由からなのでしょう。
ところが、班長ノートのユーザーにとっては、この挨拶文がアプリを使う目的とは関係のない装飾のように感じられる可能性がありました。班長ノートを開くのはたいてい、その日に働く場所を探したり、応募状況を確認したり、急いで人を集めたりする場面です。その手前に挨拶文が一行置かれると、本当に必要な情報にたどり着くまでに、もう一ステップ増えることになります。親しみやすさを感じてもらうために入れた文言が、かえってユーザーの望む目的から一歩遠ざけてしまうこともあるのだと、このフィードバックを通じて改めて考えさせられました。
振り返ってみると、ボタンの文言もあいさつも、理由は似ていました。ボタンは、ユーザーが画面をざっと見る短い瞬間にすぐ認識し、押す必要がある要素です。ボタン内の文章が長くなると、かえって読むのに時間がかかり、視線が留まる時間が増えることで、ユーザーは「このボタンを押してもいいのだろうか」とためらうかもしれません。あいさつも同じです。画面に必ずしも必要でない文言が一つ増えるたびに、ユーザーが本当に探している情報までの距離は、その分遠くなります。親切さとは、必ずしも文言を一つでも多く加えることではない。その事実を、こうしたフィードバックを受けて初めて実感しました。
そこで見つけた折衷案
最終的に出した結論は、ボタンは簡潔にし、その代わり説明が必要な場所では、しっかりと親切に案内するということです。ボタンは、ユーザーが今どんな行動をするのかを、短く明確に伝える役割だけを果たせば十分です。「確認」「削除」「次へ」のように。余計なものを加えず、ユーザーが視線を向けた瞬間に意味を理解できなければなりません。この場所では、語尾をやわらかく引き伸ばしたり、状況を説明しようとしたりすること自体が、かえって邪魔になるのだと受け入れられるようになりました。
その代わり、オンボーディング画面や案内文、空画面（エンプティステート）のように説明が必要な場所では、できるだけ分かりやすく、親しみを込めて書きました。たとえば、まだデータがない空画面では、「進行中の求人はありません。今すぐ求人を登録してみましょう！」のように状況を説明する文言とアクションボタンを添え、ユーザーが次に何をすればよいかを自分で判断しなくても済むよう案内しました。こうした場所は、ユーザーが時間をかけて読んでもよい場所です。そのため、ここではむしろ十分に親切に書くのが適切だと判断しました。
このように役割を分けると、ボタンは明確になり、画面全体は親切になるというバランスを取ることができました。すべての文言を一つのトーンに統一するのではなく、それぞれの要素が画面の中で担う役割に応じて、トーンを変える必要があるのだと分かりました。
この経験から整理した、私なりのUXライティングの原則
この仕事を経験してから、文言を書くときの基準にするようになったことがいくつかあります。
1. 場所ごとに求められる親切さの形は異なります。ボタンのように即座の判断が必要な場所と、オンボーディングや案内文のように時間をかけて読んでもよい場所とでは、親切さの表し方が異なるべきです。前者では短く明確であることが親切であり、後者では十分に説明することが親切です。画面全体を無理に同じトーンへ統一しようとしないことのほうが、ユーザーへの配慮になるのだと分かりました。
2. ユーザーが「考えなくて済む」状態をつくることが目標です。親切な文言とは、ユーザーが画面の前で立ち止まって悩まなくても済む文言です。説明をたくさん付けることではなく、ユーザーが次に何をすればよいかを自分で推測しなくても済むようにすることです。親切さは文章の長さではなく、ユーザーが感じるためらいの大きさで判断すべきなのだと分かりました。
3. 慣れ親しんだ感覚を、ユーザーの感覚と同一視しません。デザイナーとして毎日さまざまなアプリに触れていると、「これくらいは誰でも分かるだろう」という感覚が生まれます。しかし、その感覚は自分の経験から生まれたものであり、ターゲットユーザーの経験から生まれたものではありません。特に接点のないユーザー層を対象にするほど、自分が当然だと感じていることを、もう一度疑ってみる必要があります。
4. 繰り返される言葉や意味のない文言を減らします。親切に書こうという気持ちで文章を長くしていくと、あとから読み返したときに、同じ意味を二度述べていることがあります。十分に説明することと、同じことを繰り返すことは別ですが、書いているときにはその違いが見えにくいものです。あいさつのように、画面の目的とは関係なくトーンだけを加える文言も同じです。あれば雰囲気はやわらかくなりますが、なくてもユーザーが画面を理解して使ううえで何の支障もない文言なら、あえて入れる理由はありません。文言を書き終えたら、一度声に出して読んでみる。前の文ですでに述べたことを後の文が繰り返していないか、この文言を削除してもユーザーが画面を使ううえで問題がないかを確認する習慣が必要だと感じました。
5. その言葉が日常語なのか、学習が必要な用語なのかを区別します。文言にどの言葉を使うか決めるときは、その言葉がユーザーがすでに日常的に使っているものなのか、それともこのアプリや業務の中でしか使われず、初めて触れると馴染みにくく感じるものなのかを、まず区別するようにしています。後者であれば、その言葉を画面にそのまま使うのではなく、かみ砕いて説明するか、初めて触れる場所（オンボーディングやツールチップなど）で短くても案内を添えるようにしました。一方で、すでに馴染みのある言葉までわざわざ詳しく書くと、かえって文章が長くなり、不自然になることも分かりました。
このほかに学んだことがあるとすれば、ボタンの文言一つが開発工数やレイアウトの安定性に影響することを経験し、文言はデザイナー一人の好みではなく、開発者やパブリッシャーと一緒に調整していく協働の成果物なのだと知ったことです。そして「簡潔に書いてほしい」というフィードバックを初めて受けたときに感じた戸惑いも、実は好みの対立ではなく、同じ目標を異なる立場から異なる方法で実現するという視点の違いだったのだと分かりました。フィードバックを受けたときは防御的に反応するのではなく、そのフィードバックがどのような場所で、どのような理由から出てきたのかを、まず理解しようとする姿勢が必要だということも学びました。
結局、UXライティングとは自分を削ぎ落とすことでした
ボタンの文言が長くなると、開発側では例外ケースが増え、パブリッシング側では改行やボタンのサイズが崩れる問題がすぐに起こります。「親切に」書きたいという思いで長くした一つの文章が、ほかの職種の作業にも影響する。そう知ってから、ボタンを簡潔に書いてほしいというフィードバックは好みの問題ではなく、複数の職種が一緒に扱う画面で守るべき最低限のルールに近いものなのだと理解しました。
振り返ってみると、UXライティングをうまくやりたいという思いの始まりは、「自分が理解させなければならない」という負担感でした。しかし実際に必要だったのは、私のやり方で親切に書くことではなく、それぞれの画面や要素に合ったトーンを区別する感覚でした。ボタンにはボタンの役割があり、説明文には説明文の役割がある。それを認めること。そして、その役割を決める基準は私の好みではなく、ユーザーがその画面で実際に何を必要としているかであるべきだということです。
Eykim