目次から24ページへ移動したものの、到着した画面には章のタイトルしかありません。どの問いに答える区間なのか、目次へどう戻るのかも分からないままです。移動距離は短くなりましたが、ナビゲーションは終わっていません。

インタラクティブ目次は、ページ番号にリンクを付けるだけの仕組みではありません。移動先、現在位置、戻り道、次の選択肢を一緒に保つ文書ナビゲーションです。問いの形で目次を書くことに加え、移動後に読者が迷わないかまで確認する必要があります。

長い文書の目次と途中のページの間に、しおり型の戻り道と現在位置のタブが見えるペンスケッチ。

目次リンクに必要な四つの要素

長い文書を作ったチームは全体の順序を知っています。一方、読者は価格、適用範囲、事例、運用条件など、自分の業務に近い場所から読み始めます。途中からでも文脈を取り戻せるよう、各項目に四つの要素を結びます。

  • 読者が選んだ項目
  • 実際の移動先ページ
  • 到着直後に確認できる答え
  • 目次または関連する問いへ戻る経路

「導入前に必要な準備」を18ページへつなぐだけでは不十分です。最初の画面で準備項目と対象が分かり、区間の最後で運用条件または目次へ進めるようにします。どれか一つでも欠けるなら、リンクを増やす前に区間構成を見直します。

目次の約束と移動先を同じ言葉で書く

目次に「運用条件」とあるのに、移動先の見出しが「サービス方針」なら、読者は正しい場所かを改めて判断しなければなりません。中心となる用語をそろえ、最初の画面で何を確認できるかを一文で示します。

表や事例が前の文脈を前提にする場合は、範囲も復元します。表には単位と基準日を、事例には対象と出典を添えます。途中から読んでも、根拠の範囲を誤解しない状態が必要です。

良いリンクは遠くへ送る動作ではなく、到着直後に「なぜここへ来たか」を確認できる動作です。

移動後も現在位置と戻り道を残す

複数ページにわたる区間では、開始、現在の区間、終わりを区別します。別の問いへ移るときは、新しい区間であることを明確にします。すべてのページに大きな「目次へ」ボタンを置く必要はありませんが、長い区間の終わりや選択が分かれる場所には戻り道を用意します。

戻ることは1ページ目へ送ることとは異なります。すでに読んだ内容を繰り返さず、次の問いを選べる場所へ戻します。外部資料を開いた後の復帰も、実際の閲覧環境で確認します。

ナビゲーション、根拠、CTAを同じ階層に置かない

すべての項目を同じ階層に並べると、選択肢は増えても優先順位が見えにくくなります。最初の画面には主要な問いだけを置き、詳細仕様、付録、全表は関連区間の中で一段深くします。

問い合わせ、デモ依頼、ダウンロードなどのCTAは、目次とは役割が異なります。目次は読む経路を選び、CTAは内容を確認した後の行動を選びます。根拠より先に問い合わせを求めると、答えへの道より転換ボタンが目立ってしまいます。

長い文書では、ナビゲーション、根拠、行動の階層を画面上でも分けます。

FeatPaperのページ移動は実装手段として扱う

FeatPaperのWebビューアでは、ページ移動機能で目次項目を特定のページにつなげられます。これは読者の選択と移動先を結ぶ実装手段であり、項目の約束、戻り道、モバイル確認まで自動で完成させるものではありません。

ページ移動の要素はWebビューアで動作します。同じ操作が元のPDFやダウンロードしたファイルにも埋め込まれるとは考えません。Webリンクと静的PDFを一緒に配布する場合は、Webの移動経路とPDFのページ番号・しおりを別々に確認します。

公開前に往復の動線を歩く

文書を初めて見る一つの役割を決め、目次から移動先へ進み、別の問いを選ぶところまで実際に試します。

  • 項目と移動先の見出しが同じ約束をしているか
  • 途中からでも表の基準と事例の範囲を理解できるか
  • 目次または関連する問いへ戻れるか
  • モバイルの一画面を選択肢が圧迫していないか
  • キーボードのフォーカス順とリンク文だけで移動先を区別できるか
  • Webビューアと静的PDFのそれぞれに適したナビゲーションが残っているか

インタラクティブ目次の品質は、最初の移動速度だけでは判断できません。現在位置を理解し、根拠を確認し、次の問いを選べる状態が、長い文書の探索を短くします。