読書メモ「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」を読みました
表記本を読んだので感想を記載します。
エンジニア向きにドキュメントの書き方を体系的に記載した本になります。架空の犬の言葉を翻訳するプロダクトのストーリーを使いながら、エンジニア向けのドキュメントの内容を説明してくれています。ドキュメント作りもプロダクト作りと同じだという事が良くわかります。
Forkwellのイベントでも訳者の岩瀬さんが分かりやすく説明してくれていますので、興味がある場合はそちらを見ると良いかもです。
そのイベントでも『1.ユーザーを理解してジャーニーを描く、ジャーニーの中でドキュメントがこう役立つのではという仮説を立てる⇒2.仮説検証のために実装(ドキュメント実装)、設計してコードを書いて、レビューする⇒
3.リリースして反応を見る。ユーザーからフィードバックを得て改善する」という事でプロダクト作成と同じだとお話ししていました。
概要
＜ユーザー理解について＞
・ユーザーニーズのアウトラインを作り、ユーザーの理解を検証する
※ ペルソナ、ユーザーストーリー、ユーザージャーニーマップで整理する
・ユーザーニーズを満たすよう編集を考える（技術的な正確さ、完全性、構成、明確さと簡潔さの軸で考える）
＜コンテンツタイプの検討と書き出しについて＞
・コンテンツのタイプを考える。下記のようなコンテンツが考えられる。
-コードコメント、READ ME、スタートガイド、コンセプト ドキュメント、手順書、チュートリアル、ハウツーガイド、リファレンスドキュメント、APIリファレンス、用語集、トラブルシューティングドキュメント、変更に関するドキュメント、リリースノート
・白紙から勧めることが一番難しい(手になじんだツールや媒体を変えて描いてみる）
・構造品質として３Cを意識する(Clear(明確な)、Concise(簡潔な)、Consistent(一貫している))
＜フィードバックを集める＞
・ドキュメントが優れているのは目的にかなっている場合である。（＝ユーザーの行動を促進すること＋組織のゴールを達成すること）、この目的をもとに品質を定義して見える化していく
・良いフィードバックをする（建設的な追加提案ができるならば、アイデアを批判してよい）
・フリクションログ（嫌だと思った体験のログ）を作る
・フィードバックについてはトリアージが重要（課題は有効か？課題は修正可能か？課題はどれくらい重要か？）
・ユーザーは情報を探しているが、書いてある内容をほとんど読まない（F字パターンで読む）
※流し読みしやすい構成にする
・エンジニアは文章よりもサンプルコードを探している
感想
本書はToC向けの広めのドキュメントライティングの話ですが、内部のドキュメントでも使える内容で、何より、プロダクト作成と同じ考え方で書かれているのが非常に好感が持てました。
このブログは自分が学んだ事を自分のために書いているのが目的なのですが、もう少しユーザーの事を考えて書いても良いかなと思いました。ただ、本書でも書き始めるのが一番大変と書いていましたので、あまり気にしすぎずだらだら書いていこうと思っています(いいのか？？）
ちなみに下記は岩瀬さんがお勧めしてくれた本です。下の２冊は読んだはずなのですが、見つかりませんでした。また読んでみようかなぁ。
参考：岩瀬さんが紹介してくれていた本
この記事が気に入ったらサポートをしてみませんか？