スクリーンショットを提供すると、ドキュメンテーションマニュアルに役立ちますか？
作業中のWebアプリケーションのサイト管理者およびコンテンツ作成者の役割を文書化しています。ドキュメントマニュアルでは、メンバー、ニュース記事を追加、削除、更新する方法、およびさまざまなオプションを使用してサイトを構成する方法について読者に説明しています。
開発者の1人に、これらのアクションを実行する方法のページのスクリーンショットをドキュメント内にも追加する必要があると言っていました。彼は正しいと思いますが、同時に私はそうではありません。
ユーザー読むことができますである場合、彼は私の注文リストの私の指示に従うことができます。
例：
- 最初のステップ、ここをクリック
- 第二段階、これをクリック
- 3番目のステップ、これを入力
ドキュメントマニュアルにスクリーンショットを追加する必要がありますか？また、ユーザー向けに明確にするために、指示の順序付きリストも役立ちますか？または、テキストのみを使用する私の方法にとどまるべきですか？
Michael Hughes からのこの結論は、スクリーンショットを含めるタイミングと含めないタイミングを決定するのに役立ちます。
これはどこに私を残しますか？
私は、彼らが以下を行うスクリーンショットを含めることに、よりオープンになるでしょう：
- ユーザーがUIのどこにいるのが適切な場所であることをユーザーに安心させる
- 複雑なUIの特定の領域に注意を喚起するのに役立ちます
- デスクトップの構成のセットアップなど、他の方法では視覚化が難しい例をサポートする
ですから、彼らが付加価値を付けるところでは、仕事を難しくするような側面（ドキュメントのメンテナンスなど）にもっと積極的に取り組みます。しかし、私が言葉でそうするように、私は明白で何も価値を加えないものを切り取ります。
私は、サブトラクティブアプローチよりも加法的アプローチ（言葉が不十分であると思われる場合にのみ入力する）を好んでいます（不必要に思える場合は削除します）。言い換えれば、私は将来的にスクリーンショットに対してよりオープンになりますが、彼らは追放されるまで資格によってだけでなく、ドキュメントに自分自身で取り組む必要があります。
以下のケースではスクリーンショットを使用する必要があります
画面を適切に言葉で説明できない場合、つまり画面に同様のオプションがあり、ユーザーを混乱させる可能性がある場合。
ユーザーが1つの画面から別の画面にナビゲートするときに、一貫性のない、つまりUIが大幅に変更されるか、ユーザーを別のアプリケーションにリダイレクトする場合。
また、スクリーンショットを置くとドキュメントがかさばると感じるかもしれません。ただし、ユーザーの観点からは、スクリーンショットを含めることは常に良いことですが、必要な詳細をスクリーンショットにのみ含めるようにしてください。その特定の瞬間に必要ではない画面の部分を含める必要はありません。上記の点に注意しながら、スクリーンショットのコンテキスト使用は良いです。
追伸目標は、ユーザーの心の認知負荷を減らすことです。
最善の方法は、アプリケーションをわかりやすくすることです。そのため、人々は何をクリックするか、どこをクリックするかを知っているだけです。
それが機能しない画面では、アプリケーションにマニュアルを直接含めたり、ヒント、サンプル画像、アニメーションなど、タスクを理解するために必要なものを追加したりできます。
アプリケーションとヘルプを同じ場所に置くと、アプリケーションを変更するたびにアプリケーションを更新するのにも役立ちます。
マニュアルを実際に読んでいる人はもういません。たとえ読んでいても、それを書いているときに関連するポイントを見逃しているでしょう。簡単にアプリケーションに追加でき、配布されたマニュアルでは難しい。
スクリーンショットの数を最小限にしたい場合は、次のように、CSSを使用して、ユーザーの注意を引き付けたいスクリーンショットの領域の上にボックスを常に表示できます。 http：/ /www.bioinformatics.org/librarian/screenshots.php 。多少の作業は必要になりますが、ディスプレイは美しく、ドキュメントのノイズを制限します。
スクリーンショットを準備しているトレーニング/「ハウツー」のようなコンテンツの場合は、参考になります。
たとえば、メンバーを追加する必要がある場合は、「機能を選択>追加をクリック>詳細を入力>送信」をクリックし、これらの指示に従ってそのアクションをサポートする画面を提供すると、ユーザーが簡単に実行できるようになります。アクションを画面に関連付けます。
これで、ユーザー/記事の削除などの単純なアクションがあり、その権利が見逃される可能性が低くなります。その場合、画面全体を追加するのではなく、視覚的なアーティファクトのみを使用できます。「機能を選択>削除をクリック」し、ユーザーがクリックする必要があるアーティファクトのみを提供します。
ユーザー詳細の追加/更新など、同じ画面を使用する複数のアクションがある場合は、いずれかのモジュールを説明しながらスクリーンショットを提供し、もう一方の参照として使用できます。ただし、このアプローチは、ユーザーに提供するインターフェースと、システムでのアクションの最終的な結果に依存します（上記の場合、両方のアクションでユーザー情報が更新されます）。
ユーザーマニュアルをデザインする上での主なことの一つは、聴衆を知ることだと思います。システムに精通していると思われるオーディエンスと交流している場合は、書面による指示でもかまいません。ただし、ユーザーがシステム/ UIを初めて使用する場合は、スクリーンショットを使用することでより明確にすることができます。
一部のユーザーはさまざまな方法で学習します。一部の人々は、指示のリストよりも視覚的な画像によく反応し、一部の人々は口頭の指示で応答します。できるだけ多くの学習スタイルをマニュアルに含めることで、ユーザーが理解しやすくなります（ただし、オーディオは時々時間がかかるため、個人的には避けます）。