マイクロコピーの改善に役立つユーザビリティテスト
Oct 13, 2021この記事はPrototypr.ioのブログ: How Usability Testing Improves Microcopyの翻訳転載です。著者のキネレット・イフラさんの許可を得て公開しています。
新しいプロダクトのUXライティングのプロジェクトに取り組む時、私は必ずそのテーマを調査し、ユーザーの意見を聞いたり読んだりして、ユーザーがどんな言葉を使っているのかを調べます。また、クライアントのゴールやプロダクトで何を実現したいのかをよく知り、ボタンや入力欄、言葉のひとつひとつに精通していきます。
私は、徹底的に準備をしてからライティングのプロセスに入ります。そうすることで、自分の選んだ言葉やフレーズが、より正確で役立つものとなり、プロダクトを使うユーザーのためになるのです。
なぜライティングの後にユーザビリティテストを行うのか？
それは、どれだけ下準備を済ませても、私は依然、ユーザーがどのようにそのテキストを読むのかを考えねばならないからです。
- 理解してもらえるだろうか？
- 明確な表現になっているだろうか？
- 同義語のほうがいいのではないか？
- くだけすぎていないか？フォーマルすぎないか？
- カテゴリータイトルの意味を理解してもらえるだろうか？
- ツールチップの説明は十分だろうか、それとも短すぎだろうか？
- また、使用例や画面、予期せぬ選択肢を見逃していたら？
書く前にどれだけリサーチしても、その一部は常に、自分の過去の経験や推測、さらには直感に基づいているものです。それは仕方のないことなので、それでいいと思います。すべてのデジタルプロダクトは、新しい世界を発見するためのものです。
結局、より確実な情報を集めるには、マイクロコピーがすでにプロダクト（またはパイロット版、MVP）に組み込まれた後に、ユーザビリティテストを行うしかないことがわかりました。
言い換えれば、自分たちが書いたマイクロコピーを、実際のユーザーがどのように扱うかを見て、初めて正しい言葉を選んだかどうかがわかるのです。
これこそがユーザビリティテストの目的です。
ユーザビリティテストの様子。Photo by UX Indonesia on Unsplash
では、基本的にユーザビリティテストとは何でしょうか？
ユーザビリティテストは、通常、プロダクト設計をテストするために行われます。ユーザーにプロダクトの中で特定のタスクを実行するように依頼し、実行する様子を観察することで、主に計画通りに動作しないものを特定するために行われます。「コミュニケーション擁護派」は、テスターがユーザーの操作の理由を理解できるように、ユーザーがやろうとしていることや、それをしているときに何が起こると期待するかを説明してもらうほうが良いと考えています（思考発話法）。一方で、話をするとプロダクトの利用方法が偏ってしまうので、静かに観察するのが正しい方法だと考える人もいます。私たちライターにとっては、ユーザーが話してくれるほうがいいに決まっていますし、その言葉がどのように役立つかはすぐにわかるでしょう。
ユーザビリティ・テストの実施方法
ユーザビリティテストは、ユーザビリティラボで行うことができますが（一方通行の鏡が設置されていて、ユーザーに影響を与えずに観察できるところもあれば、画面に向けられたカメラや指の動きのトラッキングを使用するところもあります）、一般のオフィスでも、Zoomを使っても、あるいはランダムなユーザーと一緒に路上でも行うこともできます。すべては、あなたが選べる手段と、プロダクトそのものにかかっています。
ユーザビリティテストがどのように行われているかをもっと知りたい方は、この記事のような情報源を当たってみてください。この記事では、ユーザビリティテストのプロセスそのものよりも、そこから何を学べるかを重視しています。
カメラが指の動きを追跡し、その映像をテスターが見ることができるスクリーンに送信する。Photo by Mohamed Boumiza on Unsplash
待てよ、なぜA/Bテストだけではダメなの？
1. なぜなら、ユーザビリティテストには、ユーザー以外は何も必要ないし、言ってしまえばユーザビリティラボさえ必要ないからです。もちろんあるに越したことはありませんが、最もシンプルなユーザビリティテスト、つまりゲリラテストでも多くを学べます。
2. プロダクトのタイトル、ボタン、ツールチップのすべてに対してA/Bテストはできませんが、ユーザビリティテストでは、たくさんのコンポーネントに関する情報を一度に得られるからです。
3. A/Bテスト（およびユーザーとのやり取りを必要としないリモートユーザビリティテストの一種であるヒートマップ）では、ユーザーがクリックしたかどうか、クリックしなかったかどうか、気づいたかどうか、使ったかどうか、使わなかったかどうかはわかりますが、どのような言葉に戸惑ったのか、どのような言い回しをすればわかりやすかったのか、という理由はわかりません。ユーザーが議論したり、考えたり、混乱したり、理解したりしながら発言するユーザビリティテストでは、私たちが編集した（あるいは、悲しいことに編集しなかった）マイクロコピーについて、より多くを学べます。
本番に臨む前に、3つの提言
1. 実際にテストに参加する
デザインテストとは別に、マイクロコピーに特化したユーザビリティテストの実施が予算的に可能ならそれが理想的です。ほとんどの場合、テストの予算は（あったとしても）1セット分しかなく、大抵はそれをデザインテストに回すことになります（テストのための予算や時間がなくても、テストを行う方法がありますが、それは後ほど説明します）。
いずれにせよ、ユーザビリティテストが実施される際には、事前にあなたから「その場にいたい」ということを伝えておきましょう。もちろん、いつもうまくいくわけではありません。時には、彼らにリマインドしたり、申し出たり、あるいは「このコピーはユーザビリティテストでテストしなきゃね」とさりげなく言ったりしなければなりません。言い換えれば、ユーザビリティテストの場にいるためにあらゆる努力をすることです。テストがZoomで行われている場合は、録画を要求してください（そして、テストを実際に録画していることを確認してください）。
プロダクトチームやデザインチームに、あなたの代わりに言葉に気を配るように頼まないほうがいいでしょう。なぜなら、彼らは言葉よりも全体のフローに注意を払うことで精一杯だからです。彼らは、例えば、ユーザーがうまく操作できない場合には気づくでしょうが、ユーザーにとって問題のある言葉や不足している言葉を見つけ出す方法を知らないでしょうし、それこそが私たちが知りたいことなのです。
この記事では、マイクロコピー、単語、言葉の選択、言い回しについて、ユーザビリティテストから学べることだけに焦点を当てます。特定のプロダクトでユーザビリティテストを行ってわかったことをお話ししますが、ここで言うことはすべてのプロダクトに当てはまります。
2. 参加者の選定、スクリプト（脚本）の作成に参加する
ユーザビリティテストを計画しているのは、通常、プロダクトチームとデザインチームです。彼らは、性別、年齢、民族、地域など、さまざまな属性のサンプルを用意することでしょう。
また、言語認識の観点からもサンプルの多様性を確認しなければなりません：例えば、私は自分の母国語であるヘブライ語で書いているので、アラビア語を話す人やイスラエルの場合は移民など、母国語が異なる参加者を招待するようにします。また、私は40代なので、65歳以上の参加者やティーンエイジャーなど、プロダクトの体験や語りかけ方の異なる参加者にも参加してもらいたいと思います。
スクリプトについて：ユーザビリティテストでは、プロダクトの使用前、使用中、使用後に参加者に質問するシナリオと質問事項があらかじめ書かれた台本に沿って行われます。シナリオの選択にはあなたも参加し、疑問に思うマイクロコピーについて質問を追加してください。
- このボタンをクリックするとどうなりますか？
- このタイトルからどんなコンテンツを想像しますか？
- このテキストから何を理解しましたか？
- この2つのカテゴリーの違いは何だと思いますか？
3. もしあなたの会社がユーザビリティテストを行っていなければ、自分でやってみてください。
ゲリラテスト（最小限の計画とリソースで行うテスト）でも、かなり重要な情報が明らかになりましたし、実施はとても簡単です。
あなたがすべきこと：
- ズームセッションの日時を5人で設定してください。1人あたり30～60分、最低でも15分のインターバルを設けます。
- ユーザーにプロダクトを起動してもらい、画面を共有してもらいます。
- プロダクトを使ったいくつかのタスクを与えて下さい。そのプロダクトで最もよく行うタスクや、設計者として確信の持てないタスクを与えるとよいでしょう。
- .ユーザーに、見たものややったことを説明してもらいましょう（話すのが苦手な人であれば、あなたから聞いてみるのもいいでしょう）。
- 上のスクリプトで紹介した例のように、不明な点は具体的に質問してみましょう。
- すべてを録画しておけば、リアルタイムでテストに集中できます。後から見直して、具体的な内容や言い回しに注意することができます。
もっと効率的なユーザビリティテストの方法がありますが、このようなゲリラ的なテストであっても、コストゼロで、1日か2日の作業でたくさんの価値ある情報を得られます。
マイクロコピーの改善に役立つユーザビリティテスト
1. ユーザビリティ・テストは、私たちが書いたコピーが明快かどうか（あるいはわかりにくいのか）をはっきりと教えてくれます。
最終的な言い回しは、言葉を動かしたり、書き加えたり、編集したり、縮めたり、十数人もの異なる意見に耳を傾けた上で、明快になっているでしょうか？
プロダクトや機能が複雑であればあるほど、この問いが存在し続け、プロダクトの中で何度も出てくることになります。これは避けられないことであり、完全に仕事の一部であり、ユーザビリティテストだけが答えを知っています。
例A
データの複雑さと法律要件のために、非常に複雑な説明書を書かなければならないことがありました。説明書は、a)データについて説明する、2)データを制限する、3)特定の行動を促す、4)短く簡潔にする、というものでした。何度も何度も繰り返して、少なくとも誰が読んでもわかりやすいと思える文章にしようと試みました。
しかし、ユーザビリティテストの結果、全体を通じてユーザーが文章を理解していないことがわかり、その結果、関連する操作画面を誤って操作してしまうことになりました。私のミスは、説明を具体的にしすぎて、ユーザーを混乱させてしまったことです。対策は？ユーザーの立場に立った表現をすることです（基本ですね）。「Xに該当する可能性のあるデータのみ表示」と書くのではなく（専門的には最も正確な表現ですが）、「Xに興味がある」と変更しました。
これは、マイクロコピーを書いているときに見落としていたことで（ユーザーの視点で書くこと以上に初歩的なことがあるでしょうか）、ユーザビリティテストで初めて判明しました。ユーザビリティテストは、謙虚さを学ぶのに最高のレッスンであり、決して手放してはいけないものです。
例B
ある画面で、かなり複雑なツールチップが表示されていたのですが、ユーザーは最初の一文で読むのをやめてしまうことに気づきました。続けて読んでいれば答えが出ていたはずなのに、オプトアウトしてしまい、そのまま放置されていたのです。そこで私は、ツールチップの最後の行を最初の行にすることを提案しました。最重要項目にたどり着く前に、何らかの背景を説明しなければならないこともあれば、最重要項目を先に説明しなければならないこともあります。何が正しいのかはユーザビリティテストでしかわかりませんが、個別のケースに合わせて判断します。
例C
ユーザーは、ライターやデザイナーが思いも寄らないようなほどに重要な説明を見落としていることがあります。そして、ユーザビリティテストを行ってみると、なんと誰も読んでいないことが判明します。それだけではなく、本当に探そうとしても誰も見つけられないことが判明しました。私が経験したのは一度や二度ではありませんでした。その倍はあったでしょう。解決策としては、ビジュアル要素の変更（フォントを大きくする）や、テキスト要素の変更（重要な情報を、ユーザーが手を止めて読むような別の要素に組み込む）があります。
2. ユーザビリティテストでは、考えもしなかった問題が明らかになる
場合によっては確信が持てないことがあります。シンプルでわかりやすく、言い回しも優れていると思っていても、ユーザビリティテストの日になって、びっくりします!
例A
スライダーの上に表示されているある特定の単語が、ユーザーに間違った操作をさせていました。ユーザーの中には、はっきりとこう言った人もいました。「Xって書いてあったから、てっきり...」
例B
たくさんの統計データを画面に表示するプロダクトにおいて、「平均」という言葉を複数の箇所で使用すると、ユーザーは互いに無関係な平均値を比較してしまいます。そこで私たちは、「平均」という言葉を使う場合には、「市場平均」「年間平均」など、長くなってもいいから別の言葉を付け加え、それでいて可能な限り言葉を短くできるようにしました。
例C
ドロップダウンメニューの初期設定は「すべてのカテゴリー（All categories）」となっており、ユーザーは何も選択する必要がなく、そのままにしておくことができました。ユーザーの中には決めかねている人がいるだろうと思い、すべての選択肢を残しておきたかったからです。
実際にユーザビリティテストを行ってみると、決めかねているユーザーであっても、「選ばなければ」と感じていることに気づきました。彼らは単に、デフォルトの選択肢を理解していなかったのです。「すべてのカテゴリー」というのは、よくある標準的なドロップダウンの表現なので、この反応にはとても驚きでしたが、そもそも私たちがユーザビリティテストを行っていたのは、まさにこれが目的だったのです。そこで、デフォルトを「まだわかりません（I don’t know yet）」に変更しました。
例D
このサイトには一連の検索フィルターがあり、ユーザーは自分の好みを選択して結果を得ることができました。その時に、私たちが表示していた見出しは「あなたの好みに合った結果」でした。
しかし、ユーザビリティテストの結果、私たちには事前に気が付けていなかったことが2つありました。1つ目は、この見出しが、好みが選択されていないフリー検索の結果の上にも表示されていたこと。2つ目は、技術的な制限により、最初の検索結果が（非常に）部分的にしかマッチしないことです。
どちらにしても、「あなたの好みに合った結果」という約束は、果たされておらず、これはユーザビリティテストでしかわかりませんでした。私たちは、タイトルを「X個の結果が見つかりました」というような、重要な情報にのみフォーカスしたものへ変更することを提案しました。
3. ユーザビリティテストで適切な言葉を引き出す
例A
ユーザーがその意味を説明するたびに、大笑いしてしまうようなヘッドラインがありました（ご心配なく。Zoomの録画だったので彼らはこのことを知りません）。誰もが例外なく、自分が今見ているデータを表現するのに全く同じ言葉を使っていたのですが、それは私がチョイスしていた言葉ではありませんでした。明らかに、その言葉を変更しなければなりませんでした。そして幸運なことに、何を変えるべきかわかっていました。簡単ですね。
例B
別の例では、アイテムを分類し、そのカテゴリーに名前を付けました。しかし、ユーザーはその違いを理解できず、別の言葉で表現していました。そこで私たちは、専門用語とユーザーの言葉の両方にフィットするように、カテゴリーとその定義を変更できないか、チームで検討しました。
ユーザビリティテストで見つけたものすべてをすぐに修正できるわけではありません。業務上の制約がある場合もあれば、そうでない場合もありますが、少なくとも問題があること、思った通りに動いていないことはわかりました。あとは解決策を見つけるだけです。
4. ユーザビリティテストでは、良くも悪くもユーザーがサイトをどのように表現しているかがわかる
ユーザーの声に耳を傾け、彼らが何をどのように評価しているのかを直接理解することに勝るものはありません。そうすることで、プロダクトの機能や価値を正確に表現し、ユーザーのニーズや要望にダイレクトに応えることができるのです。
その結果、次の2つのことが明らかになりました。
1つは、ユーザーがこのプロダクトをとても楽しんでいること。
ユーザーからは、「数字をいじるのが楽しい」「もっと掘り下げてみたい、楽しい」「こんな風に見るのも楽しい」「こんな風に検索するのも楽しい」などの声が寄せられ、この反応は本当に驚きでした。もちろん、このプロダクトが素晴らしく、ユーザーの興味を引くものであることはわかっていましたが、まさかユーザーが「楽しい」と表現するとは思ってもいませんでした。この新しい知識をどのように使うかはわかりませんが、雰囲気が変わって面白くなることは確かです。
2番目に目立ったのは、誰もがスピードについて話していたことです。「駆け足で見て、すぐにすべてを見つけた」「迷うことなく、ただひたすらに検索できる」「探していたものがすぐに見つかる」「欲しいものを見つけるのが簡単だった」「楽勝だった」。
これらのユーザーの声をサイトの文章に取り入れて、どうなるか見てみるのも面白いかもしれません。
5. ユーザビリティテストは、自分たちが良い仕事をした箇所を教えてくれる
ユーザビリティテストは、ミスをピンポイントで指摘してくれるので、私たちを落胆させることがあります。しかし、苦労して作ったマイクロコピーのほとんどは、テスト中には出てこない可能性が高いのです。これは良い兆候で、ユーザーは単にそれを読んで次に進むだけだからです。
例A
ユーザーが大きな声で質問をして、ツールチップで答えを探しているとき、私は心臓が止まりそうになります。果たしてツールチップは、彼らの質問に正確に答えてくれるだろうか？最初から明確な答えが返ってくるだろうか？私が理解してほしいことを正確に理解してもらえるだろうか？
そして、彼らがそれを読み、すぐに理解し、間髪入れずに正しい選択をしたとき、私は安堵のため息をつきます。満足感でいっぱいです。
例B
ユーザーが見出しを声に出して読み、それが正確であること、ちょうど良い位置にあること、次に何を見ようとしているのかを、正確に理解できていると自分自身で実感できたとき、大きな二重丸を付けることができます。
例C - 性差のある言語で書くライターのために
ヘブライ語は性を区別して表す言語であるため、（よく考えた末に）メインのコールトゥアクションは二人称単数形にして性別をできる限り排除し、次の指示では二人称複数形（性別を問わない）にすることにしました。これは、テキストの一貫性がないことを意味しますが、ユーザーに行動を呼びかけるにはぴったりな方法であり、これが多くの指示を、わかりやすくシンプルにまとめる方法だと考えました。
したがって、計画どおりにすべてがうまくいっているこれらすべての場所に注意を払うことを忘れないでください。というのも、ユーザビリティテストは、うまくいっていない部分を明らかにするだけでなく、私たちの仮説を検証するために行われるものだからです。また、最終的には自分たちが良い仕事をしたということを思い出させてくれるのです :)
