ユーザーフィードバックを 製品改善に生かす "フリクションログ"入門

533 Views

September 14, 24

スライド概要

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

DevRel/Japan CONFERENCE 2024 ユーザーフィードバックを 製品改善に生かす "フリクションログ "入門 岡本 秀高 ( @hidetaka_dev ) 2024/08

2.

”摩擦”(引っかかり)のログ Friction Log

3.

フリクション ログ ( Friction log ) とは、 ツールを使いにくくする小さな問題を すべてリストアップしたドキュメントです https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

4.

開発者体験における ”摩擦”

5.

https://wordpress.org/plugins/ejls-easy-json-ld-setter/

6.

https://wordpress.org/plugins/ejls-easy-json-ld-setter/ UIや説明が日本語じゃない 最新版どころか、3世代前の WordPressでもテストされていない スクリーンショットがないので 入れてみないとわからない

7.

https://wordpress.org/plugins/ejls-easy-json-ld-setter/ UIや説明が日本語じゃない ちょっとこのWordPressプラグインを 最新版どころか、3世代前の プロジェクトに導入するのは怖いなぁ・・・ WordPressでもテストされていない スクリーンショットがないので 入れてみないとわからない

8.

摩擦は開発者の「速度」に影響を与える ● ● 使いやすさは、開発速度に貢献する ○ 利用開始 / Hello Worldまでの速度 ○ システムへの組み込みを完了するまでの速度 「摩擦」によって開発速度が減速する ○ 使い方がわからなかった ○ 自分の使いたい言語でSDKが存在しない ○ etc.. ● 8

9.

開発における摩擦の例 ● ● 導入時の摩擦 ○ ドキュメントが日本語化されてない / 古い ○ サンプルコードがエラーで動かない ○ なにから始めたらいいかわからない 開発時の摩擦 ○ 似た機能があるけど、どっちを使うべき? ○ 発生したエラーの原因と対処法がわからない ○ SDKやサンプルがモダンじゃない 9

10.

摩擦は累積する ● ● 「XXは開発者体験が良い / 悪い」は摩擦の積み重ね ○ 「AのAPI組み込みが大変だった」 ○ 「Bのエラーが出た時に、調査で手こずった」 ○ 「Cの要件に使えるかどうかが、なかなかわからない」 ○ 「このサービス、なんか使いにくいなぁ」 主観・体験ベースの評価故に、計測や可視化が難しい ○ 場合によっては、誤解による摩擦も発生する 10

11.

計測が難しい摩擦を どうやって発見・可視化するか?

12.

岡本 秀高 Stripe Developer Advocate ● Stripeが好きすぎて中の人になった人 ○ JP_Stripes京都の元運営 ○ JP_Stripes Connect 2019の実行委員長 ○ Stripe Apps一人アドベントカレンダー完走 ● 元Stripeユーザー企業勤務 & 個人的にもStripe利用中 ○ SaaSのサブスク請求 / 価格改定 / 増税対応など ○ 個人ブログにStripe導入トライ中 https://hidetaka.dev/ja-JP https://wp-kyoto.net Qiitaで年50+ペースの記事更新中 https://qiita.com/organizations/stripe

13.

摩擦の可視化における課題 ● 摩擦のほとんどは「主観」 ○ ● 使いにくかった・わかりにくかった ユーザーのスキルや背景によって、見え方も異なる ○ 例: スタートアップと JTC / フロントエンドとバックエンド ○ 前提知識や解決したい課題によって、 使いたい機能も迷うポイントも変わってくる →「異なる背景を持つ人による主観」をどのように可視化・共有するか? 13

15.

フリクションログ = 摩擦の記録 特定のシナリオを設定し、 ユーザーとして製品を体験する。 その中で発生した「摩擦」を記録する。 https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

16.

フリクションログの構成要素 1. どんな人が 2. どんな目的で製品を使用し 3. どこで摩擦を起こして、どんな感情を抱いたか https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

17.

フリクションログの構成要素 1. ユーザーのペルソナ : どんな人が 2. シナリオとその背景 : どんな目的で製品を使用し 3. 摩擦のログ : どこで摩擦を起こして、どんな感情を抱いた + ログを元にした考察や製品へのフィードバック https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

