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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

今⽇話すこと Design Docs について 4 ● Design Docsとは何か ● なぜ書き始めたか ● どんな効果があったか ● どんな時に使っているか

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

「Design Docs」とは ● ゴール ● ノンゴール ● 背景 ● ユーザーストーリー ● 取組みの成功を決める指標 ● 取組みで検証する最⼤の仮説 ● 取組みが失敗するとしたら、何が原因か ● 機能要件 ● 検討した代替案 ● 取り組みの結果レポート Design Docs のなかみ 7

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

どんな時にDesign Docsを使っているか 31 Design Docsを書く粒度 ● 全部の取り組みで書く必要はない ● 少し⼤きめの取り組みで書く ● 途中でもOK、とりあえず誰でも⾒れる場所で投稿する

Slide 32

Slide 32 text

● 「なぜやるか」を明確にしてから「何をどう作るか」を考えられる ● テンプレートがあるので、施策の情報を簡単に整理して共有できる ● 「背景」や「あえてやらないこと」を共有することで踏み込んだフィードバックがもらえる「Design Docs」はいいぞまとめ 32 参考：プロダクトマネージャーの必須スキル: デザインドックの書き⽅ - Design Doc https://note.com/kosukemori/n/n968cd16c53eb