エンジニアによるサービスのUI/UX改善基礎
いつもご利用ありがとうございます。このブログは、広告費によって運営されています。
目次
UI/UX の改善について自分の実体験を元に書いていきます。
はじめに
まず今回の前提としては、
- 動的なコンテンツを掲載する、プロダクトであること
- 非常に少人数であること
デザイナーが内側に居ないような、小さな規模感のチームで考えていただければと思います。
改善とは？
改善とは、悪いところを改めてよくすること
https://dictionary.goo.ne.jp/word/%E6%94%B9%E5%96%84/
とあります。
つまり、悪いところを定義する、または仮説を立てる必要性があります。
具体的に何を改善するのかを決める
事業には KPI や KGI が設定されているので、それに直結するような項目を改善するような目標にします。
例えば、「商品ページへの流入を増やしたい」とすれば、「商品ページの流入」の数字を改善することをしっかりと決める必要があります。
課題（改善の目標）を設定するためのツール
前述の、目標を決める方法について書いていきます。
すでにプロダクトは動いているので、現在どうなっているのかについて、まずは知る必要があります。
現在どうなっているのかも分からないのに、「改善」なんてできるわけがありません。
グーグルアナリティクスを使う
Google 社が提供するアナリティクスというツールは、とても優秀です。
ざっくりデータを眺めていても課題を発見できるかもしれません。
Microsoft の Clarity を使う
現在、自分は主にヒートマップツールとして使用しています。
ヒートマップツールで、どこまでスクロールされたかや、どこがクリックされやすいのか、というのを見ることができます。
Google Search Console
Google サーチコンソールは、主に検索流入を計測するためのツールではありますが、さまざまな改善点の情報をくれます。
例えば、サイトの表示速度などです。
GoogleChrome の拡張機能で Lighthouse を使っても同じようなことはできるのですが、現在リリースしているページを総合的に評価して、「改善した方が良い」と診断してくれるのはとても役に立ちます。
マクロ分析とミクロ分析
- マクロ分析は、ざっくりと見ること
- ミクロ分析は、詳細まで見ること
を指します。
では、サービスの改善においてどのようにこれらを使っていくかというと
マクロ分析でざっくりとした課題を洗い出す
例えば、アナリティクスで「サイト全体のステータス」を眺めてみます。
そうすると、「９０％が直帰していた」ということが判明しました。
これは、改善するテーマとして良さそうですね。
「サイト全体の直帰率を下げよう」というテーマになります。
さらにマクロ分析で、どこのページが足を引っ張っているかを特定する
全体が９０％だとしたら、３０％のところがあれば９９％のところもあるはずです。
ページによって数値は違うので、もう少し詳細に分析してみていきます。
そうしたら、トップページでは５０％の直帰率で、商品ページが９９％の直帰率であることが判明しました。
これで、「商品ページの直帰率を下げよう」という深ぼったテーマが誕生します。
ミクロ分析で、商品ページが今どんな状況なのかを把握する
まずは商品ページが今どんな状況なのかを、より詳細に調べていく必要があります。
これをしないとそのページの何をどう改善するか特定できないからです。
それを特定しなければ「改善」ではなく「変更」です。
ミクロに見ていけば結構改善のテーマというのは見えてくるものです。
例えば、ヒートマップツールで確認したら９９％がファーストビューの段階で離脱していたことが判明したとします。
そしたら「ファーストビューの内容を見直す」というテーマが見えてきます。
これらの調査により、
- どこの何を改善するのか
- なぜ改善するのか
を決定することができました。
すでに動いているプロダクトは CAPD サイクルになる
サービス改善のこの記事の冒頭では、「改善」のための下準備として「分析」の話をしてみました。
なぜ分析からはじめたのかというと、
- プロダクトは PDCA サイクルを回す
というのが基本だからです。
PDCA とは？
- P: Plan：計画を立てる
- D: Do：実行する
- C: Check：測定・評価する
- A: Action：対策・改善する
プロダクトはこれを何回も回してより良くしていきます。
では、すでに動いているプロダクトはどうでしょうか？
P と D が既に終わっている状態です。
なので、既に動いているプロダクトでやることは、
CDPA となるわけです。
絶対に一番最初にやることは C です。
データや顧客の意見を見ずに改善はあり得ません。
UI/UX を改善していく
これまでの分析で、
「商品ページのファーストビュー」が問題であることが定義できました。
それでは実際にユーザー目線にたって商品ページを開いてみましょう。
「・・・ページの表示が遅い」
プロダクトの序盤ほど、こういった単純な改善が待っています。
この事例ではページ表示速度の改善を行って、対策をしましょう。
ではもっと深い改善、単純には測れなさそうな改善をする上で必要なことについて話していきます。
まずは理論を詰める
「UI/UX」というとデザインセンスがある人の仕事かと思ってしまいますが実は違います。
めっちゃ努力した人が得られるスキルだということです。
デザインセンスがある人というのは、「０からデザインが作れる人」であって、ユーザーとの接点（インターフェース）の部分や、ユーザーがどんな経験（エクスペリエンス）をしてきたかという知識の部分で欠けているパターンがあります。
UI/UX は「変更」したら良くなった気がしちゃう
変更すればなんとなく良くなった気になってもらえるので、特段知識をつけなくても良さげなデザインを納品するだけで良いです。
リテラシーの低い人を相手には、「今はこういうのが流行っている」といってふわっと提案すれば通ります。
とりあえずこの本を読むのがオススメ
とりあえず競合（自分より強い）は全て触る
- エンジニアは、他社のプロダクトを触るだけでも他職種とは得られる情報量が違います。
「なぜアマプラが背景が白から黒になったのか」とか、「メルカリはなぜ商品登録が楽なのか」とか、エンジニア目線で色々な仮説を立てたり、プロダクト努力みたいな推測ができます。
なので、とりあえず他社サービスで似たようなものは全て触るということをまず最初にやりましょう。
これが全て知識となって、今にも、未来にも役に立ちます。
- ヤコブの法則
ヤコブの法則は、
- 「ユーザーは他のサイトと同じ挙動を期待している」
という法則です。
先程の本の最初に出てくる法則です。
基本的に他社の有名サイトに挙動を合わせながら、自社独自の部分をプラスして表現します。
その独自の部分を実装しやすい挙動が表現しづらい場合別のサイトを参考にしたりします。
競合や誰もが使っているサービスの挙動が頭に入っている人というのは、それだけで UI/UX の改善が可能です。
この法則が UI/UX においては、一番大事だと僕は考えています。
失敗する事例
アナリティクスなどのデータを見ずに、
「○○ だと思う」
と言って、永遠に見た目を変更し続けるようなパターンは絶対に失敗します。
あなたの業務を無駄に圧迫し続けるでしょう。
改善（A）の前には測定（C)を必ずしましょう。
本を読んだり、有名企業の開発チームの記事を日頃から読んでいる人なら当然のことですね。
まとめ
以上です。
少数で肩身が狭い思いをしているエンジニアの皆さんが、
合理的に考えて意味があることだけをするために、
自信を持ってこの記事を根拠に「やる」「やらない」を決めれたら嬉しいと思ってます。
無駄な UI 変更は絶対にやるべきではない。
感想・苦情は TwitterDM にご連絡ください。
それでは！
人気記事
