1. デザインスプリント or コラボレーティブデザイン or デザインスタジオ的な何か

参加者

プロダクトに関わりある幅広い分野の人がいればいるだけいい

• エンジニア
• デザイナ
• pm
• cs(すでにある場合)
• マーケティング担当の人やセールスの人

方法

1. mtg開催までに要件に対する画面のアイデアをスケッチしてもらう(手書き or figmaなり何なりで)
2. 作成したスケッチのスクショ等をmiroなどのサービスを使って共有しておく
3. mtg当日に各々のスケッチをプレゼン
4. 聞いてる側はよかったアイデアにチェック(絵文字つけるとか)
5. スケッチでわからないところは質問して不明点をなくす
6. デザイナはmtgででたアイデアも参考にワイヤーフレームを作成する

2. ワイヤーフレーム・デザインに対してデザイン批評する

参加者

プロダクトに関わりある幅広い分野の人がいればいるだけいい
ただし司会(ファシリテーション)が大変なのでできれば最大6人までに留めたほうがいいらしい

• エンジニア
• デザイナ
• pm
• cs(すでにある場合)
• マーケティング担当の人やセールスの人

方法

事前準備

(以下で出てくるプロダクトは機能にスコープを狭めてもいいかもしれない)

• 基盤をまず作る(デザイナ or PM or PO)
  • ペルソナ(プロダクトを使うと想定されるユーザー)
  • シナリオ(プロダクトが使われる想定のシチュエーション)
  • 原則(プロダクトの前提)
  • 目的(プロダクトを通して成し遂げたいこと)
• ファシリテータはみんなではじめるデザイン批評を読む(デザイン批評のルールを参加者全員に共有したほうがよさそうだけど難易度が高そうなのでファシリテータが理解し、デザイン批評を通して参加者にデザイン批評のルールを認知してもらう)

基盤はデザイン批評の行う際に毎度確認するので、ペラ1(ミニ・クリエイティブ・ブリーフって言うらしい)にまとめる

ミニ・クリエイティブ・ブリーフに記載されていることとしては

• プロダクトの問題についての説明、目的の簡潔なまとめ
• プロダクトの主要なユーザー
• プロダクトが使用される主なシナリオ
• プロダクトのために設定されたビシネス上の目標
• 守るべきデザイン原則

デザイン批評当日

1. 基盤の説明(ミニ・クリエイティブ・ブリーフを使いつつ)
2. (デザイン批評が2回目以降であれば基盤が前回と変わってないか確認、更新する)
3. デザイナは作成したデザインを使って、デザインの目的を簡潔に説明する
4. 参加者は作成されたデザインに対して批評を行う(デザイン批評のルールに準ずるようにファシリテーターは注意する)
5. 出てきた批評を記録
6. 出てきた批評を元にデザインをアップデート
7. 出てきた批評に対する答えをドキュメント化しておく
8. 1に戻る(デザイン批評を開催する)

3. デザインレビュー
   完成したUIデザインを承認する場

• 継続して行われるデザイン批評を通してワイヤーフレーム・UIデザインをブラッシュアップする
• デザイン批評を通してプロダクトの基盤がチームに浸透しているのでデザインレビューでみるべき場所をデザイン批評の参加者は理解している状態になっている

1. 前提を説明する
2. 作ったデザインに対してどのように目的を達成しているか説明する
3. 目的が達成されているのかどうかをチェックする
4. 達成されていないと感じたら、目的が達成してないと感じた理由を伝える
5. もらった意見をデザインに反映する