スクリーンショットを使って、より良いユーザーガイドを作る方法

目指すのはスクリーンショットを増やすことではありません。実際の迷いを解消する、より少なく、より良いスクリーンショットです。役に立つ画像は、見つけにくい設定がどこにあるのか、操作の前に画面がどう見えているはずか、作業がうまくいったことをどう確認するのかを示します。手順をたどりやすくしないのであれば、それはおそらく雑音です。

このガイドでは、スクリーンショットを使ったユーザーガイドの計画、役に立つ画像のキャプチャと注釈、その周りの手順の書き方、そしてインターフェースが変わってもガイドを正確に保つ方法を扱います。

ユーザーガイドにスクリーンショットが必要な理由

文章だけでは、読み手は書かれたラベルを視覚的な対象へ置き換える作業を強いられます。単純な作業ならその置き換えは簡単です。似たようなメニューが並ぶ混み合った管理コンソールでは、そこが人の迷う場所になります。スクリーンショットは対象そのものを示すことで、この置き換えの工程を取り除きます。

視覚的な手順は、人が読む際の動き方にも合っています。読み手が手順を上から順に読むことはめったにありません。つまずいているステップへ飛ぶのであり、適切な位置に置かれた画像は、行動する前に自分が正しい場所にいることを確認させてくれます。この確認が重要です。

ただしスクリーンショットは無料ではありません。1枚ごとが、インターフェースの変更時に撮り直さなければならない保守上の負債です。画像の価値は、それを最新に保つコストを上回っている必要があります。このトレードオフこそが、この技術のすべてです。

スクリーンショットが作業の完了を助ける仕組み

スクリーンショットが作業の完了を助けるのは、具体的な迷いの瞬間を減らすときです。よくある迷いは、場所（「この5つのタブのどれ？」）、状態（「このトグルはもう有効になっている？」）、確認（「今の操作は保存された？」）の3つです。

同僚を招待して権限を設定する、SaaSの管理者を考えてみましょう。「「メンバー」タブを開き、ロールを「編集者」に設定する」という文章の手順は、それらしく見えるタブが4つ並んでいるのを読み手が目にするまでは明確です。ロールのドロップダウンをハイライトした「メンバー」タブのトリミング済みスクリーンショットが1枚あれば、その迷いは解消します。

Nielsen Norman Groupの調査によれば、読み手は情報を担う画像には注意深く目を向ける一方、純粋に装飾的な画像はほとんど無視します。ドキュメント用スクリーンショットへの示唆は明快です。判断を担う画面の部分を見せ、それ以外は削りましょう。

スクリーンショットが解消できる迷い

• 場所の迷い：該当するメニューやタブをトリミングした画像。
• 状態の迷い：トグル、チェックボックス、ステータスの前後を写した拡大画像。
• 確認の迷い：操作後の成功メッセージや更新された画面。

スクリーンショットが役立つときと、雑音になるとき

スクリーンショットが役立つのは、対象が見つけにくいとき、状態が曖昧なとき、あるいは結果を誤りやすいときです。文章がすでに明らかにしていることを繰り返す場合は、雑音になります。

画面に「保存」ボタンが1つしかないなら、「「保存」をクリックする」に画像は要りません。1つの項目の変更を示すのにページ全体のスクリーンショットも要りません。そしてログインのように読み手が何十回も行うステップに、スクリーンショットが必要になることはめったにありません。

簡単な判断基準があります。その画像を取り除いても、読み手は何をすべきか正確に分かるでしょうか。分かるなら削ります。分からないなら残し、より鋭くします。この抑制こそが、分かりやすい作業手順書と肥大したドキュメントを分けるものです。

残すか削るかの判断

• スクリーンショットを残す場合：対象が埋もれている、状態が不明瞭、または操作が取り消せないとき。
• スクリーンショットを削る場合：文章がすでに曖昧さを残していない、または画面が単純なとき。
• 文章に置き換える場合：一文（「「保存」ボタンは右上にあります」）で済むとき。

スクリーンショットを使ったユーザーガイドの計画

出来の悪いガイドの多くは、誰も計画しなかったから出来が悪いのです。誰かがツールを開き、クリックし始め、現れたものをそのままキャプチャしたのです。まず計画することこそが、図解入りのユーザーガイドと、スクリーンショットの寄せ集めを分けます。

