All Turtles 創業メンバーが語る、UXライティングの重要性

All Turtles は2018年7月、東京オフィスを構える WeWork 丸の内にて「シリコンバレーのUXライターが語る、UXライティングの重要性」というイベントを開催しました。本投稿は、本イベントにご参加いただいた Mai Sato さんの note への投稿を、了解を得て編集した上で掲載したものです。

当日のセッションは、スピーカーの Jessica Collier が英語で話しながら、随時日本語通訳する形で行われました。

Opening

まずはAll TurtlesのCEOであるPhil Libinからご挨拶させていただきました。

スピーカーである Jessica Collier と Phil は、2014年ごろに Evernote で一緒に仕事をしていました。そして数年後の2017年、プロダクト・ファーストを掲げる All Turtles の創業メンバーとして Phil が真っ先に迎え入れたいと思ったのが彼女だったのです。

Phil 自身も Evernote で Jessicaと仕事をするまでは、UXライティングが何なのか、その価値がどこにあるのか、深く理解はしていませんでした。しかし彼女の仕事に触れてUXライティングの重要性を理解し、その後は開発時にビジュアルやプログラミングに重きをおくのと同様に、言葉にも細心の注意を払うようになったのです。よく考えると、私たちが触れる様々なプロダクトやサービスは多くの“言葉”で構成されていますので、肝心の言葉を後回しにするなんて間違っていました。ことさらAI時代においては、プロダクトとのコミュニケーションが会話形式で行われるなど、“言葉”はますます重要な要素になるはずです。

以下、Jessica の講演を、実際に使われたスライドと共にご紹介します。

Section 1: Why UX writing?

まず多くの人に聞かれる「なぜUXライティングが必要なのか?」について。答えはシンプルで「Words are everywhere」、つまり「言葉はいたるところで使われているから」。

例えば、Dropbox のプロダクトのインターフェースには27,000以上のメッセージが使用されているそうですが、これらの言葉はユーザーに機能を理解してもらい、ユーザーが求めるものを与え、ユーザーが望む目的の達成へと導くために使われています。つまり、これら局面で使われている言葉のひとつひとつが、プロダクトやユーザー体験そのものの良し悪しを左右すると言っても過言ではないでしょう。

プロダクト開発においてよくある失敗は、このように起きます。つまり、マネジメントはマネジメントの言葉、エンジニアはエンジニアの言葉、そしてPM、デザイナーなどプロダクトに関わるメンバーが、各々の価値観をベースにした異なる言葉をプロダクトに注ぎ込んでしまうような場合です。

その結果、ユーザーの体験は断片化され、プロダクトのあちこちにに矛盾が生じます。ユーザーはまるで様々な方向から沢山の人に話しかけられているような感覚に陥り、混乱してしまうでしょう。

プロダクトに「シンプルである」(簡単さ、分かりやすさ)ことを求めるほど、どのような言葉を使うかは非常に重要です。洗練されたワードほど自然で違和感を与えませんし、結果としてユーザに意識されません。ビジュアルを作るにも、無駄のないデザインほど難易度が高いのと同じかもしれません。

Section2: What is UX writing?

では、具体的にUXライティングとは何なのでしょうか?
All Turtles の同僚で、Principal UX Writer である Lisa Sanchez に意見を求めてみました。

設計を行う際は、「誰が」「どこで使うのか」が、言葉選びに大きく影響します。

また、パリなどで活躍するUXライターの Becky Hirsch の意見はこうです。

言葉そのものよりも、その背景の思想や哲学、意図の方が大事だと言っています。

どういうことかというと、UXライターは、言語学(言葉)にフォーカスしつつも、Human Centered Design やプロダクトの戦略についても考える必要があるからです。つまり、具体的にインターフェイスに表示される言葉を何にするか…というのは仕事のごく一部だということ。そして、その言葉を考えるためには情報構造(IA)、フロー、利便性を意識し、どのタイミングでどの情報を提示するかを検討し、コトバの統一感を維持し、全ての環境やUIで使えるようなシステムを開発する必要があるのです。そしてそのシステムを誰でも使えるように、単語の意味合いを管理するリストを作ったりもします。

