メールの件名は「新機能のお知らせ」です。本文にはメニューの場所とボタンが並んでいますが、既存ユーザーは自分の仕事がどう変わるか分かりません。今すぐ設定を変えるのか、以前の結果は残るのか、使わなくてもよいのかも見えません。
機能アップデートのお知らせは、新機能を並べて見せる資料ではありません。誰のどの仕事がいつ変わり、必要な行動とサポート経路は何かを最後まで伝える変更コミュニケーションです。
新機能の名前より影響を受ける仕事を探す
お知らせを書く人は開発背景と画面変更をよく知っています。ユーザーは製品全体ではなく、繰り返す作業の中で変化に出会います。まず影響を受ける仕事を一文で書きます。
- 資料を登録した後に整理する順序
- チームメンバーが承認依頼を確認する場所
- 既存リンクを更新する方法
- レポートの値を読む基準
新しい機能名でも現在の仕事が変わらないなら、「参考になる新しい選択肢」として伝えます。小さなボタン変更でも作業順序や結果の読み方が変わるなら、影響と確認事項を先に置きます。
追加、変更、修正、終了を同じ調子で伝えない
更新の性格を分けると、読者が必要な行動を判断しやすくなります。
- 追加: 既存workflowに選択肢が増える
- 変更: 既存の動作、場所、初期値が変わる
- 修正: 意図どおりに動かなかった部分が直る
- 終了: 提供を終える、または別の方法へ移る
追加は使わなくても既存作業を保てる場合があります。変更や終了には準備が必要かもしれません。すべてを「より良くなりました」とまとめると重要度が見えず、ユーザーは自分に必要なお知らせを探し直すことになります。
変わることと変わらないことを一緒に書く
変更点だけを説明すると、ユーザーは残りの範囲も変わったと受け取ることがあります。影響する範囲と影響しない範囲を並べます。
一つの作業段階が変わるなら、既存資料、共有経路、権限、記録への影響を確認します。未確認の項目を「影響なし」と断定せず、確認中または別途確認が必要と示します。
画面例は新しい位置を強調するだけでなく、workflowのどこで出会う画面かを示します。プランや権限で違いがある場合は、確認できた範囲だけを書きます。
適用時期と必要な行動を一画面に置く
発表日と実際の適用日は異なる場合があります。お知らせ日、利用可能日、既存動作が変わる日、準備期限を分けます。
行動が必要なら担当者と完了条件まで示します。行動が不要なら、その事実も伝えます。最初の画面を次の形で確認できます。
対象: このworkflowを使うチーム
変更: 既存の段階で変わる一つのこと
時期: 適用日と準備期限
行動: 確認・変更することと担当者
サポート: 詳細ガイドと問い合わせ経路
段階的な提供やアカウントごとの差がある場合、全ユーザーが同時に使えるような書き方は避けます。自分の環境で適用状態を確認する公式経路を案内します。
例とサポート経路を利用場面につなぐ
メニュー名より、短い変更前後の例のほうが理解しやすいことがあります。以前の作業順序と、どの場所で選択が変わるかを見せます。
例は成果を約束する事例ではなく、動作範囲を確認する場面にします。転換率、生産性、利用率の改善について確認済みの数値がないなら、効果のようには書きません。
詳細ガイド、問い合わせ担当者、既知の制限をお知らせの近くに置きます。サポート依頼に必要な情報は、製品の公式手順を確認して案内します。
お知らせへの反応と実際の利用を分ける
FeatPaperでは、共有済みの同じリンクにある文書を更新できます。ただしリンクが維持されても、変更が自動で伝わるわけではないため、別の案内が必要です。
文書アクセス、ページ閲覧、再閲覧、リンククリックは、お知らせ資料を見た記録です。実際の機能利用や理解の完了は、製品の利用記録や顧客の応答など、問いに合った根拠で確認します。
フォローでは、どの作業で変化があり、準備が必要な部分と止まった場所はどこかを尋ねます。
対象、変わる仕事、適用時期、必要な行動、サポート経路が一画面でつながると、お知らせは役割を果たします。ユーザーは自分への影響を判断し、必要な準備を始められます。