18.

ユーザーのペルソナとシナリオを明確にする ● 「読んだ人が共感できるログ」を作る必要がある ○ 「なるほど。確かにここを改善すると、 メインとなるユーザーがより製品を使いやすくなりそうだ」 ● どんな人が、どんなタスクを遂行するために製品を使うのか? ○ PHP開発者?それともノーコードツールで効率化をする人? ○ そもそもその使い方は、製品チームの想定外ではないか? https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

19.

例: ユーザー : 20名規模のスタートアップで勤務する開発者。新しい技術にも興味があ り、触ったものについてブログや登壇で頻繁にシェアする。 シナリオ・背景 : 従量課金のオプションプランを追加するプロジェクトに参加している。 Stripeを使った請求システムの実装担当になったため、その実装を進め る方法などを調べはじめている。 従量課金での請求についてはAWSを使った経験からイメージはあるも のの、どのように集計するかや請求時にやるべきことなどについては詳 しくない。金銭が絡む要件のため、できるだけ考慮漏れによるトラブルが 起きないように慎重に準備を進めたいと考えている。 https://wp-kyoto.net/cancel-stripe-billing/

20.

Liveデモ

22.

製品機能に不慣れな人ほど、フリクションログを作ろう ● 「使い方」を知っているからこその見落としがある ○ ドキュメントに使い方書いてあるよ → 実はno indexされていて、 Google検索で出てこない ○ 新機能の組み込み方法を重点的に調べました! → そもそも「その機能が出たこと」に気づける場所がない ● 新入社員や新規メンバーが加入した時は最大のチャンス! 「その人の目から見て、この製品や機能はどう見えますか?」 https://developerrelations.com/developer-experience/an-introduction-to-friction-logging

23.

DevRelにおける「顧客理解」 ● DevRelは、現場の開発者との接点と機会が他の社員より多い ● よりダイレクトなフィードバックに触れることができる ● ○ 「この機能が要件に合わなかったので、見送りました」 ○ 「ドキュメントには載ってないですが、こんな作り方できます」 ○ 「この機能があることで、この間めちゃくちゃ助かりました!」 フリクションログで追体験することで、 ユーザーの困り事を自分ごとにする

24.

フリクションログの活用法の例 ● Dev Marketing: ○ ● Product Feedback: ○ ● 追体験による気づきから、課題ベースのコンテンツを企画する ログを元にした機能や GTM戦略への提案を行う Customer Success: ○ 社内のSA / Devチームに共有し、 摩擦の解決策やワークアラウンドがあれば顧客に共有する

25.

主観的な体験を 共感できる形で可視化するのがフリクションログ ● どんな人が、何をしようとした時に引っかりが起きるのか? ○ ● 言葉・画像・動画を使って、摩擦の可視化を実施する ○ ● その引っかかり(摩擦)によって、製品にどんな印象を持つか? Q: このユーザー体験において、どんな改善機会が存在するか? ユーザー目線で追体験することで、 顧客の悩みや製品の機能についての理解も深めることができる

26.

まずは自社 / 製品について検索してみよう ● ● ● ユーザーは自社ドメインの外からやってくる ○ どんなワードで検索しますか?どんな記事をまず読みますか? ○ 誰に相談しますか?誰にお勧めされましたか? 自分の足で行って、自分の目でみてくる ○ 理想を言えば、自社製品を使って何か個人的に作ってみる ○ 難しい場合は、とにかくユーザーの話を聴いて理解する

27.

最後に、めっちゃ内側の話 ● ● Friction logは計測が簡単 ○ 何本書いたか ○ どれだけフィードバックを出したか ○ そこからどれだけリリースが出たか だからこそ、数字に振り回されないように注意しよう ○ 「自転車置き場の議論」ばかりになっていないか? ○ ログを作成した経験は、他の業務に活かせているか?

28.

Next step: -> Template https://github.com/mikeb-stripe/friction-l ogging-toolkit ● ● @hidetaka_dev https://hidetaka.dev ● https://qiita.com/organizations/stripe ● https://wp-kyoto.net