シンプルにまとめると、
「私たち UXライターは、Web やモバイルプロダクトのインターフェイス・コンテンツを企画・開発している」ということになります。

Section3: About UX writers

UXライターが、いわゆるライティング以外にも様々なことをすることを分かっていただけたと思います。しかし、まだまだ謎多き職業なので、Section3 ではもう少し詳しく見ていきます。

UXライティングは他にも「コンテンツ・デザイン」「プロダクト・コンテンツ戦略」「プロダクト・ライティング」などと呼ばれたりします。UXライターという職種の呼び名が登場したのはここ5~6年のことで、Jessica が初めてUXライターという肩書きを持ったのは、2014年に Evernote に参加した時でした。ただ実際の仕事内容としては、それ以前からやっていることは変わっていません。(そして今やアメリカでは、少なくともシリコンバレーの先端企業のほとんどで「UXライター」という職種が存在しますし、採用競争も激しいです。

Jessica は英文学の博士号を持ち、大学でライティングの講義も行なっていました。もしUXライターに興味がある、それを目指したい、という人がいたら、以下の3つが求められることになるでしょう。

まず、言語学のバックグラウンド。次にプロダクトの設計やプロセス・UX原則の理解。そしてもっとも重要なのは、問題解決に対して共同で取り組む姿勢です。
UXライターは、決して一人で部屋に閉じこもって黙々と作業するような仕事ではなく、毎日デザイナーをはじめとするプロダクトに関わる様々な人とやりとりをし、協働する仕事だからです。

Section4: UX Writing Tips

ここからは、UXライティングのコツについてお話しします。

lorem ipsum、つまり「ダミーテキスト」を使わず、最初から限りなくリアルなコンテンツやテキストを使うことが重要です。これは一見手間がかかりそうですが、これをやっておいた方が最終的に開発は合理的に進められます。(実際の意味を持った言葉が入っていないと、ユーザーテストも行えません。)

ライティングも、下書き→修正→削るという工程は必ず発生します。
意味のない言葉を使うのは避け、はじめから何らかの意味のある言葉(下書き)を使い、プロダクトの開発過程で一緒に洗練させていくべきです。

新しい言葉を作り、あわよくばそれを流行らせたい!と思っても、それはユーザーを混乱させるだけでなく、自分の首を絞めることにもなります。避けた方が無難です。

英語の世界では大文字・小文字の使い分けには明確なルールがあり、これを守ることは重要です。もちろんUXライティングの世界でも注意すべきで、例えば、note(一般名詞)でいいのに、あえてNote(固有名詞)とするようなことも、その言葉によほど大きな意味がない限りは避けましょう。

UXライティングに限らずですが、細部への気配り(ひとつひとつの言葉選び)がプロダクトの差を生みます。Jessica はいつも重箱のすみを突くようにチームに指摘して嫌がられるのですが(笑)、イームズの言葉にあるように、神は細部に宿ります。
“The details are not the details. They make the design” – Charles Eames

ユーザーの声を聞くには、もちろんユーザーテストをするのも良いです。そしてユーザーの使う言葉を最もよく知るであろう、カスタマーサポートのチームと対話するのもとてもオススメです。

ユーザーがその時々に必要な情報のみを、その都度に提供する方がよっぽど使い勝手が良いサービスになります。これはご存じの Progressive disclosure (段階的開示)という手法です。

デザインの美しさよりも、機能的であるかどうかを重視すべきです。UXライティングとの関係で言うと、例えば言葉を使った方がいいか、それとも画像など他の方法がいいかを考えねばなりません。ユーザーへの各種案内はいつも言葉だけで完結できるわけではなく、時にはビジュアルの方が伝わりやすかったりもします。言語とビジュアルに根源的な優劣があるわけではないので、ユーザーの目的達成のために効果的な方を都度検討しましょう。デザイナーとUXライターの間で争っても仕方ありません、ユーザーに一番わかりやすい方法を採用すべきです。
“Form follows functions.” – Louis Henry (Henri) Sullivan
参考:IDIA.JP

プロダクトやサービスの中で使う用語集を作っておけば、チームメンバーから「あれは何と呼ぶんだっけ??」と毎日質問責めになることはありません(笑)。
UXライターが理想とすべきなのは、プロのライターでなくても誰もがプロダクトに関わるライティングできるようになり、みんなでプロダクトを作っていけるようになることです。

Section5: UX writing in the wild

ここからは、実際のプロダクトにおける良い例、悪い例を見ていきます。

BAD EXAMPLE 1

・Evernote の初期の頃のメッセージで、恐らく Phil 自身が書いたもの・・(Phil はもともとはエンジニア)
・エラーのメッセージが長く、何が問題なのかパッと見ではわからない
・選択オプションに「NOT RECOMMENDED」が含まれている
・エラーのメッセージなのに、アクションボタンが「OK」

エラーメッセージは、ユーザーに何が問題なのかを端的に伝えるべきですが、それができていません。また、推奨もしない選択肢を提示する必要はあるでしょうか?エラーメッセージに対してOKボタンは不自然では?という例でした。

BAD EXAMPLE 2

・「Rules could not be saved because there is an error in the rules(ルールズに間違いがあるのでルールズは保存できませんでした)」という、トートロジー的なエラーメッセージの例
・「間違いがあるからエラーになっています」、のような、意味のわからない表現になってしまっている

メッセージそのものはロジックとして間違っているわけではないが、ユーザーが次に何をすべきかが分かりづらい例。

BAD EXAMPLE 3

・ユーザーに、「メール受信のオプト・インをしてください」とお願いしている
・2つの選択肢を与えているが、「YES」か「YES, but once a month」の二択で、結局YESしか選べない

Closed Question(択一)でありながら「NO」という選択肢がなく、結果的にユーザーを騙すような体験は望ましくありません。

BAD EXAMPLE 4

・とある公共性の高い金融サービスのサイトで、「+ADD A TILE」という機能ボタンが使われている例

“Tile”というUIエレメントの単語がそのまま使われていますが、その意味をどれくらいの人が理解できるでしょう?老若男女問わず様々な人がサービスを使うことを想定すると、言葉の選択が好ましくないと言える例です。

BAD EXAMPLE 5

・とある共同編集ツールでしばらく作業をしなかった結果「Wow! This doc has changed a lot.(おっと!この文書はたくさん編集されていますよ!)」というメッセージが出て、リロードを促される

まるで「あなたがサボっている間、同僚が一生懸命働いていましたよ・・・。リロードしてね!」と言われているような、罪悪感をユーザーに抱かせてしまう言い方です。使う表現は常にそのサービス特性(作業効率化ツール、仕事のシーンで使われること)を考慮すべきで、メッセージのトーンを間違えると、時にユーザーを不快にさせてしまうという例です。

GOOD EXAMPLE

HEADSPACE
瞑想用のアプリで、全体的にUXライティングをうまく取り入れているプロダクトです。スマホの通知許可を求めるメッセージの好例として紹介します。
例えば「通知」の許諾を得る際のメッセージ。通常ユーザーの”邪魔をする”ことに対して許可を求めるものですが、その”邪魔すること”が、ユーザーにとってメリットがあることをわかりやすく伝えています。

GOOD EXAMPLE

Pinterest
法務系の言葉は往々にして難しいものですが、Pinterest の「Terms of Serviceは大切な部分だけを平易な言葉で要約しています。
ユーザーに知らせるべき大事なポイントをきちんと伝えている、とてもいい事例です。

Resources: Learn more about UX writing

最後に、UXライティングについてもっと知りたい!と思った人へ。

▼Books
Nicely said: Writing for the Web with Style and Purpose
Nicole Fenton and Kate Kiefer Lee

▼Articles
How to design words
John Saito

What is UX writing
Lisa Sanchez

Product content at each stage of a project
Biz Sanford

UX writing: A lesson in letting words go
Becky Hirsch

Our Narratives, Ourselves
Jessica Collier

▼Design Systems
Google’s material design, communication

Shopify’s Polaris, Content

▼Style Guide
Mailchimp’s Voice and Tone

Mailchimp’s Content style Guide

Google’s developer Documentation Style Guide

Tuts+ Style Guide

Drupal’s Content Style Guide

ーーーーーーーー

本投稿は、本イベントにご参加いただいた Mai Sato さんの note への投稿を、許可をいただいて編集したものです。Mai Sato さんのコメントつきのオリジナルも、是非ご覧ください。