計画は大がかりである必要はありません。キャプチャの前に下す3つの判断に尽きます。これは誰のためのものか、完了した状態はどうなるのか、そして各画面をどう見せ、どう注釈を付けるのかです。この判断を一度下しておけば、以後のスクリーンショットはすべて楽になります。

拠り所となる再利用可能な構成については、毎回一から考えるのではなく、簡単なガイドの骨格を使うとよいでしょう。より踏み込んだ再利用可能な形式については、ここでテンプレート集を作るのではなく、ドキュメントテンプレートの手引きをご覧ください。

対象者、目標、ユーザーの道筋を定める

画面ではなく読み手から始めましょう。新規顧客向けに書くガイドは、すでに製品を知っている社内の管理者向けより多くの背景説明が必要です。対象者が、文章の水準、説明の量、そしてどのステップを前提にできるかを決めます。

次に、そのガイドが完了させる1つの作業を定義します。「請求を管理する」は作業ではありません。「登録済みのクレジットカードを更新する」が作業です。目標を絞ればガイドは短く保たれ、スクリーンショットの枚数も正直な数に収まります。

最後に、最初のクリックから確認画面まで、実際のユーザーの道筋をたどります。現実の人がためらいそうな箇所を書き留めましょう。そのためらいの地点こそ、ドキュメント用スクリーンショットが価値を発揮する場所です。

計画時の3つの判断

• 対象者：その人の役割、ツールへの慣れ、すでに知っていること。
• 目標：成果として言い表せる、具体的で完了可能な1つの作業。
• 道筋：実際のクリック経路と、ためらいの地点の印。

ドキュメント用スクリーンショットを撮る前に各ステップを洗い出す

1枚も撮る前に、手順を文章として書き出しましょう。文章を先に置く進め方は、各ステップで実際に何が起こるのかを決めることを強い、画像がまったく不要なステップを浮かび上がらせます。

キャプチャの前にワークフローを洗い出しておくと、どのステップに視覚的な補助が要るかも見えやすくなります。先に実際のワークフローをキャプチャし、そこからドキュメントを生成する方法を好むチームは、キャプチャファースト型のワークフロードキュメントのガイドをご覧ください。

各ステップの横に、スクリーンショットが必要かどうかと、その理由を記します。その画像が解消する迷いを言葉にできないなら、そのステップにはおそらく画像は不要です。スクリーンショットの抑制はここから始まります。

先に洗い出しておくことは、UIが変わったときの備えにもなります。手順が画像への指示（「画像の青いボタンをクリックする」）ではなく操作（「請求設定を開く」）として書かれていれば、画像の撮り直しが必要になっても文章はリニューアルを生き延びます。

キャプチャ前にガイドを洗い出す

1. すべてのステップを書き出す：クリック経路の全体を、短い操作の文として書きます。
2. 画像の要否に印を付ける：各ステップに、画像が必要か文章のみかを理由とともに記します。
3. 前提条件を控える：各キャプチャに必要なアカウント、データ、画面の状態を記録します。
4. 順序を決める：実際のユーザーがたどる順にステップが並んでいることを確認します。

スクリーンショットと注釈のスタイルを統一する

スクリーンショットに一貫性がないと、手順が正しくてもガイドは信用できない印象になります。トリミングの大きさがまちまちで、ハイライトの色がそろわず、ズーム倍率がばらばらだと、読み手は画像ごとに見方を立て直すことになります。

スタイルは一度決めて、どこにも同じように適用します。インターフェースに対して目立つハイライト色、「ここをクリック」を示す注釈の形を1つ、そしてページ上で画像がそろうように標準のトリミング幅を決めましょう。Haikuのようなキャプチャファースト型のドキュメントツールは、ステップ画像を統一されたスタイルで自動生成できるため、この手作業による統一の負担の多くを取り除けます。

こうした選択を短いスタイルメモとして書き残し、次にガイドを編集する人が合わせられるようにしましょう。一貫性は装飾ではありません。読み手が画像を信頼できるようにするものです。

固定すべきスタイルの選択

• ハイライト：クリック対象を示すアクセント色を1つ、形（四角か矢印）を1つ。
• トリミング：画像がそろい、読みやすさを保てる標準の幅と余白。
• ラベル：キャプションとコールアウトに使う、一貫したフォントと配置。

ドキュメント向けにより良いスクリーンショットを撮る

キャプチャの品質は、良い計画が実を結ぶか崩れるかの分かれ目です。範囲をうまく絞ったステップでも、画像がぼやけていたり、雑然としていたり、誤ったデータで埋まっていれば、読み手の役には立ちません。

