Design Docs を活用して効果的にプロダクト改善

Transcript

1. 📝 Design Docs を活⽤して効果的に プロダクト改善 kabechiyo13

2. ⾃⼰紹介 かべちよ 2021卒 Qiita株式会社 デザイナー（宮城→ 名古屋） QiitaのサービスのUIをデザイン、コーディング、バナー作成など 2

3. QiitaでHTMLやCSS、Figmaなどの記事書いてます ⾃⼰紹介 https://qiita.com/kabechiyo13 3

4. 今⽇話すこと Design Docs について 4 • Design Docsとは何か • なぜ書き始めたか

   • どんな効果があったか • どんな時に使っているか

5. Design Docsとは Design Docs 施策の概要をまとめたドキュメント📝 5

6. 「Design Docs」とは https://note.com/kosukemori/n/n968cd16c53eb 6

7. 「Design Docs」とは • ゴール • ノンゴール • 背景 • ユーザーストーリー

   • 取組みの成功を決める指標 • 取組みで検証する最⼤の仮説 • 取組みが失敗するとしたら、何が原因か • 機能要件 • 検討した代替案 • 取り組みの結果レポート Design Docs のなかみ 7

8. • 達成したいことからやることがずれてきてしまう • 施策の⽬的や背景をうまく整理して共有できていない 「Design Docs」を書き始めた背景 施策を進める上での課題 8

9. ＞ 達成したいことからやることがずれてきてしまう 「Design Docs」を書き始めた背景 ものづくりが好き🎨 「この機能を触るならあれもやった⽅が良いのでは」 「こうするともっと良くなる」「ついでにこれもやりたい」 取り組みの内容が肥⼤化、脇道に逸れていく... 9

10. ＞ 達成したいことからやることがずれてきてしまう 「Design Docs」を書き始めた背景 なんか要件膨らんでるけど、 この施策ってなんのために やるんだったっけ？🤔 10

11. 〇〇をやりたい、今やる価値があるはず💭 「なぜそれを今やる必要があるのか」 をうまく説明できない ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書き始めた背景 11

12. Design Docsを書き始めた背景 このドキュメントを書けば、 ⽬的や背景を明確にして施策を進められそう... 12

13. Design Docsを書き始めた背景 まずは今取り組んでいる施策でDesign Docsを書いてみよう 13

14. Design Docsを書いてみて 実際書いてみて... 感じていた課題に効果がありました󰗨 14

15. ＞ 達成したいことからやることがずれてきてしまう Design Docsを書いてみて 「こんな機能にしよう！」 「UIはこんな感じが良さそう…」「ここの仕様は...」 施策を始めるときに 「何を作るかやどう作るか」 につい熱中してしまう 15

16. ＞ 達成したいことからやることがずれてきてしまう Design Docsを書いてみて 「⼀旦施策について整理しよう」 Design Docsを書き始める✍ まず最初に取り組みのゴールや その取り組みをする背景といった施策の情報を書き、 最後に「具体的な機能要件」を書く

    16

17. ＞ 達成したいことからやることがずれてきてしまう Design Docsを書いてみて 「何をどう作るか」に辿り着くまでの時間で 冷静になって情報を整理できる🍨 「⾃分がやろうとしてたこと、ちょっと⽬的から逸れてたな」 と気がつける 17

18. 🕑 使える時間には限りがあるので 効果的に時間配分をするためにも冷静な整理は必要 ＞ 達成したいことからやることがずれてきてしまう Design Docsを書いてみて 18

19. ✅ 「やりたかったけどスコープ外のこと」も 「検討した代替案」や「ノンゴール」に書ける ＞ 達成したいことからやることがずれてきてしまう Design Docsを書いてみて 19

20. 📝 テンプレートがあることで、 抜け漏れなく情報を整理できる ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて 特にバックグラウンド‧ノンゴール‧検討した代替案が󰗨 20

21. きっかけとなったSlackのやりとり、過去に同じ検討をしたログ、 ユーザーからのフィードバック、関連する数値⽬標のドキュメント... 「なぜこの取り組みを今やるか」 がわかる情報をまとめる ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて バックグラウンド 21

22. ⼤体の機能開発や改善は、 やらないよりはやった⽅が良い ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて 22

23. 逆に今それをやるべき理由がないなら、 他に優先すべき取り組みがあるかも ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて なぜ今この施策を実施するのか？があると、 理解度や納得感が上がる 23

24. 将来同じ箇所を触ることになった時 ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて 「なぜ当時この取り組みをしたか」の背景がわかる 「今は事情が変わったから変えても良い」 「この背景があるならここは変えないほうが良い」 どう変えるかの判断材料になる 24

25. ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて スコープ外に決めたことや 選ばなかった他の案を書く ノンゴール‧検討した代替案 25

26. 誰かが「すでに考えた分」を⼟台できる ＞ 施策の⽬的や背景をうまく整理して共有できていない Design Docsを書いてみて さらに踏み込んだフィードバックがもらえる 技術的な理由などで難しいと思っていたことに、 「こうすれば実現できるかも」などの提案ももらえるかも 26

27. どんな時にDesign Docsを使っているか • 依頼を受けてデザインを作成するとき • ⾃分が施策を提案するとき • 作成したデザインをレビューに出すとき 主にこんなタイミングで活⽤してます🎨 27

28. プロダクトマネージャーから背景や⽬的と⼀緒に、 施策の内容を共有された ＞ 依頼を受けてデザインを作成するとき どんな時にDesign Docsを使っているか デザインを作成する前にDesign Docsを書くと プロダクトマネージャーと⾃分の認識が揃っているか確認できる 28

29. Design Docsを書くことで⽬的や背景を整理できる ＞ ⾃分が施策を提案するとき どんな時にDesign Docsを使っているか 施策のプレゼン資料として使える GOが出たらそのまま施策のドキュメントに 29

30. 施策によって、 エンジニア‧ビジネスメンバー にもレビューしてもらう ＞ 作成したデザインをレビューに出すとき どんな時にDesign Docsを使っているか Design Docsを共有すれば、 チームや職種が違くても背景などをスムーズに共有できる

    30

31. どんな時にDesign Docsを使っているか 31 Design Docsを書く粒度 • 全部の取り組みで書く必要はない • 少し⼤きめの取り組みで書く •

    途中でもOK、とりあえず誰でも⾒れる場所で投稿する

32. • 「なぜやるか」を明確にしてから「何をどう作るか」を考えられる • テンプレートがあるので、施策の情報を簡単に整理して共有できる • 「背景」や「あえてやらないこと」を共有することで踏み込んだ フィードバックがもらえる 「Design Docs」はいいぞ まとめ

    32 参考： プロダクトマネージャーの必須スキル: デザインドックの書き⽅ - Design Doc https://note.com/kosukemori/n/n968cd16c53eb