エンジニアのためのドキュメントライティング

これはなに？

読書メモ。ドキュメントライティングについての内容　追記中・・

知識の呪い：人間は他人が自分と同じ知識を持っていると思い込んでいる

知識の呪いから逃れて、ユーザーを理解する方法

1. ユーザーのゴールを特定する

なぜドキュメントを書くのか、、ユーザーに何らかのタスクを完了してもらいたい、もしくは行動を変えてほしいから。

ゴール：ex. 犬の鳴き声を人の言葉に翻訳する

プロダクトのユーザーのゴールを決めたら、書き留めておくこと。あとから、ドキュメントによってゴールをどの程度達成していたか確認することでドキュメントの成功度を測定できる。

2. ユーザーを理解する

忘れてはいけない。全てのユーザーが同じわけではない。ユーザー全員のニーズを満たすのは無理です。ビジネスやプロダクトにとって最も重要なユーザーを優先しましょう。

ex. ドキュメントの読み手が開発者なら、以下の項目に注意するべき

【開発者のスキル, プログラミング言語, 開発環境, オペレーティングシステム, チームの役割】

3. ユーザーのニーズを理解し、ドキュメントがそれをどう解決するか理解する→ユーザーニーズのアウトラインを作る

【ユーザーのどのような質問に答えるべきか】

・これは何のプロダクト？

・どんな機能がある？

・費用はどれくらいかかる？

・どこから始められる？

ユーザーの理解を検証する

ユーザーに話を聞くなどして、理解度の確認、サービスへの期待などを調査する。わかったことを下記にまとめる。

4. わかったことをペルソナ、ストーリ、マップにまとめる

まとめるための代表的な3つの方法

・ユーザーペルソナ

理想の、もしくは現実の読み手を表現するための半分架空のキャラクター。初級から上級の開発者など様々なタイプを用意し、プロダクトの採用を決める上で最も重要なのは誰でしょうか？

・ユーザーストーリー

ユーザーが達成したいことを短くまとめたもの。

ユーザーが達成したいおおまかなタスクやユーザーのモチベーションのこと

・ユーザージャーニーマップ

ユーザーがソフトウェアやドキュメントに接する時に辿りうる全ての経路、チャンネルが描かれる。時系列になっており、各ポイントでユーザーが実施する内容と各手順におけるユーザーの気持ちや体験が説明される。

5. フリクションログを使って仮説検証する

フリクションとは、不満や怒りとか落胆とかストレスのこと。

アカウントに登録する際の様々なフリクションを気持ちと一緒に記録すること。改善点を見つけるために実行する。

以上。

ryuichi