見出し画像

デザイナーが要件仕様作るってどんな感じ？

akippa_yokoyama

前置き

デザイナーが要件仕様作るとどうなるのか

デザイナーなんだからデザインだけを作りたいんだ！
はい、その気持ちよぉくわかります。デザインだけに集中するとアウトプット量もスピードも磨き抜かれるでしょうし、それも魅力的だと思います。
じゃあなんでやっているのかと言うと、要件仕様から考えた方が(私は)楽しいからです＾＾

デザイナーが要件仕様を作成することは、単なるプロジェクト進行のためのドキュメント化作業ではなく、いろんな利点があると考えています。
デザインの成果物に対する影響は大きいと考えていて、アウトプットのクオリティ向上に効果的だと感じています。
それだけでなくプロジェクト進行全体にポジティブな影響があると考えていて、特にデザインと要件の同時並行的な詰め込みには多くの利点があると思います。

利点1：デザインと要件を同時に詰めることで、プロジェクトのスピードが向上する

一般的には、要件が最終的に確定されるまでデザインが開始されないことが多いのではないでしょうか。
しかし、このアプローチではプロジェクトの時間枠が制約され、スケジュールの遅れが発生しやすくなります。
デザイナーが要件を同時に詰めることで、プロジェクトの進行がスムーズになり、迅速なプロトタイプの開発や修正が可能となります。

利点2：デザイナーが要件書を作成することで、デザインやUXに関する理解が深まる

要件書では、プロジェクトの目的や制約・ニーズなどを明確に定義します。デザイナーがこれらの要件を理解し、それをデザインに反映させることで、より使いやすいデザイン設計ができると考えます。
要件を深く理解することで、デザインの方向性やアプローチの可能性と制約を自身で判断できるので、利用者のニーズにより適した成果物を提供することができます。
また、デザインと要件の同時詰め込みは、利用者中心のデザイン思考を促進します。要件の明確化は、利用者のニーズや期待を理解し、それに基づいてデザインを展開することを可能にし、UXの向上に繋がります。

利点3：デザインと要件の同時詰め込みは、チームのコミュニケーションを促進できる

デザイナーが要件を作成する際には、エンジニアやプロジェクトマネージャーはもちろん社内ステークホルダーも含むチームメンバーとの密接なコミュニケーションが必要となります。このプロセスは早い段階で要件を明確にすることに繋がり、後々のプロジェクトの方向性の変更や調整が容易になります。

事例紹介

つらつらと利点を紹介しましたが、結局抽象的にサマった物なんて信用できんのじゃい！現場の事例を見せんかい！という方に向けて、今回は開発中のtoB向け社内管理画面の事例をご紹介したいと思います。

チーム構成

まずチーム構成はこんな感じです。今回はプロジェクトマネージャーにはプロジェクトの進行管理と社内ステークホルダーの取りまとめを行ってもらい、要件仕様の策定を私が行うという役割分担を行いました。この辺りも案件に応じて柔軟に分担したらいいんじゃないかなというのが私の考えです。

  • 社内ステークホルダー

    • 営業 / 掲載 / CS

  • プロジェクトマネージャー

  • デザイナー

  • エンジニア

  • テスター

要件

プロジェクトマネージャーが営業チームからヒアリングした要望をもとに、開発スコープを決め要件を精査していきます。ここはプロジェクトマネージャーと協働です。

まずはユースケースを洗い出します。例えば「ケース1のみ」 or 「ケース1,2両方」で必要な機能が変わってきます。
どこまでスコープにするかの判断は、ターゲットを明確にした上でインパクトを試算し、プロダクトマネージャーやステークホルダーも巻き込んで決定します。
（ここがはっきりしてないと、追加要件が一生止まらないことになるのでとっても大事）

ユースケースとターゲットの洗い出し

上記を踏まえて最終的に要件を決定します。
この時点でどんな風に機能を実現させるのかは、エンジニアに予め相談し要件として混ぜ込むことが多いです。

FIXした要件

仕様

仕様はWFを作りながら、逐一書いていきます。デザインとして落とし込みながら考えた方が抜け漏れなく仕様を考えらます。
っていうかもうこの時点では要件のインプットは十分な訳で、もう早く思考を画面に起こしたくてうずうずしています。

デザイン作りながら仕様を書いていく

仕様はWF→デザイン→実装に段階が進むにつれ、様々なメンバーにレビューを挟みつつ、考慮漏れがあった際は都度書き足していきます。
リリースまでは考慮漏れがないか、ドキドキしちゃいます。

デザインを進めていくと、実際の操作やアクションが明確になり都度どんな結果を返すのが正しいか？を決めていかなければなりません。
こまけぇ・・と思うんですけど、これを決めないとデザインが作れません。
作業的には今日Figma触ってねえな・・みたな日も発生します。

ケースごとにどんなアクションを返すかを網羅する

デザイン作成は必要ないんだけど、仕様として決めておかなければいけないことも発生します。
例えばDBを変更することによる従来機能への対応もその1つです。
この手の話は気を利かせたプロジェクトマネージャーやエンジニアが巻き取って対応してきてくれたんだなーと実感し感謝すると共に、デザイナーがボールを持つことでUXに考慮した解決策を取りやすくなるというメリットもあるなと思いました。
例えばデザイン修正が必要だね！ということも判断しやすく、他メンバーも発言しやすいと思います。

従来機能への追加ではなく新機能として独立させる判断をスムーズにできた

このような仕様をまとめつつ、最終的にデザイン画面の分岐・活性条件などの挙動はFigmaにコメントで記載していきます。
これはデザイン制作時も常に行いますが、仕様と同時設計を行うことで一番効く打ち手を考えることができるというのは利点です。

画面の分岐・活性条件などを書き連ねる

まとめ

今回はデザイナーが要件仕様作ったらどうなるの？ということを事例を交えてご紹介してきました。
デザイナー視点でデザインへもたらす良い影響もお伝えしたかったですが、いかにチームがうまく回るようにコミットできるかも大切だと思っています。
こういったプロセスで1つでも現状課題が解決できるよう、これからも日々精進していきます！
読んでいただきありがとうございました！


いいなと思ったら応援しよう！