効果のあったチームおよびアプリのUX改善施策
Table of Contents
チームのUX改善スキルを底上げしつつ、UX改善をプロセス化した話です。
iOSエンジニア、Webエンジニアとメインはエンジニアとして働いていますが、常日頃から必ず自分の作った先にはユーザーが存在を意識しています。
特に画面を作成するフロントエンドにおいてはその意識の欠如はスキルの欠如と言っても過言ではないです。
しかし、全てのエンジニアが得意・出来るとは限りません。そもそも必要理由が腹落ちしてない、優先度が低い、何から始めればいいか分からないなど、人によって様々です。
今回は自分が実施した施策で、効果を実感できるチームおよびアプリのUX改善について説明します。
UX改善はUI/UXデザイナーだけのものではない
声を大にして言いたいです。
「UI/UXデザイナーの自分が取り組む業務」
「UI/UXデザイナーが考えればいい」
そう考えている人・チームは、チームでもなければ、サービス開発に参加してるエンジニアでもありません。
自分の取り組んでいるサービスの利便性・快適性に気づき改善するのは、業種・業務問わず共通です。
UI/UXデザイナーは専門性や知識、とりまとめが出来るスキルホルダーなだけであって、UI/UXに関する業務を全てその人が担うものでは有りません。
UX改善に必要な観点をチームで身につける
必要だとは分かってはいても、目となるセンサーがなければUX改善の種に気づけません。議論できるだけの知識や観点が備わってなければUX改善の種は育ちません。
まずはチーム内のレベルアップが必要です。
週1か月2の定例でレビュー会を実施しましょう。
レビュー会とは？
レビュー会とは私が会議名に勝手に名付けてる用語です。
次の会議体で実施します。
- 内容
- 参加者が自社と競合他社のサービスを触って、UXに関する良い点悪い点を挙げて議論する
- 触るサービスや画面はファシリテーターがサイコロまたは参加者から募る
- 時間を区切って1会議で複数個の画面をレビューしてもよし、1画面に絞るでもよし
- 参加者全員で画面を見ながら良い点悪い点など気になった点を声に出す
- 理由をデザイン論や視線誘導などのロジックに基づいてると良い
- または自身の体験談も付け加えると良い
- 聞いた人も触ってみてその点に賛否を返す
- 目的
- 入会フローなどCVRにつながる重要なフローのUX向上し、離脱率を下げるために把握と洗い出しのプロセスを定着させる。
- サービス関係者（特にエンジニア）の観点を養い、UX改善プロセスを回転速度を上げる。
- 参加者(PDM, フロントエンドエンジニア, 他希望者)
- 時間30分(仮)
- 人数5~6人程度
- ゴール: 実施する施策をBacklogやGitHub Issueなどチケット管理に出す（ここで優先順位は決めない）
- 事前: アプリであればサービスの事前インストール
レビュー会に必要な準備
円滑に進めるためにいくつか事前に準備が必要です。
- 競合他社のサービスやアプリを列挙する
- 自社サービスやアプリの画面または体験を列挙する
- 他社・自社 × 画面または体験の組み合わせリストを用意する
- サイコロなどランダムで決めれる仕組みを用意する
競合他社のサービスを列挙
ユーザーのシェアを競う競合他社のサービスを列挙します。
UX改善はユーザー自身で判断される絶対値と、他社サービスと比較される相対値があります。
前者は単純に使いにくいと感じたりするもので、後者はそこに「◯◯のほうが楽」と比較が加わります。
競合調査はユーザー知識を知る上でも重要です。
例えばターゲットが楽天利用率が高いのであれば、情報設計（情報の提供順序）や操作性は似せてあれば、それだけユーザーの認知負荷が減ります。
分かりやすい悪い例を挙げるとすれば、AndroidアプリにiOSのUIを適用することです。
つまり、ユーザーの持つ知識や経験は取り巻く環境に依存してるので、そこから乖離(かいり)した知識や経験はユーザーに負担がかかります。
自社サービスの画面や体験を列挙
次に自社サービスの画面名または体験の名称を列挙します。
ここでの体験とは、複数の画面や複数の機能を利用することで得られる体験です。
例えばECであれば会員登録、商品閲覧／検索、カート追加からの購入、シェアなどが挙げれます。
他社・自社と画面または体験を組み合わせてレビューお題を用意
他社のサービス、自社の画面や体験が列挙できたらそれらを組み合わせます。
例えばECであれば、次の競合や画面や体験が列挙できます。
- メルカリの会員登録
- メルカリの商品閲覧／検索
- メルカリのカート追加からの購入
- メルカリのシェア
- ラクマの会員登録
- ラクマの商品閲覧／検索
- ラクマのカート追加からの購入
- ラクマのシェア
- ZOZOTOWNの会員登録
- ZOZOTOWNの商品閲覧／検索
- ZOZOTOWNのカート追加からの購入
- ZOZOTOWNのシェア
- SHOPLISTの会員登録
- SHOPLISTの商品閲覧／検索
- SHOPLISTのカート追加からの購入
- SHOPLISTのシェア
- 楽天市場の会員登録
- 楽天市場の商品閲覧／検索
- 楽天市場のカート追加からの購入
- 楽天市場のシェア
ランダムで決めれる仕組みを用意
お題候補が用意できたら、レビュー会でお題に困ったらこれらからランダムで選べるようにしておきます。
例えばSlack botのレスポンスを使って、一つのレスポンスにお題候補を入れておくと、Slack botがお題を提案してくれるようになります。
レビュー会で何が変わるのか？
レビュー会を実施したことで次の変化が起こりました。
- チームメンバーのUI/UXに関する観点が増加
- 着実にUX改善タスクが実施される
- UI/UX観点を意識した開発体制が備わる
メンバーのUI/UX観点が増加
レビュー会では参加者同士で理由をつけて良い点・悪い点を共有します。
他の参加者は自身では気づかなかった見方を知ることができます。
そのため、互いに観点が増えることでチーム全体のUI/UX観点を底上げできます。
またチームメンバー間の知識差がなくなることで、自信を持って意見交換できるようになり、
よりチーム内のUX改善が活発になります。
着実にUX改善タスクが実施される
定例で実施し、内容にそったレビューが実施されることで、改善ポイントが見つかれば必ずゴールとしてGitHub Issues等に追加され、消化されていきます。
UI/UX観点を意識した開発体制が備わる
不定期にまとめて画面リニューアルや大掃除みたいな長時間を確保せずとも、慢性的に実施されることで普段の別タスクを対応中に気づいたら次回レビュー会で発言するか、レビュー会を待たずにSlackで発言されるようになります。
レビュー会に対する否定意見とその返答
最後にレビュー会に対して実際に受けたネガティブ意見と返答をまとめます。
毎回改善案出てくるものではないのでは？
経験上毎回必ず出ます、また出すことだけが目的ではなく、観点を揃えるためでもあります。
必要になったらまとめて実施してもいい
「必要」とは？その判断基準とは？その判断できる観点を持ち合わせていないから実施します。 また、まとめて実施は思ったより案が出ません。
当人の意識外で勝手にやりきった感を感じて思考が停止、無価値な雑談になりがちです。
発言しない人は一定人数存在する
参加しない人は問題ありますが、発言しないのは問題ありません。
その場で発言せずとも、当人の知識として、PRや画面実装など別の機会で効果を発揮するためです。
組織が改善体質であれば簡単な話
このように今回説明した施策は、内容としてはとても簡単なものです。
しかしながら、UXというスキルも効果もデフォルトが定性的なものは、組織の体質によっては門前払いされます。
上手くいくケースとは、改善を諦めない体質を持った組織、そして社長のマインドまたは企業理念です。
なお、このUXを定性評価から定量評価に変換を実施したこともあり、CX/UX/UIデザインの価値を定量化するために私がした施策 にまとめてあります。