目指すのは、関連する範囲だけを、鮮明さを保つ解像度で写し、画面上に個人情報が漏れるものが何もないスクリーンショットです。そこに至るには3つの習慣があります。画面を整えること、狭くキャプチャすること、そして既定でマスキングすることです。

キャプチャの前にインターフェースを整える

あなたがキャプチャした画面が、読み手の信じる画面になります。だからこそ意図をもって整えましょう。現実的でありながら機微でないデータを入れた、きれいなテストアカウントを使います。通知バナー、関係のないブラウザータブ、そして読み手を混乱させる中途半端な状態は閉じておきます。

インターフェースは、そのステップの開始時点そのものに設定します。ステップが「ロールを「編集者」に変更する」なら、3クリック手前ではなく、ドロップダウンが使える状態の画面を開きます。読み手が実際にたどるときに目にするのと同じ画面が見えているべきです。

製品の手順解説では、ガイド内のすべてのキャプチャがそろうように、ウィンドウサイズとズームを統一しましょう。ビューポートがずれていると、それ以外は正しいガイドでも雑な印象になります。

キャプチャ前に画面を整える

1. テストアカウントを使う：現実的なデータで、個人情報や機密情報は含めません。
2. 雑音を消す：バナー、余分なタブ、関係のないパネルを閉じます。
3. 状態を設定する：そのステップが始まる画面をそのまま開きます。
4. ビューポートを固定する：ウィンドウサイズとズームをすべてのキャプチャで同一に保ちます。

トリミング、解像度、ハイライトを効果的に使う

判断に必要な範囲へトリミングします。ページ全体のスクリーンショットは、重要な要素を1つ読み手に探させることになります。該当するコントロールの周囲を狭くトリミングすれば、一文字も読む前にどこを見ればよいかが伝わります。

ガイドの段組み幅に合わせて縮小しても鮮明さを保つ解像度でキャプチャしましょう。スクリーンショットの文字がぼやけているのは、スクリーンショットがないより悪い状態です。読み手が自分の側に問題があると考えかねないからです。高DPI（Retina）でキャプチャして縮小したものが、たいてい最もきれいに見えます。

そのうえで、ハイライトは5つではなく1つ加えます。クリック対象を囲む四角か矢印が1つなら、すぐに読み取れます。矢印3本に丸1つ、色の重ね塗り2つでは、画像が謎かけになります。

ビフォーアフター：権限設定のスクリーンショット

出来の悪い例は、設定ページ全体を全幅で写し、ハイライトもなく、ロールのドロップダウンが多くの要素のうちの小さな1つとして写っているものです。読み手はざっと見て、あきらめ、推測します。

役に立つ例は、メンバーの行とロールのドロップダウンだけにトリミングし、ラベルが読める大きさに拡大し、ドロップダウンを四角で1つ囲んだものです。同じ画面でありながら、今度は画像が、文章にはできない仕事をしています。

スクリーンショット内の機微なデータを守る

すべてのスクリーンショットは情報漏えいの可能性を抱えています。実在する顧客名、メールアドレス、口座番号、社内URL、サポートの問い合わせ内容は、いずれも誰も確認しなかったために公開ガイドの中へ出ていったことがあります。

既定でマスキングしましょう。画像をガイドに入れる前に、個人を特定できるもの、システムの詳細が分かるものはぼかすか隠します。キャプチャの時点でマスキングするほうが、公開したガイドを後から回収するよりはるかに安上がりです。

画像に関するW3C Web Accessibility Initiativeのガイダンスもここで守る価値があります。画像を、意味を伝える唯一の手段にしてはいけません。スクリーンショットで示す重要な内容は、アクセシビリティのためにも、スクリーンリーダーが画像を読み取れない読み手のためにも、文章にも書かれているべきです。

公開前にマスキングすべきもの

• 個人を隠す：氏名、メールアドレス、アバター、口座番号。
• システムの詳細を隠す：社内URL、トークン、環境名。
• 安全なデータを使う：明らかに架空と分かるデータをテストアカウントに入れておきます。

手順書のためにスクリーンショットの周りの文章を書く

スクリーンショットは単独では成り立ちません。手順書がUIの変更を生き延びられるかどうかを決めるのは文章です。言葉は意図を説明しますが、画像はある一瞬を説明するだけだからです。優れた文章と優れた画像は互いを補強します。

