なぜPDFでのマニュアル提供はUXを損なうのか？最適な方法について認識のアップデートを
投稿日:2024年12月23日
カテゴリー:Web
投稿者:
S山
現在、多くの企業は取扱説明書の類をPDFで提供しています。
なぜPDFで提供されているのか。
それは製品に同梱する印刷物のデータを二次利用しているためです。
コスト的に合理性があるためにそうなっているのが現状です。
しかし、製品に同梱する必要のない（印刷物が不要な）サービスや
システムについての説明ドキュメントについてもPDFが多く用いられています。
これはワードやパワーポイント、エクセルといったオフィス製品が
ビジネスの領域において文書作成のデファクトスタンダードとなっている状況を反映しています。
つまり、文書・ドキュメントを作成するなら、
基本的にワードやパワーポイントが無意識の内に選択されているのです。
これはある意味仕方のない状況とも言えますが、
コスト的に合理性がないのであれば、別の選択肢も考えてみてもいいでしょう。
つまり、ウェブで、ブラウザで閲覧するのに最適なフォーマットで作成するということです。
まず、PDFでのマニュアルの提供にどういった問題があるのかを確認しておきましょう。
PDFは操作性に難がある
想像してください。
あなたは今Google検索して、リンクを辿り、取扱説明書のページに辿りつきました。
そこにPDFのリンクが羅列されています。
リンクをクリックするとブラウザでPDFが表示されます。
縦にずらりとページが並んでいます。冒頭に目次のページがあります。
しかし、その目次は該当のページにリンクしてはいません。
ページをスクロールしていき該当の箇所を探します。面倒なので「検索」をします。
しかし、適当な語句を入れて検索してもヒットしません。
再度検索します。検索した文字が文書中の文字にヒットしました。
しかし、ハイライトされた箇所が多すぎて該当の箇所になかなか辿りつきません。
ようやく目的の説明箇所に辿りつきました。そして内容を確認してページを閉じました。
その後、もう一度内容を確認したいと思い、ブラウザの履歴からPDFのページを開きました。
もちろん、表示されるのは最初のページです。
先ほど苦労して探した内容は何ページに記載されていたか、覚えていません。
また検索のやり直しです。
長々と書き連ねましたが、このような経験は誰しも一度ならずしたことがあるのではないでしょうか。
そもそもブラウザはPDFを開くのに作られているアプリケーションではなく、
このような操作性を放置しているのにも無理からぬところがあります。
では、ブラウザでPDFを直接表示するのではなく、一旦データとしてダウンロードし、
そのファイルをAcrobat Readerなどで表示させればいいのではないか、ということになります。
ただし、この場合も同様の問題は残ります。
膨大なページ数のどのページを開いていたかの情報はアプリによっては記憶されず、
ファイルを閉じるとまた表紙から表示されることがあります。
また、最近開いたファイルの一覧は情報として残りますが、
ファイル名が適切に付けられていないことが多く、一見してどのファイルが何のファイルなのかがわかりません。
もちろん、ブラウザで閲覧するよりは確実にアプリケーションで表示する方が操作しやすいとは言えます。
ただし、そうしたことができるのはパソコンでPDFを閲覧する状況に限ります。
スマートフォンではこうはいきません。
そして、このスマートフォン環境での閲覧にさらなる問題があります。
PDFは閲覧しづらい
スマートフォン、モバイル端末が登場してから、ウェブサイトは多くの改革を求められました。
それまでパソコン向けにレイアウトしていたページは、どう考えてもモバイル端末向きではなかったからです。
ページの幅が広く、まさにパソコン向けに「見やすい」ように作られていました。
そしてウェブ業界は軒並み「レスポンシブ」の掛け声で、ページを、サイトを改変していきました。
レスポンシブとはデバイスの画面の大きさによって、自動的にレイアウトを調整して表示する技術です。
この技術トレンドは瞬く間に普及していき、現在では非レスポンシブなサイトを見つける方が困難なほどです。
一方で、その間PDFはどうだったでしょうか。
何も変化がありませんでした。
そして、消費者はスマートフォンでピンチイン・ピンチアウトを繰り返して苦労して該当箇所を探すことになります。
閲覧のしづらさ、検索を含めた操作のしづらさ、
この2点だけをとってもPDFは消費者が求めるコンテンツの提供方法としては適当ではないことが確認できました。
今なお、マニュアル類は印刷物向けに作成されたレイアウトのままウェブに公開されています。
企業のコスト合理性の元に、そのような慣行は普及し、
消費者もまた「そういうもの」として受け取っているのが現状です。
昨今ではUX（ユーザーエクスペリエンス）の重要性がビジネス界隈で広く唱えられています。
ユーザーの正しい理解を助けるためのマニュアルがUXを軽視して良いはずがありません。
マニュアル類は以前から必要ではあるけれども優先度は低い扱いをされてきました。
今なお、そのような扱いを受けていることは驚きです。
今こそ消費者の求める閲覧方式に
では、閲覧のしやすさ、検索を含めた操作のしやすさを求めるとどうなるでしょうか。
答えはウェブページにすることです。
ウェブページを作るためには、
ワードやパワーポイントで作成したファイルをPDFに変換するのと比べて
検討しなければならない要素が多くあるのは確かです。
例えば、どうやって配信するのか、どこにファイルをおいて公開するのか、など。
ただ、企業がサイトを所持していることが前提であると考えると、
検討すべきは「どう作るか」だけになります。
HTMLは複雑ではない
インターネットの黎明期とは違い、
ウェブに関する技術は高度化して複雑になっていることは否めません。
しかし、そうであるからこそHTML化する部分は「処理」に任せて、「生成」するのが昨今の流れです。
では、何をどう処理して、生成するのでしょうか。
現在、ウェブの業界でドキュメントを執筆するのに主に使われるのは
マークダウンと呼ばれるファイルフォーマットです。
マークダウンとはワードのようなファイル形式ですが、同時に記法（記述方法）のことを指します。
そして、マークダウンはワードのように特定のアプリケーションを必要としません。
このマークダウンファイルを使い、HTMLへの変換「処理」を任せて、
HTMLファイルを「生成」するプログラムのことを、一般的にジェネレイターと呼びます。
このジェネレイターを用いることで、ドキュメントのHTML化の敷居をぐんと下げることができます。
HTMLで作られたマニュアル＝ウェブマニュアルの作成方法について
数年来言われていることの一つにCMS（コンテンツマネジメントシステム）の導入は不可欠というものがあります。
そして、このCMSの導入には少なくとも数百万程度の初期コストがかかるというのも定説として言われています。
ジェネレイターを使うと、こうした初期コストの呪縛がありません。
あくまでジェネレイターはHTMLを生成するプログラムでしかありません。
生成されたHTMLを公開するのに必要なのはファイルをアップロードすることだけです。
つまり、データベースに支えられた複雑で高額なシステムは不要なのです。
ワードなどの特定の有料のアプリケーションも必要ない。
高額なCMSの仕組みも必要ない。
加えて、ジェネレイターのほとんどはオープンソースといって
誰でも自由に使えるものとして提供されています。
必要なのは、そのためのノウハウと取り組みの意思だけです。
本記事を読んで興味を持たれた方がおられましたら是非ともお気軽にお問い合わせください。
特に下記のような課題を抱えられている企業の方はHTML化をご検討ください。
- 一つのシステム・サービスのマニュアルが複数冊に渡って存在している
- 一つのマニュアルのページ数が数十ページある
- 印刷はしていない
- マニュアル更新の費用を軽減したい
- 軽微な修正であれば自分たちで対応したい
| ▼参考記事 |
