マニュアルは、製品体験の一部になっていく – Arkanos Insights

製品が多機能化すると、マニュアルに書くべきことは増えていきます。

新しい機能が追加される。
設定項目が増える。
スマートフォン連携やクラウド連携が加わる。
ユーザーごとに利用環境や契約状態も異なる。

そうなると、マニュアルのページ数は自然と増えていきます。

一方で、ユーザーは必ずしも分厚いマニュアルを読みたいわけではありません。

知りたいのは、今、自分が使いたい機能をどう使えばよいのか。
困ったときに、何を確認すればよいのか。
その場で、次に何をすればよいのか。

つまり、求められているのは「すべてを詳しく書いたマニュアル」だけではなく、必要な場面で必要な情報にたどり着ける体験です。

マニュアルを減らすだけでは、情報は消えない

以前から、製品マニュアルの現場では「マニュアルを減らしたい」「ページ数を減らしたい」という話が出ることがあります。

もちろん、読みやすくするために情報を整理することは大切です。
重複した説明を減らす。
古い表現を見直す。
不要な説明を削る。
検索しやすい形にする。

こうした改善には大きな意味があります。

しかし、製品が多機能化しているにもかかわらず、単純にマニュアルだけを薄くしようとすると、別の問題が起きます。

マニュアルから削った情報は、どこかに消えてなくなるわけではありません。

ユーザーが迷う。
販売店での説明が増える。
コールセンターへの問い合わせが増える。
FAQが肥大化する。
現場担当者が個別に説明する。

つまり、マニュアルから情報を削ったことで生じる課題は、別の場所に移っていきます。

マニュアルを減らすこと自体が目的になると、情報の置き場所が見えにくくなります。
本当に考えるべきなのは、ページ数ではなく、ユーザーに対する情報の届け方です。

IKEAとAppleに見る、情報の届け方の違い

たとえばIKEAの組み立て説明書は、文字を極力使わず、図や番号を中心に構成されています。

これは、世界中で同じ製品を販売するうえで、とても合理的な方法です。
翻訳量を減らし、言語差を抑え、視覚的に手順を伝えることができます。

ただし、これは単に文章を削っているわけではありません。
部品の形、穴の位置、組み立て順序、付属品の構成などが、図で説明できるように設計されているから成立しています。

一方で、Apple製品はまた違う方向でマニュアルを薄くしています。

iPhoneやMac、Apple Watch、AirPodsなどは、いずれも非常に多機能な製品です。
それでも、多くのユーザーは分厚いマニュアルを読まずに使い始めることができます。

初期設定は画面に従えば進む。
近くにデバイスを置けば接続案内が表示される。
困ったときは設定画面や検索から情報にたどり着ける。
製品ごとに操作体系が大きく変わらない。

つまりAppleは、説明をなくしているのではなく、説明を製品体験の中に溶かしています。

紙のマニュアルに書くのではなく、画面上の案内、設定画面、通知、オンラインサポート、デバイス間連携の中に情報を配置しているのです。

製品側に説明を持たせられる領域

ソフトウェア製品では、画面内の案内やウィザードによって、マニュアルを減らせる余地があります。

初回設定ウィザード。
入力ミスに対するエラーメッセージ。
画面内ヘルプ。
ツールチップ。
チュートリアル。
FAQへのリンク。

こうした仕組みがあれば、ユーザーは操作しながら必要な情報を得ることができます。

車や工業製品では、ソフトウェアと同じように考えることはできません。
安全性、法規、誤操作時の影響、ユーザー層の広さ、仕様差、地域差などがあるためです。

それでも、すべての領域が同じではありません。

たとえば車の中でも、ナビゲーションやマルチメディア、スマートフォン連携、アカウント設定、地図更新、音声操作といった領域は、かなりソフトウェアに近い性質を持っています。

こうした領域では、マニュアルにすべての操作手順を書くよりも、画面上で案内したほうが分かりやすい場合があります。

Bluetooth接続に失敗したとき、失敗理由に応じて次の操作を表示する。
初回利用時だけ設定ガイドを出す。
設定画面の中に「これは何か」を説明する導線を置く。
画面からWebマニュアルの該当箇所へ遷移できるようにする。

このように、製品側とマニュアル側が連携すれば、ユーザーにとって自然な情報提供ができるようになります。

