Upgrade to Pro — share decks privately, control downloads, hide ads and more …

デジタルプロダクトデザイナーしくじりあるある 〜失敗を糧にデザイナーとして2ランクアップ!〜

デジタルプロダクトデザイナーしくじりあるある 〜失敗を糧にデザイナーとして2ランクアップ!〜

Mobility Technologies

September 12, 2022
Tweet

More Decks by Mobility Technologies

Other Decks in Design

Transcript

  1. 2022.9.9 Fri 失敗という金脈「デザインしくじり先生」 @あつまるデザナレ 2022 デジタルプロダ クトデザイナー しくじりあるある 〜失敗を糧にデザイナーとし て2ランクアップ!〜

    株式会社Mobility Technologies 向井 毅男
  2. 自己紹介

  3. 向井 毅男 Takao Mukai https://twitter.com/mt_takao 株式会社Mobility Technologies プロダ クトマネジメント本部デザイン部 プロダ

    クトデザイング ループ グ ループリーダ ー ベンチャー企業に新卒入社し、営業、制作を経験。 デ ィレクションから、プランニング 、実装まで幅広く担当。 Web制作に必要なスキルや経験を一通り身につけた後、株式会社デ ィー・エヌ・エーへ転職。 ゲームの運用、新規開発、Webサービスの立ち上げなどに従事。 事業統合後は、MoTにて、プロダ クトマネージャー兼デザイナーとし て活躍。
  4. 会社紹介

  5. ミッション 移動で人を幸せに。

  6. タクシーアプリ『GO』を中心に さまざまなモビリティサービスを 提供していています。

  7. 今日お話すること

  8. 出典:総務省「令和3年版情報通信白書」(2021年7月) デジタル領域のプロダクトデザイナー 圧倒的人材不足です よね しかも、近年のプロダクトデザイナーに求められる 役割やスキルセットも多岐に渡っていて、 尚更、人材確保・採用難易度高くなりそう。。。

  9. 今日のお題 失敗という金脈「デザインしくじり先生」 既に一組織だけではこの課題解決は難しい なので、成長ドライバーの1つである「失敗」ネタを提供することで デザイナーのみなさまの成長に貢献できたらと思います。 今日はそのために、なるべく具体的な事例と得られた教訓を共有します。

  10. しくじりネタ

  11. しくじりネタ 1 考慮漏れでリリース日延期 2 ユーザー理解不足でリリース後に仕様変更 3 自分の「ものさし」、正しいと勘違い

  12. しくじりネタ 1 考慮漏れでリリース日延期

  13. 2022年7月20日、『GO』の空港定額機能をリリース プレスリリース:https://mo-t.com/news/pr/2022/07/20/6jhw5ktx5wexssrff4orjj

  14. しくじり内容 この空港定額機能、 実は、もうちょっと前にリリース予定でした

  15. しくじり内容 リリース遅延の原因 ‘ 当初のリリース前日、夕方ごろ、QAチームよりリリースブロッカーとなるバグ発見の 報告有s ‘ 複数機能に跨るユースケース(AI予約x空港定額の配車時)で、ユーザー体験的にクリ ティカルなissueと判% ‘ 関係者で対応方針を議論した結果、リリース日を延期し、根本的な対応を進めていく

    ことに ‘ このユースケースの考慮漏れがあったことが判l
  16. しくじり内容 なぜ考慮漏れが起きていたのか??? 開発チーム C 仕様自体は C 開発チームは という認 識でいた 認識していG

    許容できる仕様 ビジネスチーム C 仕様は C 100%仕様を把握はそもそも無u C ビジネスチームは と判i C バグ報告後の話 認識していなかっG 許容できない 開発とビジネスで体験フローの認識差異があったことが原因 あるあるですよね。。。。
  17. このしくじり、どうしたら防げただろうか?

  18. MoTのプロダクトデザイナー動き方はざっくりこんな感X 3 PdMのPRDをベースにフローを可視w 3 PRDの粒度はまちまちだが、比較的粗い段階からデザイナーが入っていくことが多r 3 それを元に開発チーム(PdM、デザイナー、エンジニア)で仕様すり合わ) 3 開発チーム内だけではなく、ビジネスチームとも定期的に仕様のすり合わせやインプットを 行う場を設けて、仕様をFIXさせていく

    デザイナー観点で進め方に問題があったのだろうか???? 大規模案件ゆえ、進め方自体は比較的丁寧な方 だけど漏れた 実際、後ろにあるように画面数・パターン数もなかなかの数
  19. 振り返り デザイナーとしてどう立ち回っていったら良かったのだろう?

  20. ここで少し閑話 MoTのデザイン組織が考えるデザイナーのあるべき姿 デザイン エンジニアリング 品質管理 CX (カスタマーサクセス) プロダクトマネジメント マーケティング

  21. ` デザイナーならではスキル(可視化・ビジュアライズ、言語化)をコアスキルに持) ` 加えて、プラス1〜2つの専門性を持ち、事業・サービスの成長に貢献・ドライブして いÇ ` インハウスデザイナーとしては、プロトタイプ、ファシリテーションあたりがとても肝 になりそう MoTのデザイン組織が考えるデザイナーのあるべき姿

  22. 振り返り デザイナーとしてどう立ち回っていったら良かったのだろう? あらためて

  23. デザイナーとしてどういう動きをしていったら防げたのか?(考えベース) 考慮漏れが起きる確率を可能な限り小さくする h 例え‘ h ビジネスチームを含め、関係者全員を巻き込んだプロトタイピング&承認フローを 構築・仕組み’ h 便利なツールFigmaもあx h

    そもそもFigmaってコラボレーションツーƒ h 情報共有のための可視化・ビジュアライ‰ h デザイナーならではスキルを用いてファシリテーションしていˆ h 開発プロセスのデザイŠ h デザイナーだからできる、やれる、やるべき こんなこと書いてますが、正解かどうかがまだ分かりません
  24. 教訓 デザイナーができること・やるべきことはたくさんある。 デザイナーならではのスキルを利用して、 実際に行動に起こしてみよう!

  25. しくじりネタ 2 ユーザー理解不足でリリース後に仕様変更

  26. ソフトウェア ハードウェア AI ユーザーアプリ 乗務員アプリ 事業者向けサービス 後部座席タブレット BLEロガー I/Oボックス タクシーメーター

    FirmWare AIドライブレコーダー 対面決済端末 診断詳細 走行時間 13h 30m 走行距離 300km 連続運転時間 5h 20m 急減速 95 急加速 93 急ハンドル 53 一時不停止 21 リスク運転行動 動画一覧 5.27(月)のスコア 今日のスコアを見る 設定目標 一時不停止 90/100 達成! 18 22 全 件 3 1 リアクション一覧 スコア推移 動画一覧 スコア詳細 苗字 名前 苗字 名前 東京支店 ログアウト 診断詳細 走行時間 13h 30m 走行距離 300km 連続運転時間 5h 20m 急減速 95 急加速 93 急ハンドル 53 一時不停止 21 リスク運転行動 動画一覧 5.27(月)のスコア 今日のスコアを見る 設定目標 一時不停止 90/100 達成! 18 22 全 件 3 1 リアクション一覧 スコア推移 動画一覧 スコア詳細 苗字 名前 苗字 名前 東京支店 ログアウト GOを構成するプロダクト群 (一部抜粋) 実はめちゃくちゃ多いんです。。。
  27. ソフトウェア ハードウェア AI ユーザーアプリ 乗務員アプリ 事業者向けサービス 後部座席タブレット BLEロガー I/Oボックス タクシーメーター

    FirmWare AIドライブレコーダー 対面決済端末 診断詳細 走行時間 13h 30m 走行距離 300km 連続運転時間 5h 20m 急減速 95 急加速 93 急ハンドル 53 一時不停止 21 リスク運転行動 動画一覧 5.27(月)のスコア 今日のスコアを見る 設定目標 一時不停止 90/100 達成! 18 22 全 件 3 1 リアクション一覧 スコア推移 動画一覧 スコア詳細 苗字 名前 苗字 名前 東京支店 ログアウト 診断詳細 走行時間 13h 30m 走行距離 300km 連続運転時間 5h 20m 急減速 95 急加速 93 急ハンドル 53 一時不停止 21 リスク運転行動 動画一覧 5.27(月)のスコア 今日のスコアを見る 設定目標 一時不停止 90/100 達成! 18 22 全 件 3 1 リアクション一覧 スコア推移 動画一覧 スコア詳細 苗字 名前 苗字 名前 東京支店 ログアウト GOを構成するプロダクト群 (一部抜粋) 実はめちゃくちゃ多いんです。。。
  28. しくじり内容 新プロダクトでのデザイン開発で よかれと思ったことが裏目にでた

  29. しくじり内容 新プロダクトでのデザイン開発でよかれと思ったことが裏目にでた „ 新プロダクト (統合版乗務員アプリ) のおg „ 過去のプロダクトでの知見やリサーチ結果を元に、最適だと思う形でデザイン開発を 進めた

  30. しくじり内容 初期フロー 配車依頼 ローディング 配車承諾後 (迎車)

  31. しくじり内容 p 過去のプロダクトでは、上記の画面(配車成立ダイアログ)を表示していF p 「配車を受けたらすぐにどこに向かったら良いのか知りたい」という乗務員からの要望があっF p また、別のプロダクトでは、そもそもこのダイアログを出しておらず、成り立っていF p ゆえに、新しいプロダクトでは、スムーズに移動モードへシフトできるように、配車成立後に とした。

    ダイアログを表 示しない仕様
  32. しくじり内容 p 過去のプロダクトでは、上記の画面(配車成立ダイアログ)を表示していF p 「配車を受けたらすぐにどこに向かったら良いのか知りたい」という乗務員からの要望があっF p また、別のプロダクトでは、そもそもこのダイアログを出しておらず、成り立っていF p ゆえに、新しいプロダクトでは、スムーズに移動モードへシフトできるように、配車成立後に とした。

    ダイアログを表 示しない仕様 これが失敗だった
  33. リリース後の乗務員さんの反応 • 新プロダクト (統合版乗務員アプリ) が無事にリリースされ、いざ運用フェーズV • 実際に運用開始後、問題が顕在B • 元のプロダクトで表示されていた配車成立ダイアログが表示されなくなったことに より、

    • 業務に支障がでるレベルの問題i • もちろん、エンドユーザーにも影響 配車成立に気づかない乗務員が多く発– しくじった
  34. 問題が顕在化した後の対応 リリース後に仕様変` b 配車成立ダイアログの表示を復A b 読み上げ通知機能も追加し、視覚的だけではなく、聴覚的にも配車成立を認識してもらいや すく改 b ダイアログを自動で消えるようにもした

  35. このしくじり、どうしたら防げただろうか?

  36. デザイナー観点で進め方に問題があったのだろうか???? ‡ 事前にヒアリング等のリサーチstepを踏んでいE ‡ それ自体はむしろ適切な進めy ‡ 別プロダクトでの事例もあっE ‡ ゆえに、ダイアログ非表示パターンのフローが乗務員体験的にも正解であろうという 仮説の元、開発を進めていった

    しかし、このプロセスは結果的に失敗、判断が甘かった
  37. 振り返り デザイナーとしてどう立ち回っていったら良かったのだろう?

  38. デザイナーとしてどういう動きをしていったら防げたのか?(考えベース) ユーザー理解を1段 (場合によっては2段) 深く行う ½ toBプロダクトのユーザー理解はより慎重に深く考えないといけな´ ½ タクシーという事業ドメインにおける乗務員さんのインサイトも特” ½ 乗務員さんの平均年齢50〜60‰

    ½ スマートフォン、タブレットデバイスに慣れていな´ ½ 慣れが非常に重要な要™ ½ 今までのオペレーションを変えることに対するネガ・ハードル有 ½ 学習コストも高めであることも留意する必要有 ½ リサーチのやり方・設計も要アップデー° ½ ターゲットの属性上、仮説ベース+観察での検証がメインにな¬ ½ ゆえに、なるべく本番環境に近い形でリサーチ実d ½ 実施工数とのバランスも考慮する必要有り
  39. 教訓 固定観念は捨て、ユーザーのことを徹底的に理解しよう! そのためのプロセスもよーく考えよう!

  40. しくじりネタ 3 自分の「ものさし」、正しいと勘違い

  41. これはマネジメントロール (デザインマネージャー) あるある? t デザイナーのプレゼンス向上って、社内外問わず大事ですよねi t で、社外発信 (オウンドメディアとかnoteとか)もよくやりますよねi t でも、それって強制的にメンバーにやらせてませんかi

    t 自分も無意識でしたが、ハッと気付かされた事例をちょっとだけ紹介
  42. とある日のメンバーとの1on1内での会話 向井 デザイン組織課題でもあるので、社外プレゼンス向上のため に、記事執筆とかイベント登壇とかやってみませんか? 向井 あー、たしかに。。。 うーん、、、自分、苦手なんですよね。。。 大事なのは分かってはいるんですが。 表に出なくても、裏で支えることも大事で、評価されるべき だと思うんですよね。

    メンバー
  43. とある日の別メンバーとの1on1内での会話 向井 (目標設定の話の流れで) ◯◯◯さんのレベルであれば、もう1つ2つ上のレベルでの 目標を考えてみてはいかがですか? 向井 あー、 うーん、、、 自分にとっては、その目標は難易度高いと思って設定してい るんですよね。

    向井さんにとっては、簡単に見えるかもですが。 メンバー
  44. しくじり内容 自分が正解だろうという価値・基準をメンバーに無意識に押し付けていた ‚ 2つの事例、共に自分の未熟さを痛感した事例でし‡ ‚ メンバーにも申し訳ない気持ちで一杯になりました ‚ 一方で、この経験を活かし、マネジメントロールを担う人材としてアップデートをかけ ていこうと思っていますD ‚

    ちなみに現在進行系です←
  45. 教訓 自分の考え方や価値観は100%だと思わない。 デザイナーらしく、主観と客観を上手に組み合わせて ユーザー(今回はメンバー)にとって、最適な形を模索しよう!

  46. まとめ

  47. しくじりネタと教訓 1 考慮漏れでリリース日延期 2 ユーザー理解不足でリリース後に仕様変更 3 自分の「ものさし」、正しいと勘違い 教訓 デザイナーができること・やるべきことはたくさんある。 デザイナーならではのスキルを利用して、実際に行動に起こしてみよう!

    教訓 固定観念は捨て、ユーザーのことを徹底的に理解しよう! そのためのプロセスもよーく考えよう! 教訓 自分の考え方や価値観は100%だと思わない。 デザイナーらしく、主観と客観を上手に組み合わせてユーザー(今回はメンバー)にとって、 最適な形を模索しよう!
  48. ご清聴ありがとうございました。 今日参加された方のこれからの成長に少しでも役立っていれば幸いです。

  49. 少しだけ宣伝

  50. MoTではデザイナーを絶賛募集中です 一緒に移動体験をアップデートし、人々の生活を豊かにしていきましょう! 採用情報:https://mo-t.com/career/ 会社・仕事にご興味持たれた方も、 カジュアルにお話してみたいという方もお気軽にどうぞ! mobility technologies 採用