スクリーンショット中心のソフトウェア資料一式を計画する方法

チームごとにソフトウェアページの整理方法が異なると、ビジュアル資料一式は保守しにくくなります。読者の質問から始め、各回答にページの種類を割り当て、スクリーンショットの方針を決めます。価値の高いガイドを作って相互につなぎ、各ページのレビュー担当者を記録します。

要点: 製品メニューではなく、読者の作業を中心に資料を構成します。各質問に明確な答えを1つ用意し、不確かさを減らす場所だけにスクリーンショットを使い、画面変更後に各ガイドを更新する担当者を記録します。

読者が答えを必要とする質問を一覧にする

資料の棚卸しは、すべての画面を順に紹介するのではなく、読者の質問から始めます。サポートの問い合わせ、オンボーディング、営業からの引き継ぎ、リリース後の反応、製品の利用状況から、作業と問題を集めます。

各項目を、結果または判断として書きます。

• アプリをインストールし、必要な権限を許可する。
• 選択したウインドウをキャプチャする。
• 文書を画像ファイルとして書き出す。
• 画面プレビューが表示されない問題を直す。
• Action CaptureとAuto Captureのどちらを使うか選ぶ。

言い回しが違っても内容が重なるものは、1つの質問にまとめます。そうすれば、別々のチームが、ほぼ同じ回答を別のタイトルで複数作ることを防げます。

各質問にページの種類を1つ割り当てる

ページの種類によって、読者が期待する構成が決まります。作業にはチュートリアル、すべての選択肢にはリファレンス、症状と解決にはトラブルシューティング、変更内容にはリリースノートを使います。

読者の質問	適したページ	主な内容
この機能は何のためにある？	概要	目的、適する用途、制約、次の操作
この作業をどう完了する？	チュートリアル	前提条件、順序付き手順、結果
各項目には何の意味がある？	リファレンス	すべての項目、値、初期設定
なぜ失敗する？	トラブルシューティング	症状、原因の確認、修正、必要情報
何が変わった？	Changelog	リリース済みの動作、移行、利用条件

ページ同士はリンクできますが、答え全体を繰り返してはいけません。概要ページではチュートリアルへ案内し、全手順を複製しないようにします。

スクリーンショットの方針を定義する

スクリーンショットの方針を決めると、ビジュアルページの一貫性と保守性が上がります。画像が必要な場面、表示してよいデータ、操作対象の示し方、元画像と編集済み画像の保存場所を定めてください。

スクリーンショットは次の目的に使います。

• 操作やセクションの場所を示す
• 画面に見える選択肢から選ぶ
• 操作前後の状態を示す
• 成功した結果を確認する
• 警告またはエラーを見分ける

正確なコマンド、頻繁に変わる値、概念説明、読者がコピーする情報には文章を使います。コマンドのスクリーンショットは、コードブロックよりアクセシビリティが低く、再利用もしにくくなります。

差し替えやすい名前で画像を保存する

安定したファイル名を使うと、安全に更新できます。撮影順ではなく、ガイド名とステップの目的から名前を付けてください。

たとえばaction-capture-start-session.webpなら、ステップ2だった段落がステップ3へ動いても意味が通じます。screenshot-02-final.webpは、次の編集で誤解を招く名前になります。

ガイドまたは保守記録に、次の情報を一緒に保管します。

• 元のキャプチャ
• 編集・最適化済み画像
• 代替テキスト
• 製品とOSのバージョン
• 撮影日
• ページ担当者
• 自社で撮影した画像でない場合の出典またはライセンス

広い機能紹介より先に作業ガイドを作る

作業ガイドでは、読者が最もよく行う仕事、または失敗するとサポート負担が大きい仕事を扱います。設定、最初の成功結果、よく繰り返す作業、解決コストの高い失敗から始めてください。

1つのガイドを1つの完成結果に結び付けます。「書き出しのすべて」という広いページは、読みづらく更新もしにくくなります。「Action CaptureのページをPNGとして書き出す」を、すべての形式とプラン条件を一覧にするリファレンス表から分けてください。

Action Captureなら、作業しながらクリックに連動したステップを集められます。撮影、確認、編集、書き出しは、Macでクリックからステップ形式の手順書を作る方法をご覧ください。

資料一式をつなぐ

ナビゲーションでは、読者が次に抱く質問へ進めるようにします。設定ガイドから最初の作業へ、作業からよくある失敗のトラブルシューティングへ、リファレンスから項目を使うワークフローへリンクできます。

リンク先が分かる直接的なラベルを使います。「詳しくはこちら」より「画面収録の権限を許可する」のほうが役立ちます。関連リンクが資料の階層そのものを置き換えないよう、数を絞ってください。

どのページを開くかを教えず、読者へ問題だけを渡してテストします。正しい答えを見つけ、作業を完了し、起きやすいエラーから復旧できるかを確認してください。

担当者と見直し条件を決める

すべてのビジュアルページに、担当者とレビューを始める条件が必要です。定期的な見直しも役立ちますが、画面、プラン、権限の変更や、同じ問い合わせの急増があれば、予定より先に確認します。

次の項目を記録します。

ページ担当者：
確認済みの製品バージョン：
最終確認日：
次回見直し予定：
見直し条件：
- UIラベルまたはレイアウトの変更
- ワークフローまたは権限の変更
- プランまたは書き出し機能の変更
- 同じサポート問題の繰り返し

重要な各質問に対して読者が明確な答えを1つ見つけられ、製品変更の影響を受けるページをチームが特定できれば、資料一式は運用できます。クリックに連動したビジュアル手順にはAction Capture、撮影、編集、書き出しの流れにはMacでクリックからステップ形式の手順書を作る方法をご利用ください。