このページのゴール：

全体の流れ

①ガイドの企画　→　②企画の承認　→　③ガイドの実装　→　④ガイドのテスト　→　⑤ガイドのリリース　→　⑥ガイドの評価

①ガイドの企画

ガイドの企画担当が、エンドユーザーの課題、Onboardingを使ってどのようにしたいのか？を言語化します。

②企画の承認

ガイドの承認者が①の企画を承認します。

#確認すべき事項 A. 同一アプリケーション/同一ページ内で複数の表示をしようとしていないか？ 　└「どこのページで」を確認 B. 同一ユーザーに複数のガイドを連続して表示しようとしていないか？ 　└「対象のエンドユーザー」を確認 　└NG例： ポップアップを閉じたのにすぐ出てくるような体験になっていないか？それがユーザー体験を阻害しないか？ C. 課題設定に問題がないか？ 　└課題が事業の推進を妨げているものになっているか？ 　└課題を解決することで多くのエンドユーザーを救えるか？ 　└課題が実際に発生しているか？ D. 解決策が明らかにユーザー体験を阻害するものになっていないか？ 　※やってみないとわからないものは問題なし E. ガイドの評価が決められているか？

③ガイドの実装

作成者がガイドを実装します。

#実装時に意識すること A. ユーザーの操作の邪魔にならないように工夫しているか？ B. 文字数は少なく簡潔に作れているか？ 　└エンドユーザーにとって情報過多になっていないか？ C. フォントは大きめで見やすくなっていないか？ 　└読みやすいと言われる最小のフォントは16pxと言われています。これより小さくなっていないか？ D. エンドユーザーにとってわかりやすいか？

④ガイドのテスト

作成者がガイドをテストします。

プレビューにおけるテスト

Onboardingのプレビュー機能を使ってテストする

#プレビューにおけるテストで意識すること A. 作ったガイドの見た目が問題ないか？ B. フォーカスを当てている場合、フォーカス外れが発生していないか？ 　└複数のアカウント環境で確認することを推奨します。（アカウント環境によって、クラス名が変わるなど、フォーカス設定が違う場合があるため。別途OnboardingCSと相談しながら進める。） C. ヒントの場合、配置場所が適切か？他のページで配置されていないか？ D. エンドユーザーにとってわかりやすいか？

テスト環境タグにおけるテスト

#テスト環境タグにおけるテストで意識すること A. 作ったガイドの見た目が問題ないか？ B. フォーカスを当てている場合、フォーカス外れが発生していないか？ C. ヒントの場合、配置場所が適切か？他のページで配置されていないか？ D. （パラメータの設定をテスト環境タグでも行っている場合）パラメータのとおりに正しく動くか？ E. 自動表示条件に合致した場合/そうでない場合で挙動が正しいか？ F. エンドユーザーにとってわかりやすいか？ G. ツアーとヒント、ツアーとポップアップ、ポップアップとヒントなど複数のガイドが混じり合った状況でもエンドユーザーにとっていい体験になっているか？

A~Eは作成担当者が実施。 F~GはQA担当/UXデザイナーが実施。

⑤ガイドのリリース

作成者（あるいは別の担当者）が関係者に公開する旨周知し、ガイドを公開します。

#リリース直前の確認 A.社内にガイドをリリースする旨の周知 　└作成者（あるいは別の担当者）が 　└公開◯日前までに 　└〜〜の関係部署宛に 　└XX（何の情報）を周知する #リリース後の確認 A. 本番でも今までのテストと同様の動きをしているか？ B. 違和感のある挙動になっていないか？

⑥ガイドの評価

ガイドリリース後、PJチーム全体で①の企画で設定していた評価に基づき、振り返りを行います。

振り返り後、ネクストアクションを決定します。

（参考）デザインルールについて

ガイドを統一的な形で作っていくために、企画前にデザインルールを作っておくことを推奨しております。

どのような項目が必要か？は以下をご参照ください。

ツアー・ポップアップ

ヒント