サイト改善は、思いついた修正を続けるだけでは結果を振り返れません。何を良くしたいのか、どの事実を課題と見たのか、変更後に何を確かめるのかを一つの記録へまとめます。
PDCAは、計画、実行、評価、次の改善を順につなぐ考え方です。サイトでは一度に大きく変えるより、確認できる範囲へ分けると判断の経緯を追いやすくなります。
改善の目的と観察事実を分ける
最初に、サイトの役割と読者に取ってほしい行動を確認します。「分かりにくい」だけでは対象が曖昧なので、迷う箇所や問い合わせで説明が必要な箇所を記録します。
観察した事実と担当者の解釈は、別の欄へ書きます。事実は対象ページ、確認した画面、日時とともに残し、未確認の内容を課題の根拠へ混ぜません。
複数の課題がある場合は、読者への影響と確認のしやすさで着手順を決めます。選ばなかった課題も保留欄へ残し、忘れないようにします。
Planで一つの仮説を立てる
Planは計画です。課題の原因は、計画の段階で断定しません。「この案内を直すと、次の行動が分かりやすくなる」のように、変更と確かめたい状態を一組にします。
計画には、対象ページ、変更箇所、変更しない範囲、根拠資料、承認者を記載します。評価に使う情報も実施前に決め、都合のよい結果だけを選ばないようにします。
担当者は、原稿を準備する人、画面へ反映する人、事実を確認する人に分けます。一人で兼務する場合も、作業と承認を別の欄へ記録します。
Doは変更範囲を小さくする
Doは実行です。変更前の文章や画面を保存し、計画した箇所だけを修正します。関連のない修正を同時に入れると、どの変更を評価しているか分かりにくくなります。
公開前には、文章の事実、リンク先、画像の利用根拠、表示を確認します。想定外の状態があれば作業を広げず、変更前へ戻す判断者と連絡先を確かめます。
実施記録には、作業者、変更内容、公開日時、確認した範囲を残します。予定と異なる対応をした場合は、その理由も追記します。
Checkは同じ条件で比べる
Checkは評価です。変更前後を比べるときは、対象ページ、確認方法、対象期間などの条件をそろえます。条件が違う場合は、単純な良し悪しとして扱いません。
数値だけでなく、読者が目的の情報へ進めるか、説明が不足していないかも確認します。問い合わせ担当が気付いた変化は、推測と事実を分けて記録します。
変化が見られても、変更だけが理由だとは断定しません。同じ時期に行った別の施策や事業上の変化を確認し、判断材料の不足を明記します。
Actで次の判断を記録する
Actは次の改善です。結果を受けて、変更を維持する、元へ戻す、追加確認をする、別の課題へ進む、のいずれかを責任者が選びます。
期待した状態にならなかった場合も、記録を削除しません。仮説、実施内容、確認結果を残すと、同じ変更を理由なく繰り返すことを避けられます。
次の計画では、今回分かったことだけを前提にします。確認していない効果や外部サービスの仕様は、提供元の公式資料で確認できるまで保留にします。
継続できる運用表を作る
改善を続けるには、会議の回数より、判断に必要な項目が毎回そろうことが大切です。次の欄を持つ運用表を用意します。
- 目的、対象ページ、観察した事実
- 仮説、変更内容、変更しない範囲
- 作業者、承認者、公開日時
- 評価条件、確認結果、未確認事項
- 次の判断、担当者、再開条件
確認時期は一律にせず、情報量と判断に必要な期間を基に決めます。更新担当が変わっても、記録から同じ条件で再開できる状態を目指します。
