こんにちは！テクニカルコミュニケーションチーム（以下、TC）の原嶋です。
先日公開したPart1・Part2に続いて、このPart3では、TCメンバーの米山、中島、山本のお気に入り動画を紹介していきます。
TCで開催した動画勉強会のレポートブログは、この記事で完結します。
この記事は、下記の記事の続きです。
ライティング力向上！テクニカルライターが見て良かった動画 -1年間のまとめ- 【Part1】
ライティング力向上！テクニカルライターが見て良かった動画 -1年間のまとめ- 【Part2】
動画5：完璧なエラーメッセージの書き方
GaroonのUI文言を中心に担当している米山です！私からは、James ScottさんがWrite the Docs Prague 2019で発表した"How to write the perfect error message"という動画を紹介します。
この発表では、エラーメッセージを書くときに気をつけたいポイントを紹介しています。本当にたくさんのポイントが紹介されているので、詳しくはぜひ動画を見ていただきたいです。が、それだとこのパートが終わってしまうので（笑）
ここでは、James Scottさんがまとめた「HACK」に沿って、ポイントをいくつか紹介します。
- H：Helpful, Humble, Human, Humor
- A：Audience, Accessibility
- C：Concise, Clear
- K：Knowledge
一つずつ見ていきましょう。
H：
- Helpful（役立つ）
エラーメッセージは、ユーザーにとって役立つものである必要があります。エラーが起きた原因だけでなく、解決策もできるだけ書きましょう。 - Humble（謙虚）
たとえユーザーのミスであっても、ユーザーを責めるようなメッセージにする必要はありません。謙虚なメッセージを心がけましょう。 - Human（人間らしさ）
人間らしい表現にすると、ユーザーは製品に共感を持ってくれます。専門用語をたくさん使うと、ロボットのような印象を与えるので、注意しましょう。 - Humor（ユーモア）
ユーモアは製品とユーザーの距離を近付ける効果がある一方で、使う場面を間違えるとユーザーにストレスを与えてしまいます。
Scottさんは、次の点を特に注意しているとのことです。- 警告にユーモアを入れない
- 頻繁に発生するエラーや、フラストレーションがたまるエラーにはユーモアを入れない
- ユーモアを含む文を翻訳する場合は、原文のコンテキストが正しく共有されないことがある（翻訳時に配慮が必要）
- 見つけたらラッキーとユーザーが思ってくれるくらいの、主張しすぎないユーモアにする（Best as an Easter Egg）
A：
- Audience（ユーザー）
どのユーザーに向けたエラーメッセージなのかを意識しましょう。
対象が一般ユーザーなのか、システム管理者なのか、もしくはAPIを使う開発者なのかによって、伝えるべきメッセージは変わります。 - Accessibility（アクセシビリティ）
スクリーンリーダーなどの支援技術を使ったときにも伝わりやすいエラーメッセージを意識しましょう。
C：
- Concise（簡潔）
エラーメッセージは簡潔にします。文章の長さを短くすると、読者の理解度が高まるという調査結果があります。 - Clear（明確）
エラーメッセージは明確に書きましょう。曖昧なエラーメッセージを見ると、ユーザーはイライラしてしまいます。
K：
- Knowledge（知識）
良いエラーメッセージは、ユーザーに知識を与えます。
HACKをまとめると・・・
「エラーメッセージを、ユーモア（Humor）に注意しながら、役立つ（Helpful）、謙虚（Humble）で人間らしい（Human）内容にするには、ユーザー（Audience）やアクセシビリティ（Accessibility）に配慮し、曖昧さや専門用語を避けて簡潔（Concise）で明確（Clear）な書き方にすると、困った状況を解決するための知識（Knowledge）をユーザーに提供することができるでしょう！」ということになります。ちょっと長いですね（笑）。
この「HACK」は、エラーメッセージを考えるときのポイントとして、意識したいことがまとまっているのではないかな？と思います。
動画の中では他にも「エラーメッセージにキャラクターを起用するのはどうだろうか？」など、身近な製品を事例にした面白い話をたくさんされています。興味のある方は、ぜひ動画をご覧ください！
動画6："Simply"って言わないで！
TCチームで、ローカライズや機械翻訳を担当している中島です。私が紹介する動画は、Write the Docs Prague 2018で発表されたDon't say "simply"です。極めてシンプルなタイトルですね。
動画は、スピーカーのJim Fisherさんの経験談から始まります。Macでアプリをインストールする際に、WindowsユーザーだったFisherさんはダウンロードしたファイルをダブルクリックしました。アプリは動いたのでインストールは完了したと思い込みましたが、しばらくして同僚に間違いを指摘されます。ダブルクリックは、ダウンロードした拡張子.dmgの圧縮ファイルを展開しただけで、アプリをMacにインストールするには「アプリケーションフォルダにドラッグ」するのが正しい操作だったのです。WindowsとMacの仕様の違いによって起こる操作ミスは、私も同じような経験があり容易に想像できました。
このスクリーンショットのようにSIMPLY DRAGと表示されていたことに気付かなかったFisherさんは、聴衆に語りかけます。
「本当にこのMacのインストール操作はシンプルなんでしょうか？」
そしてsimply (簡単)を使うべきではない理由として、Fisherさんは次の5点を挙げています。
"simply"は操作が主であり、コンセプトのことを考えてない。
上のMacの例なら、インストール操作はドラッグだけかもしれませんが、そのドラッグでアプリケーションがどうやってインストールされるのか、その概念全体はもっと複雑です。"simply"という言葉は主観的である。
何を"simply (簡単)"と思うかは、操作している人に大きく依存しますね。読み手の気分を害してしまうかもしれない。
"simply"と書いてある操作ができないと、読み手は「自分はこんな簡単な操作もできないのか」と恥ずかしい気持ちになってしまうかもしれません。特に開発者は"simply"を使いがちなので注意が必要です。書き手は、怠けずに具体的に内容を説明するべき。
難しい概念が出てきても、目を背けて"simply"と書いたりせず、明確に説明する努力をしましょう。数字、たとえば「3分でセットアップ」とするのも一案ですが、その場合には本当に3分で終わるのか、ビデオなどで根拠を示すことも必要です。"simply"は意味のないつなぎ言葉で、なんの情報も提供していない。
"Simply drag"(ドラッグするだけ)なら、"Drag"(ドラッグする)で十分ですね。もちろん、"simply"という単語を全面禁止すればいい、というわけではありません。
結論として、Fisherさんは「自分が何を伝えたいかをしっかり把握し、読み手の理解がより深まるように、単語の意味を考えて使いましょう」と伝えています。私も、日本語の文章では「簡単に」「～するだけで」を安易に使わないようしたいですし、英訳する際にも"simply"を連発しないように気を付けたいと思います。
動画7：インクルーシブなデザインを実現するわかりやすいプロセス
Garoonのヘルプサイトを担当している山本です。 わたしは、Google I/O 2018から"An accessible process for inclusive design"という動画を紹介します。
この動画では、下記を話されています。
- どのチームでも使用できる、よりインクルーシブにデザインするためのプロセスの紹介
- インクルーシブデザインを考えるにあたって、MATERIAL DESIGNのガイドライン、ツール、およびコンポーネントがどのように役立つか
2018年に開催されたイベントの動画ではありますが、ちょうど社内で開催されているアクセシビリティの勉強会に参加しているTCメンバーがいることもあり、この動画でさらに理解が進むといいなというので見始めました。動画自体は、アクセシビリティについて今まで学んだことの総復習といった位置づけの内容です！定期的に見直したいなと思っています。
動画の構成は次のとおりです。少しずつ内容を紹介します！
- プロダクトビジョン（The product vision）
- デザイン（Design）
- インタラクションデザイン（Interaction design）
- ビジュアルデザイン（Visual design）
- UXライティング（UX writing）
- モーションデザイン（Motion design）
- ユーザーと話をしよう（Research）
- 開発（Development）
- 開発のあとに（After development）
1. プロダクトビジョン
もし、これからあなたがプロダクトのビジョンを定義しようとしているなら、ユーザーと話をしましょう。
障がいを持つユーザーと対話をしよう
わたしたちは、人生のどこかでアクセシビリティを必要とします。 開発の初期段階で、ユーザーと話す機会があるなら、そこに障がいを持つユーザーに入ってもらうといいですね。
下記のような質問の過程で、今まで思いつかなかった別の方法を思いつくこともあります。- どんな支援技術を使っていますか？どんな状況で使いますか？
- 障がいを持っていることが、操作にどう影響していますか？または影響していないですか？
- 支援技術がなかったとしたら、どんな代替手段を使って、目的を達成していますか？
- 各質問のあとには、障がいを持つユーザーのニーズにたどり着けるように、「もっと教えてください」と掘り下げてフォローアップしましょう。
支援技術をエキスパートから学ぼう
自分でスクリーンリーダーなどを試すのも良いですが、一番はエキスパート（支援技術を日々使用している人）から学ぶことです。 より良い体験をすべてのユーザーに提供することは、潜在的なマーケットシェアを獲得することにも繋がります。
2-1. インタラクションデザイン
すべてのユーザーにとってアクセシブルで使いやすい体験にするには、どのようにデザインすればと迷うかもしれません。 その場合は、「次のポイントに気をつけて、いつもどおりデザインしてみてください」とアドバイスされていいます。
コントロールとラベルをグループ化する
レイアウトをデザインするときは、関連するコンテンツやコントロールがグループ化されて近接していることを確認しましょう。
近接させることで、運動機能障がいを持っている人にも理解しやすくなります。タブのインタラクションモデルをデザインする
キーボードのタブを使って操作できることは、ユーザー体験を向上させますよ。
矢印キーを使えるようにすると、さらにいいですね。
2-2. ビジュアルデザイン
たとえば、灰色の背景色に、灰色のテキストが書いてあったら、読みにくいですよね。
ビジュアルデザインの改善ポイントは、次の3つです。
高いカラーコントラスト
アクセシブルにするためにカラーコントラストを高くしましょう。
見ためがよくなるだけでなく、テキストも読みやすくなりますよ。
画面上の重要な要素がはっきりするため、行動してほしいアクションもわかりやすくなります。複数の手がかり
重要な要素の状態を表示するときは、指し示すものを複数用意しましょう。
色覚多様性に配慮して、アイコンを追加するなどして、色以外でも認知できるよう、補足情報を追加するといいですね。大きなタッチターゲットサイズ
タッチターゲットのサイズは、ユーザーが操作しやすいよう十分なサイズをとりましょう。- モバイルの場合
タッチターゲットのサイズは（48dp×48dp）、7ミリの幅で、大人の指のサイズに合わせて調整します。 - Webの場合
フォーカスがあたっているところがよく見えるようにします。
- モバイルの場合
2-3. UXライティング
表示されているテキストだけでなく、スクリーンリーダーで読み上げられる文言も重要です。
スクリーンリーダーはコントロールタイプを自動的に読み上げてしまうため、ボタンのラベルであれば何をするボタンなのか、意味のある簡潔なラベルをつけるようにしましょう。
2-4. モーションデザイン
ロービジョンの方も気づきやすくなるよう、晴眼者であっても見逃すことがないよう、注意が必要ですね。 モーションデザインをアクセシブルにするには、次の2点に留意しましょう。
アラートの表示時間が長くても、簡単に解除できる
誰でも見ることができるように、アラートは十分な時間表示するようにしましょう。
不必要になったら消せるように、閉じるボタンやタップアウト機能など、アラートを簡単に閉じるオプションを準備しておくとよいですよ。拡大表示されたホバー情報を簡単に閉じることができる
拡大鏡を使って操作すると、ホバーが画面全部を覆うように表示されてしまうこともあります。
エスケープキーや閉じるボタンなどを実装して、ホバー情報を閉じれるように準備しておくとよいですよ。
3. ユーザーと話をしよう
プロダクトが完成したら、ヒューリスティック評価を実施して、プロダクトが正しい方向に進んでいるかどうかを確認しましょう。
その際には、MATERIAL DESIGNが提供する、アクセシビリティのガイドラインが役に立ちますよ。
"Is your app clear, robust, and specific?"
（あなたのアプリは、わかりやすく、堅ろうで、ユーザーが期待する支援技術をサポートしていますか？）
MATERIAL DESIGNのAccessibilityで案内されている3原則
- Clear
明確なCTA（Call To Action）を使用し、わかりやすいレイアウトをデザインすることによって、ユーザーをナビゲートするのを助ける。- Robust
さまざまなユーザーに対応できるようにアプリをデザインする。- Specific
タッチ、キーボード、マウスでの入力方法をサポートするのと同様に、プラットフォーム特有の支援技術をサポートする。
4. 開発
1から始める必要はなく、すでに公開されている有益な情報を積極的に取り入れるとよいですよ。
標準のコンポーネントを使おう
MATERIAL DESIGNのComponentを使うのも手ですよ。スケーラブルテキストを使おう
ユーザーの設定に応じて、テキストを拡大または縮小できるようにしましょう。バグバッシュやろう
定期的にアクセシビリティの観点から、修正計画を立てれるとよいですね。ツールを使おう
開発中にアクセシビリティを確認できるツールはたくさんあります。
ツールを使って自分のコードをチェックしてみてください。
5. 開発のあとに
ローンチ前
エラーや問題点が残っていないか確認しましょう。
（動画では、おすすめのツールやアプリを紹介されています。）ヘルプコンテンツ
良いヘルプコンテンツなくして、良いオンボーディングはありません。
ヘルプコンテンツは、障がいを持つ人々がよく利用するリソースです。
ヘルプコンテンツがアクセシビリティに基づいていること、実際のコンテンツもアクセシブルであることを確認しましょう。
ユーザーがプロダクトを使い始めて、行き詰まってリカバーしようとしたとき、ヘルプコンテンツがよりどころになります。ローンチ後
プロダクトの使用状況やデータ分析の結果から、ローンチがうまくいったか、ユーザーがちゃんと使っているかをチェックします。
できればユーザービリティテストを実施して、ユーザーが満足しているか、ユーザー全員がそのアプリを正しく利用できるか、確認しましょう。
このとき、アクセシビリティの観点でもチェックできると良いですね。
動画を見終えて
動画をとおして、「ユーザーと話をして、インクルーシブなプロダクトを作ることが大切である」ということを再認識できました。 障がいを持つユーザーが利用しやすいものを考えることが、結局はすべてのユーザーにとって利益につながりますね。
おわりに
Part1～Part3まである、ボリューミーな紹介記事になりましたが、皆さんの参考になれば幸いです。
振り返ってみると、ジャンル問わず色々見たな～と感じます。
根詰めて頑張る！という感じではなく、ゆるゆると続けてこられたというのが、勉強会を1年継続できた一番の理由じゃないかなと思います。無理なく楽しむって大事ですね。
また、その雰囲気にできるメンバーにも感謝です。
まだまだ見たい動画はたくさんあります！これからも、ゆるゆると勉強会を続け、学び続けていく予定です💡