原則は単純です。読み手は文章だけでそのステップを完了でき、スクリーンショットは確認として働くべきです。画像が完璧なときにしか機能しないガイドは、脆いガイドです。

画像と一致する、行動中心のステップを書く

各ステップは動詞から始め、対象は画面に表示されているとおりの名前で呼びます。「設定エリアに移動する」より「「設定」をクリックする」が優ります。読み手が「設定」という目に見えるラベルと照合できるからです。

文言はスクリーンショットと正確に一致させます。ボタンに「メンバーを追加」とあるなら、「ユーザーを追加する」と書いてはいけません。文章と画像で言葉が食い違うのは、とくに流し読みする読み手にとって、混乱のよくある原因です。

対象は、あなたの画像の中での見え方ではなく、名前と場所で説明します。「「メンバー」タブを開く」はリニューアルを生き延びます。「画像の青いボタンをクリックする」は、そのボタンが緑になった瞬間に壊れます。

ステップの文言のルール

• 動詞から始める：クリックする、開く、選択する、入力する、確定する。
• ラベルと一致させる：画面に表示されているとおりの文言を使います。
• 場所を示す：何色かではなく、どこにあるかを説明します。

混乱を減らす位置にスクリーンショットを置く

各画像は、それが示すステップの直後に置き、決して前には置きません。読み手はまず操作を読み、次に確認を見る、という順序です。ステップの上に浮いている画像は、どの手順のものかを読み手に推測させます。

1つの画像は1つのステップに結び付けます。3つの操作をまとめて写そうとした1枚のスクリーンショットは読み手の注意を分散させ、たいてい何もうまく際立たせられません。本当に複雑なステップなら、より狭い画像を添えたサブステップに分けましょう。

画像の周りには余白を残し、ステップの切れ目を目で分けられるようにします。積み重なったスクリーンショットの壁は1つのぼやけた塊として読まれ、ガイドを図解する意味そのものを失わせます。

キャプション、ラベル、コールアウトを明確に保つ

キャプションは、ステップを言い直すのではなく、画像だけでは示せない情報を加えるべきです。「ロールのドロップダウン。「編集者」に設定した状態」は役に立ちます。「画面のスクリーンショット」は雑音です。

すべてのスクリーンショットに代替テキストを書き、支援技術を使う読み手や、画像が読み込まれなかった人にもガイドが機能するようにします。ピクセルではなく、示されている機能を説明しましょう。「画像」ではなく「ロールのドロップダウンが開いた状態の「メンバー」タブ」と書きます。

コールアウトは短く、統一します。矢印に添える一言か二言（「ここをクリック」「オンにする」）で十分です。画像に詰め込まれた長いコールアウトは、ガイドの表示サイズでは読めなくなります。土台となる手順を文書化する技術全般については、ワークフロー、ランブック、技術ガイドの文書化の手引きをご覧ください。

図解入りのユーザーガイドを最新に保つ

スクリーンショットを使ったガイドで最も難しいのは、作ることではありません。正しい状態に保ち続けることです。ガイドは公開した日には正確で、製品が変わった瞬間から劣化し始めます。

手作業のガイドは静かに劣化します。ユーザーが行き止まりにたどり着いて問い合わせを起票するまで、スクリーンショットが誤っていることに誰も気づきません。これは、ガイドの公開からずっと後になって表面化する不十分なプロセスドキュメントが招く隠れたコストの1つです。ここでは、最初にどれだけ丁寧に書いたかより、ガイドをどう作るかのほうが重要になります。

解決策は、再キャプチャの習慣と、いつそれを始めるべきかを知る仕組みです。製品のリリースに結び付けたレビューの頻度を定め、製品チームがこれから変更する画面に関わるガイドに印を付けましょう。Haikuのようなキャプチャファースト型のドキュメントツールは、実際のワークフローを一度記録し、インターフェースが変わったときに手順を再生成することでこの負担を減らし、全面的な手作業の再キャプチャを短時間のレビューに変えます。10ステップのガイドを手作業で組み立ててトリミングするのは、実際のフローを撮り直すよりかなり時間がかかり得ますが、正確な時間はワークフローとツールによって異なります。

ガイドを正確に保つ習慣

• 周期を決める：決まった周期と、大きなリリースの後にガイドを見直します。
• 変更をきっかけにする：当て推量ではなく、土台となる画面が変わったときに撮り直します。
• 書き直すのではなく確認する：各画像がまだ一致しているかを確認し、変わったものだけを差し替えます。

よくある質問