Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

デザインレビューをできていなかったコムデチームが、 自分たちが続けられるレビューの仕組みをつくった話

tnxtnxtnx
July 25, 2024

デザインレビューをできていなかったコムデチームが、 自分たちが続けられるレビューの仕組みをつくった話

2024/07/17に開催されたコミュニケーションデザイナー向けイベント「Communication Design Night vol.5」にて登壇したスライドです。
https://layerx.connpass.com/event/321945/

tnxtnxtnx

July 25, 2024
Tweet

Other Decks in Design

Transcript

  1. チームの状況 メンバー編成 IP (A) Project IP (D) Task HR (A)

    Project HR (B) Task t IP (B) Task IP (C) Task Client 1~3 days Mid Mid Mid Mid Jr Sr Mid Partner Partner Spot Partner Spot
  2. 走らせ始めた仕組み 取り組みのサマリ・流れ レビューに関する 本の輪読会 1 e レビューの共通認識づくC e 実践する仕組みの設計と並行してインプット e

    まず始めて継続しやすいレビューの機会づくC e 進行中のタスクへの取り入れやすさ e アウトプットの棚卸しと振り返C e チーム相互の承認と学習の機会 1month 7月から継続中 準備 実践 クイックレビュー 2 Monthly Doya 3
  3. 走らせ始めた仕組み 1 輪読会 今回取り上げた本 本のサマリとよかった点 みんなではじめるデザイン批評 ―目的達成のためのコラボレーション&コミュニケーション改善ガイド • デザインFBにはタイプやアンチパターンが存在し、 体系的に捉えることで、

    批評をはじめとする業務のコミュニケーションを改善する余地があt • 批評の目線を合わせることで、 デザインの目的に立ち返り、 効果的にFBをし 合うことができt • 批評をプロセスに組み込み、 小さく気軽に始めながら、 諦めずに改善と継続 を続ける中でよりよい批評ができるようになる
  4. 走らせ始めた仕組み 1 輪読会 実際の進め方 約1h × 4週で開催 参加者全員でその場で読み合わせ、 新鮮な学習を共有 同期で読む

    + 学びのシェア 第1回 第2回 会の目的共有 同期で読む + 学びのシェア 同期で読む + 学びのシェア 実践に向けたワークショップ 第3回 第4回 会におけるグランドルールを共有 “ 本に対する理解を深めるこ‰ “ 本の内容から学んだことを、 お互い に分かち合うこ‰ “ 実験的であり、 実践のための学びに Do Don’t “ 本の要約を完ペキにつくるこ‰ “ 共有できるのが感想や思ったことだ けになるこ‰ “ 場の進行を他人任せにすること 実際の進め方
  5. 走らせ始めた仕組み 1 輪読会 実際の進め方 約1h × 4週で開催 B Gaudiyにおける批評の
 理想の在りA

    B 実践したいこ8 B そのために必要な仕組み・環境 同期で読む + 学びのシェア 第1回 第2回 会の目的共有 同期で読む + 学びのシェア 同期で読む + 学びのシェア 実践に向けたワークショップ 第3回 第4回 参加メンバーで意見出し 実際の進め方
  6. 走らせ始めた仕組み 1 輪読会 効果やメンバーからの声 R 本を読むことに慣れていないとこからスター0 R 読書の内容がしっかり入ってきたわけではない R 理解はこれからだが、

    FBやレビューが体系化されているということ自体はわかっb R よりよくする余地があることが分かった R 事前のコンテキストを共有することが大事ということを再認識しb R 変わったこ R =同じ意識・認識のメンバーが増えれば、 レビューはやりやすくなりそ‰ R 変な感情になることを回避できそう
  7. 走らせ始めた仕組み 1 クイックレビュー やり方 Dairy(チーム昼会) チェックイン(日報) 各業務へ W 前日進めたこR W

    1日のタスク棚卸し W 要件定義の精度アッ W 関係者への追加ヒアリン‚ W デザインのブラッシュアップ W 雑談 (5m‰ W タスクにおいて特筆したい共有・相談 (5~10m)  →時間内に収まらないボリュームであれば、 別途MTGで扱う Slackワークフローで 非同期で共有 13:00 13:30 クイックレビュー (15~20m) 要件定義の レビュー タスク起票から2日以内 納品日の前日まで アウトプットの レビュー
  8. 走らせ始めた仕組み 3 Monthly Doya 取り入れた背景 自己効力感UPと評価材料の収集 チーム全体感と 次に生かせるナレッジづくりへ 丁寧な振り返りと称賛、 今後に活かしやすさを重視

    制作タイムラインを意識せず、終わった後のFBがあるからこそ、 遠慮なく言えるし、次回に活かしてみようと思える場づくりに 一ヶ月やってきたぞという振り返りと自分への労い、 チームからの褒め合いと称賛。 評価者への共有や次の目標を立てる材料に。
  9. 走らせ始めた仕組み 3 Monthly Doya やり方 we 会の構成説明 【5分v e 下部のDBビューを利用して、

    1ヶ月のアウトプットを振り返りながら制作物や要件をシェア 【1人5分 / 25分v ce 各自ボードに用意したデザインを1人ずつレビューし合う 【1人10分 / 50分v Ieレビューされたデザインのタスクチケットのメモ欄にレビューのサマリーをまとめて持ち帰 る(FigJamのURLも記入) 【5分v ‘e 会の振り返り雑談 【5分】 “ 評価者への共ˆ “ 次回の業務に活かす “ ワークショップ準¢ “ 制作物や要件のまとめ 前準備 Doya後 Monthly Doya (90~120m) アウトプットの 共有と称賛 やったこと共有と褒め Good&More ピックアップした 制作物のレビュー FigjamとNotionで 共有
  10. 走らせ始めた仕組み 3 Monthly Doya アウトプットの共有と称賛 これのこの表現は自分では思いつかなかった! 1ヶ月あっという間だったけど けっこう数作ったね 〜〜〜という要件に対しての 世界観の落とし込みがすごい!

    アイコンみたいな、 メイン以外の作り込み 要素もかわいすぎる 細部の鬼、 すごい よくあるデザインを盛り込むのでなく、 内側にあしらいを詰め込んでいく、 という考え方が 自分では思いつかなくて引き出しが増えた!
  11. 走らせ始めた仕組み 3 Monthly Doya ピックアップした制作物のレビュー AとBの表示はあえて 差別化したほうがよい? ここは製作ポイントをもうすこし言語化して 解像度をあげてからデザインできると良かったかも? デザインの前の体験や感情から、

    表現を考えみるのはどうかな? CにフォーカスしてDを流して把握してしまうけど、 実際に見せたい情報は意図通りになってる?誤解が起きそう? レアリティの表現のところ、 このクリエイティブを見える前の体験から、 どんな印象になっていたいかの設計と表現を繋げて考えると よりデザインの奥行きがでそうですね!
  12. 走らせ始めた仕組み 3 Monthly Doya 効果・メンバーからの声  デザインレビューを受ける場がこうして設けられるのは嬉し’  1ヶ月のアウトプットを最初に振り返れるのい’ 

    世に出なかった案についてもFBもらえるのもありがたすぎる。成仏できたŸ  クリエイティブ単体ではレビューがしづらい。目的なんなんだっけ?にも言及するx  5W1H的なカードに要件をまとめて見せながら話していけるとよいか‹  moreがあるポイントには、必ずプロセス自体の改善点が存在するのは気づきだっV  クリエイティブだけではないこともあ“  本人コメントが予め準備されているその観点を深堀りできそうだ  アウトプットに加えて、事前に記入する項目は一定必要かも Good 課題
  13. まとめ 取り組みのサマリ・やってみた学び レビューに関する 本の輪読会 1 準備 実践 クイックレビュー 2 Monthly

    Doya 3 土壌づくりで会話の内容や スコープできる視点が変わる 結局、 アウトプットの課題や問題も 要件定義の段階で生まれていることがほとんど Ž レビューの共通認識づくx Ž 実践する仕組みの設計と並行してインプット Ž まず始めて継続しやすいレビューの機会づくx Ž 進行中のタスクへの取り入れやすさ Ž アウトプットの棚卸しと振り返x Ž チーム相互の承認と学習の機会
  14. まとめ これから取り組んでいきたいこと デザインや 要件定義の前から レビューを始める k クイックレビューの短い時間で要件定義を見ていくにはまだ扱いづら k 要件定義の精度がより客観的に見える形q k

    依頼フォーマットを改善(5W1Hがわかるシートetc.)し、レビューに持 ち込みやすく k 依頼者など、デザイナーじゃないメンバーからどうレビューを得やすく するかp k デザイナー同士のFBだけで終わらないようにする 土壌づくりで会話の内容や スコープできる視点が変わる アウトプットの課題や問題も 要件定義の段階で生まれていることがほとんど デザイナー以外にも レビューの土壌をつくり 広げていく