マニュアルは最終防衛ラインになりがち

一方で、現実の製品開発では難しい問題もあります。

品質保証や評価の段階で、製品上のリスクや分かりにくい点が見つかることがあります。
本来であれば、製品設計やUI側で対応したほうがよいものもあります。

しかし、製品設計、試作、評価、出荷までのタイムラインを考えると、後工程で製品側を変更するのは簡単ではありません。

設計変更が必要になる。
再評価が必要になる。
部品やソフトウェアへの影響が出る。
出荷スケジュールに影響する。

その結果、まだ修正が間に合うマニュアル側で対応する、という判断になることがあります。

「この注記をマニュアルに入れておいてください」
「この条件では注意するように書いておいてください」
「この操作は避けるように書いておいてください」

こうした対応は、現場では珍しくありません。

もちろん、マニュアルで注意喚起すべき情報はあります。
安全上必要な警告や、ユーザー操作に関わる重要な注意事項は、適切に記載しなければなりません。

ただし、すべてをマニュアルの注記で受け止め続けると、別の問題が起きます。

注意書きが増えすぎる。
本当に重要な情報が埋もれる。
ユーザーが読み切れなくなる。
製品側で解決すべき問題が、マニュアル上の注記として残り続ける。

マニュアルは、製品課題の最終避難所ではありません。

現実にはマニュアルで暫定対応せざるを得ない場面もあります。
しかし、その対応が恒久対策なのか、次の製品や次のバージョンで製品側に戻すべき課題なのかを分けておくことが重要です。

文章を書く仕事から、情報を設計する仕事へ

これからのマニュアルライターや編集者の仕事は、単に文章を書くことから少しずつ変わっていくと考えています。

もちろん、分かりやすい文章を書く力は今後も必要です。
しかし、それだけでは十分ではありません。

その情報は、マニュアルに書くべきなのか。
製品画面に表示すべきなのか。
初回設定時だけ出せばよいのか。
FAQに置くべきなのか。
サポート窓口で案内すべきなのか。
安全上、必ずマニュアルに残すべきなのか。
そもそも製品側の設計を変えれば説明不要にならないのか。

こうした判断が、これまで以上に重要になります。

マニュアル制作は、完成した仕様を受け取って文章化するだけの仕事ではなくなっていきます。
製品企画、UI設計、品質保証、販売、サポート、翻訳、Web運用と連携しながら、情報の役割分担を設計する仕事へと広がっていきます。

言い換えれば、マニュアル制作は「文章作成」から「情報体験設計」へ近づいていくのだと思います。

一度に変えるのではなく、数年単位で移行する

もちろん、このような変化を一度に実現することは簡単ではありません。

特に大きな会社ほど、製品企画、開発、品質保証、マニュアル制作、翻訳、販売、サポート、Web運用が、それぞれ別の組織・工程・委託先で動いていることがあります。

そのため、ある日突然「これからは製品体験全体で情報設計をしましょう」と言っても、すぐには動けません。

現実的には、数年単位で段階的に移行していくことになります。

まずは、既存マニュアルの情報を整理する。
問い合わせが多い項目を洗い出す。
画面内ヘルプに移せる情報を見つける。
WebマニュアルとFAQの役割を整理する。
新製品や新機能から、情報設計の考え方を少しずつ取り入れる。
マニュアル制作側が、企画やUI設計の段階から関われる領域を増やしていく。

このような積み重ねによって、少しずつ情報の届け方を変えていくことができます。

製品がもっと魅力的になるために

マニュアルを減らすことが目的ではありません。

目的は、ユーザーが製品を迷わず、安心して、気持ちよく使えるようにすることです。

必要な情報が、必要な場面で、自然に届く。
分からないことがあっても、手元の画面やWebからすぐに確認できる。
安全上重要な情報は、確実に伝わる。
詳しく知りたい人には、体系的な情報が用意されている。

こうした状態を作ることができれば、製品そのものの魅力は高まります。

マニュアルはなくなるのではありません。
役割が変わっていくのだと思います。

製品の外側にある説明書としてだけでなく、製品体験の一部として、どこで、どの情報を、どのように届けるかを設計する。

その視点が、これからのマニュアル制作にはますます重要になっていくはずです。