Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AbemaTV プロダクトデザイン 2.0

518 views

Published on

This presentation describes AbemaTV's recent product design methods. The methods are aimed at having the product keep evolving with the users, the business, and the developers for more than 10 years.

Published in: Design
  • Be the first to comment

AbemaTV プロダクトデザイン 2.0

  1. 1. AbemaTV
 プロダクトデザイン 2.0 株式会社サイバーエージェント 五藤 佑典 - 2019.04.22 PM ナイト LT -
  2. 2. • California State University, San Bernardino グラフィックデザイン専攻 • ソフトウェアエンジニア @ サイバーエージェント • 株式会社 AbemaTV 開発本部 • New Device チーム • あらゆるデバイスに AbemaTV を展開するための技術を
 提供するチーム • Streaming Client チーム • AbemaTV の再⽣品質を軸に UX エンジニアリングに
 コミットするチーム • 動画技術エバンジェリスト • 世界各国に⾜を運び動画技術に関する情報をキャッチアップし、
 社内外の動画サービスの発展に貢献するロール • DesignOps 推進バックエンド • ⼤規模組織でスケールできるプロダクトデザイン開発組織構築 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_
  3. 3. Atomic Design
 堅牢で使いやすいUIを効率良く設計する https://www.amazon.co.jp/dp/B07CJ5TLK2
  4. 4. はじめに… 本⽇の補⾜資料たち
  5. 5. PM • PM = Project Management or Product Management ? • プロジェクトマネジメント = ⽬的達成のための活動 • プロダクトマネジメント
 = プロダクト価値最⼤化のための活動
  6. 6. プロダクトデザイン 2.0? AbemaTV を 3 年間運⽤して表⾯化してきた
 プロダクト価値最⼤化を阻害する要因を解決するための
 デザイン活動における次の⼀⼿
  7. 7. プロダクトデザイン 1.0 • 1 回 1 回の機能リリースがゴール • プロジェクトマネジメントと違いがない • デザイナーがデザインカンプ(Sketch データ)を作り、
 エンジニアが実装 • デザインの意図はデザイナーしか把握できず、
 実装はエンジニアしか把握できなかった • リリース後のデザイン評価がバラバラ
  8. 8. デザインを再考する そのままでは価値がない素材を適切に設計して
 新しい価値を創り、ユーザーに届けること
  9. 9. プロダクトデザインの素材とユーザー? 機能要件 エンドユーザー 素材 ユーザー ⼈が認識しているプロダクトデザイン デザイン
  10. 10. プロダクトデザインの素材とユーザー? 機能要件 エンドユーザー 素材 ユーザー 機能リリースがゴールであれば
 これだけでもプロダクトデザインは可能 デザイン
  11. 11. 実際のプロダクトデザイン 事業要件 機能要件 技術要件 事業者 エンドユーザー 開発者 デザイン 素材 ユーザー デザイン デザイン 実際は機能リリースだけがゴールではない
  12. 12. 実際のプロダクトデザイン 事業要件 機能要件 技術要件 事業者 エンドユーザー 開発者 デザイン 素材 ユーザー デザイン デザイン ⼈は知らないうちにプロダクトを
 さまざまなユーザーに向けてデザインしている
  13. 13. プロダクトデザイン 1.0 の課題 AbemaTV は「10 年間進化し続けるサービスを創る」ことが課題 • 1.0 では「10 年間進化し続けるサービスを創る」ことは難しい • プロダクトの進化は負債によって停滞する • バラバラにデザインされたプロダクトは負債を抱える • 総合的に⾒た対象要素とユーザーにデザインスコープを広げる必要性
  14. 14. プロダクトデザイン 2.0 事業要件 機能要件 技術要件 事業者 エンドユーザー 開発者 デザイン 素材 ユーザー
  15. 15. 2.0 は繰り返すデリバリーもデザイン エンドユーザー 事業者 開発者 ユーザー 課題 課題 課題 デザイン エンドユーザー 事業者 開発者 ユーザー素材
  16. 16. 2.0 は繰り返すデリバリーもデザイン エンドユーザー 事業者 開発者 ユーザー 課題 課題 課題 デザイン エンドユーザー 事業者 開発者 ユーザー素材 10 年続くプロダクトのライフサイクルを
 デザインしたい
  17. 17. デリバリーもプロダクトデザインの⼀部 • どんなプロダクトデザインも初期リリース時は最低 • プロダクトは継続的で正確な改善によってのみデザインされる • 特にデジタルプロダクトは常時変更可能でそれが競争⼒
  18. 18. デリバリーもプロダクトデザインの⼀部 • どんなプロダクトデザインも初期リリース時は最低 • プロダクトは継続的で正確な改善によってのみデザインされる • 特にデジタルプロダクトは常時変更可能でそれが競争⼒ 複数のユーザー(エンドユーザー、事業者、開発者)に対する
 デザインを管理する⼿法が必要
  19. 19. デザインデリバリーの管理 デリバリーの単位を定義する ストーリー
  20. 20. ストーリー駆動開発 全てのデザインの変更はエンドユーザーの⾏動(ストーリー)に
 変化を与える⽬的で⾏う • 仮説(現状の課題と予想される変化値)を検証できる単位で
 デザイン変更をデリバリーする
  21. 21. ストーリーチケット ストーリーをデリバリーするために必要な全てのタスクを
 ストーリーチケットに紐づいたチケットとして管理する
  22. 22. ストーリーのデリバリーに
 必要なタスクの進捗が俯瞰できる
  23. 23. ストーリーオーナー ストーリーを確実にデリバリーするというミッションに対して
 ⾃分⾃⾝が当事者意識を持って向き合うロール • ストーリーに対する本質的理解 • ストーリーデリバリーを完遂するための⾃⾝のパフォーマンス把握 • チームメンバーやチーム外⼈員などを活⽤した解決⽅法の模索
  24. 24. • ストーリーごとに
 ストーリーオーナーは変わる • 定例ミーティングで
 各オーナーが⾃分のストーリーの
 進捗共有をファシリテートする ストーリーオーナーの⼈
  25. 25. ストーリーオーナーが取り組む視点 • エンドユーザーに対するデザイン 2.0 • 事業者に対するデザイン 2.0 • 開発者に対するデザイン 2.0
  26. 26. エンドユーザーに対するデザイン 2.0 プロダクトで良いとするユーザー体験を理解し、
 ストーリーのデザインを推進する • ストーリーの中でユーザーがどのような情報を得て、
 どんなモチベーションを持って、
 意図する⾏動を促すのかをデザインする
  27. 27. 描いたストーリーが
 定義したユーザー体験に沿っているか
  28. 28. • ストーリーデザインは
 ワイヤーフレームに似た
 表現で制作する
  29. 29. どんな情報を得て…
  30. 30. どう⾏動するか
  31. 31. https://ygoto3.com/posts/story-assured-design/ ストーリーデザインの詳しい
 アウトプットに興味がある⽅はこちら
  32. 32. エンドユーザーに対するデザイン 2.0 カスタマージャーニーマップ
 KPI の変化に現れないエンドユーザーの⾏動・感情・思考・不満を俯瞰する
  33. 33. 事業者に対するデザイン 2.0 説明責任を果たすストーリーのデザインを推進する • デザインの意図をファクト(事実)によって説明する • デザイン変更に対して KPI を設定する • 事業指標に関する変化が計測可能なようにデザインする • 不確実性を最⼩化するデザイン戦略を取る
  34. 34. ファクト(事実)から
 仮説を⽴てる
  35. 35. 仮説の課題を解決する 狙いを共有する
  36. 36. 必要であれば
 A/B テストも設計する
  37. 37. 狙いを定量評価するための
 KPI を設定する
  38. 38. KPI 設定と分析をどう実践するか Google Analytics
 データの分析会を
 定例で⾏う
  39. 39. A/B テストを⾏った結果を
 分析すると、仮説が外れることが多い
  40. 40. しかし、新たな仮説のタネを
  41. 41. 複数の視点から得て
 次のアクションに繋げる
  42. 42. KPI 設定と分析をどう実践するか 分析可能な単位での
 最⼩デリバリーを
 繰り返すことで
 不確実性を最⼩化する ⼤がかりな検証を⾏った結果の
 有意差なしでバーンアウトしない
  43. 43. 開発者に対するデザイン 2.0 ストーリーがデリバリーされるまでのタスクの中で、
 継続的な変更に耐え得るデザインの構造化を推進する • デザインの意図が分かるように情報が整理されているか • デザインデータが関⼼別にコンポーネント化されているか • デザインデータと実装の構造が⼀致しているか
  44. 44. デザインの構造 • リリースするデザインは常に変更前提の仮だと考える • 継続的に変更が可能という機能はプロダクトデザインの1要素 • 変更容易性を⾼くするためにデザイン要素を構造化する 継続的にデザインが変更できるということは
 デザインデータが柔軟に取り外し可能な部品によって
 構成されているということ
  45. 45. デザインの構造 ストーリーデザインを構成する部品をデザインする オブジェクト タスク インターフェース ユーザーが扱いたい情報の塊 情報⼀塊に対する⾏動⼿段 コンピューターとの直接的な接点
  46. 46. 1つのストーリーへの変更が複数の部品に影響することがないように
 デザインの関⼼事を分離する (チームメンバー全員が理解しやすいようにリネームも試みる
  Object → Cnt / Task → Act / Interface → Elm etc.)
  47. 47. デザインデータと⼀致した実装構造
  48. 48. デザインデータと⼀致した実装構造 デザインデータ構造が
 実装構造と⼀致していることにより
 デザイン変更コストを考えることが
 実装コストを考えることに近づきます
  49. 49. 更に
 デザイナーがギャンギャン
 Pull Request 出せちゃいます https://developers.cyberagent.co.jp/blog/archives/20327/
  50. 50. ディレクターだって
 ギャンギャンです
  51. 51. プロダクトデザイン 2.0 やることいっぱい チームでデザインを考える
  52. 52. プロダクトデザイン 2.0 やることいっぱい Figma で
 モブデザイニングする
  53. 53. プロダクトデザイン 2.0 やることいっぱい デザインの対象を
 スキルに依存しない
 (グラフィックスキルなど)
 ように分解すれば
 誰もが参加できる
  54. 54. デザイナー デザイナー エンジニア エンジニア デザイン
  55. 55. QA デザイナー デザイナー
  56. 56. ストーリー 構造 視覚情報 従来は全てのデザイン作業が
 視覚情報デザインの中に
 埋もれてしまい、
 デザイナー以外には
 ブラックボックス化していた
  57. 57. ストーリー 構造 視覚情報 プロダクトデザイン 2.0 では
 複数の課題を同時に解決する
 ⾼難易度のデザイン課題を
 分解してチームで解決する
  58. 58. まとめ AbemaTV のプロダクトデザイン 2.0 では • デザインする対象素材と届けるユーザー対象のスコープを拡⼤ • ストーリーというデリバリー単位で
 広くなったデザインスコープの成果物を管理 • 広くなったデザインスコープに対してチーム全員でタックル
  59. 59. 五藤 佑典 YUSUKE GOTO ありがとうございました https://ygoto3.com/ @ygoto3_

×