考慮漏れ撲滅！デザイナーが受け入れ条件を書く
担当するプロダクトがリリースされて数ヶ月、日々機能追加や改善デザインを行なっています。
デザイン要件をエンジニアさんに伝える際、Figma上にメモを書き込んだり、ドキュメントにまとめたりしていますが、後から「この場合はどうなりますか？」といった考慮漏れが見つかることがよくあります。エンジニアさんからの質問でFigmaコメントがいっぱいになることも...
〜😇 😇 😇 〜
プロダクト開発に関わるデザイナーなら共感できるのではないでしょうか？
あるときQAさんからの指南で、デザイナーが受け入れ条件（受け入れ基準）を書くようにしたらとても幸せになったので紹介させてください。
受け入れ条件：ユーザーに届けたい機能のチェックリスト
受け入れ条件（受け入れ基準）といっても組織によってやり方はそれぞれ。リリース基準の一つとして受け入れ条件があり、PdM / POが書くことが多い印象です。
SmartHRさんのこちらの記事も参考になります。
受け入れ条件を書く場所
追加機能をデザインする際、チームメンバーがデザインの背景や意図をいつでも見られるようにドキュメントを残すようにしています。ここに受け入れ条件を追加することにしました。
デザイン要件ドキュメントの例
・背景、経緯、目的
・ユーザーストーリー
・FIXした画面のキャプチャ
・FIXに至るまでに検討したポイント
・エラーのパターン
・受け入れ条件（← NEW 🎊 ）
受け入れ条件の書き方
手動PIN設定機能の受け入れ条件の一部
〜すると〜が表示される。
〜すると〜へ遷移する。
〜の場合は〜が表示される。
〜の場合は〜へ遷移する。
デザインしたときのことを思い出しながら画面の仕様を一つ一つ書き出していきます。最初は粒度が難しかったですが、書きながら慣れていきました。
正直なところ最初は、自分に書けるかな？書くのに時間がかかりそうだな...と戸惑いましたが、慣れないながらも試しに書いてみたら、すぐに効果を実感することができました。
受け入れ条件を書くことによる効果
1.デザイン作成漏れ、考慮漏れに事前に気づく
受け入れ条件を書く過程で自分がデザインした画面を俯瞰して見ることで、遷移元の画面を作っていなかった！とかロールが違う場合の表示を考慮できていなかった！といったことに気づくことができました。
2.コミュニケーションコストが下がる
考慮漏れが減ったことで、エンジニアさんからのFigmaコメントやSlackでの質問が減りました。チームのコミュニケーションコストが下がりスピーディーに実装に入れるようになりました。
QAさんが確認する際にも「これは意図した挙動になっていますか？」といった質問が減りました。
3.リリース前のチェックリストとして使える
リリース前に最終確認をするときには、デザインを作成してから時間が空いていることがほとんどです。確認する際は、自分が作った受け入れ条件をチェックしていけばいいので安心です。
ついこの間も、リリース前になってサーバーエンジニアに伝えるべき変更を伝え忘れたことに気付くなど、凡ミスを防ぐことができました（汗）
受け入れ条件があると、作り側/テスト側双方の視点で「要件/要求に対して適切に満たしているか」をチェックできるのでプロダクトの品質向上に役立ちます。
まとめ
わたしたちのチームでは、中小規模のプロジェクトではデザイナーが受け入れ条件を書くようにしたらいまのところとてもうまくいっています。今ではデザインとセットで受け入れ条件を書かないと不安になるくらいです。
みなさんは考慮漏れをなくすためにどんな工夫をしていますか？ぜひ教えてください！
この記事が気に入ったらサポートをしてみませんか？