![見出し画像](https://assets.st-note.com/production/uploads/images/93102698/rectangle_large_type_2_0c058b104afb4421e81b379fb7882a0e.jpeg?width=800)
デザインプロセスの振り返り
今年1年を振り返り、デザインプロセスに変化があったなと思い、改めて言語化してみました。
何が変わったのか?
簡単に述べると、機能ベースのエピック・画面ベースのデザインをやめて、アウトカムベースのエピック・ストーリーベースのデザインに変更しました。
Before/Afterのプロセスの違いは、かなりざっくりとですが以下のような形です。
Before
エピックの概要
〇〇機能のリリース
機能の概要
[how]ができる
デザイン
画面A(デザイン)
画面B(デザイン)
画面C(デザイン)
・・・
After
解決したい課題
[who]が[when]のとき[what]できない
提供する価値
[what]ができるようになる
ストーリー
[how]ができる(デザイン)
[how]ができる(デザイン)
[how]ができる(デザイン)
・・・
Beforeが機能に必要な画面を定義しデザインカンプを作っていくのに対し、Afterでは課題・価値に沿ったストーリーを作り徐々に分割していって、デザインのアウトプットは基本的にCRUD単位のデザインカンプやモックになります。(開発に回すストーリーのチケットはこれをさらに細かくしたものになります)
なぜ変えたのか?
Beforeのプロセスで生じていた課題は以下です。
「〇〇機能」に含まれる要求・要件が何なのか、解釈の余地が大きすぎる
要求・要件いずれもブレた状態でデザインカンプを作る(見る)ことになるので、要求を要件が満たしているか誰も評価できない
完成した画面の羅列から、開発時の受け入れ要件を想起できない
変えてみてどうだったか
次に、変えてみてのメリットです。
デザインより先にストーリーを言語化するので、解釈の幅が狭くなった(大きいエピックのときはユーザーストーリーマッピングを行ったりした)
課題・価値と、ストーリー・デザインを比較することで、チームで要件の評価や調整ができるようになった
開発時の受け入れ要件が厳密になった
さいごに
かなりカオスだった状態から、一連の流れができました。
デザインとなるとどうしても、「画面」単位で作業をする方に思考がいきがちですが、プロダクトを利用するユーザーの目的は画面を見ることではないですよね。
デザインを通じてストーリーを可視化・評価することで、少しでも着実に価値を届けられるよう貢献していきたいです。
来年はこれに加え、スタイル・ガイドライン改善もやっていきたい、、(この辺りもだいぶ課題だらけな状態なので、、)
この記事が気に入ったらサポートをしてみませんか?