「ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング」を読んで

「人間は他人が自分と同じ知識をもっていると思い込んでいる」
↑
この認知バイアスを知識の呪いと言う

前提知識が違うことを意識しないといけない

ユーザーがそのソフトウェアに求めていることと、サポートが必要になる箇所を理解する必要があります。

大事

今の自分に欲しいのはここらへんのHowだな

ユーザーのために効果的なドキュメントを書くには、ユーザーが誰であって、何を達成したいのか理解する必要があります。

大事

ユーザーが開発者なら開発者のニーズを理解すること

マネージャーならマネージャーのニーズを理解すること

開発者がドキュメントの読み手であるなら、次のような項目を考えてみてください。
・開発者のスキル
・プログラミング言語
・開発環境
・オペレーティングシステム
・チームの役割

開発者のスキルはどういうものだろう
読み進めると分かるのかな

ユーザー定義の次はアウトラインを作ること

簡単な方法は質問リストの作成

以下はどんなプロダクトにも適用できるサンプル

・これは何のプロダクト？
・このプロダクトが解決する問題は？
・どんな機能がある？
・費用はどれぐらいかかる？
・どこから始められる？

toCのCにもわかる感じかな

こういうのは開発者向け

・APIを使うための認証はどうすれば良いか？
・この機能はどうやれば使える？
・どうやればこの問題を解決できる？

大事なのはニーズ(needs)であってウォンツ(wants)ではない

例）近くの街へ旅行する手段は？
wants → スポーツカーでドライブしたい
needs → バスチケットを渡す

Noteにあった例だけど、ここではユーザーが運転できないならと後出しされているからそもそもwantsの選択肢はないんじゃないかな

でもそれがwantsか
だからバスチケットを渡してneedsを満たす

怒ってカッとなっているユーザーが送るサポートチケットに勝る情報源なし