会社情報
採用情報
お問い合わせ
Article

UI/UX改善の実例：ユーザーテストから見えた課題と解決

高田晃太郎
UI/UX改善の実例：ユーザーテストから見えた課題と解決

5人前後のユーザーテストで主要な使い勝手の問題の大半が露呈するという有名な経験則がある一方で、発見した事実を“仕様変更と実装”へ確実に落とす運用がないとビジネスインパクトは生まれにくい。[1] 業界調査やケーススタディでは、チェックアウトのユーザビリティ改善がCVR（コンバージョン率）の上昇につながる事例が複数報告されているが、[2][4] 計測設計が粗いと効果の推定が歪み、投資対効果を誤る。私は、テストで見えた定性的な洞察を、イベント設計と実験計画で定量に接続し、最短の実装で検証することを基本方針にしている。本稿では、B2BオンボーディングとECチェックアウトの実例を挙げながら、設計・実装・計測を一気通貫で解説する。なお、数値の効果はプロダクトや文脈に依存するため、ここでは一般的な検証手順と考え方に焦点を当てる。

ユーザーテストは「発見」だけでなく「決断」の装置

ユーザーテストの価値は、問題の列挙よりも、どの問題をいつ直すかという優先順位を決められるところにある。観察で得たメモを感想に終わらせず、行動データに変換して意思決定の材料にするには、タスク成功率（所定の操作を完了できた割合）やタスク所要時間（目標達成までの時間）、エラー率（障害発生の頻度）といった指標をテスト時点で計測可能な形に定義し、プロダクト上のイベントにマッピングしておく必要がある。例えばオンボーディングの“最初の価値体験”に至る遷移では、完了イベント、エラーイベント、ヘルプ閲覧イベントを粒度を揃えて設計する。以下のようなイベントスキーマをTypeScriptで宣言しておくと、計測抜けを最小化できる。

// analytics/events.ts
export type EventName =
  | 'onboarding_started'
  | 'onboarding_step_completed'
  | 'onboarding_error'
  | 'value_moment_reached';

export type Event<N extends EventName, P> = { name: N; props: P; ts: number; userId?: string };

export type OnboardingStepCompleted = Event<'onboarding_step_completed', {
  step: 'profile' | 'invite' | 'import';
  durationMs: number;
  assisted: boolean; // tooltip/help used
}>;

export function track<N extends EventName, P>(e: Event<N, P>) {
  window.fetch('/analytics', { method: 'POST', body: JSON.stringify(e) });
}

ユーザーテスト中は、観察者が紙に取るノートと同じラベルを上記のイベント名に揃える。すると、ラボの洞察と本番のデータ基盤が同じ言語で接続され、どの改善がどの指標をどれだけ動かしたかが比較可能になる。ここまで用意して初めて、テストの発見はプロダクトの決断に変わる。

ケーススタディ1：B2B SaaSオンボーディングの詰まりを外す

あるB2B SaaSで、試用開始から“最初の価値体験”に到達するまでの完了率が低下し、営業のSQL（Sales Qualified Lead：営業が有望と判断したリード）化までのリードタイムが延びていた。定量では、初回セッションの離脱点がプロフィール設定とメンバー招待に集中し、タスク成功率が約6割に留まっていることが分かった。そこで、5名のターゲットユーザーでシンクアロング式のユーザーテストを実施し、入力途中での認知負荷とエラー復帰の導線が細いことを特定した。特にメール招待の一括貼り付け時にバリデーションが遅延し、修正のフィードバックが画面下部のトーストのみで見逃される問題が支配的だった。

解決方針はシンプルに、リアルタイムのフィールド内バリデーション、進捗の可視化、そして“まずは一人で始める”のデフォルトを提示する設計に切り替えることだった。Reactとzod、react-hook-formでエラー表示を即時化し、支援のサイドパネルにショート動画を埋め込んだ。

// OnboardingInvite.tsx（簡略化した例）
import React from 'react';
import { useForm } from 'react-hook-form';
import { z } from 'zod';
import { zodResolver } from '@hookform/resolvers/zod';

const schema = z.object({ emails: z.string().nonempty() });

type Form = z.infer<typeof schema>;

export default function OnboardingInvite() {
  const { register, handleSubmit, formState, setValue, watch } = useForm<Form>({
    resolver: zodResolver(schema),
    mode: 'onChange'
  });

  const emails = watch('emails') || '';
  const emailList = emails.split(/[\,\s]+/).filter(Boolean);
  const invalid = emailList.filter(e => !/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(e));

  return (
    <form onSubmit={handleSubmit(() => {/* submit */})}>
      <label>Invite teammates (optional)</label>
      <textarea {...register('emails')} placeholder="alice@ex.com, bob@ex.com" />
      {invalid.length > 0 && (
        <div role="alert" aria-live="polite">
          {invalid.length} invalid email{invalid.length > 1 ? 's' : ''} detected. Click to auto-fix.
        </div>
      )}
      <button type="button" onClick={() => setValue('emails', emailList.filter(e => /^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(e)).join(', '))}>
        Auto-fix
      </button>
      <div aria-label="progress">Step 2 / 3</div>
      <button type="submit">Continue</button>
    </form>
  );
}

同時に、招待ステップはスキップ可能にして“まずは一人で始める”を主要ボタンに格上げし、A/Bテストで影響を測った。乱数ベースの軽量な割当てをクライアントで行い、イベントにバケット情報を付与して集計できるようにした。

// experiment/bucket.ts（概念実装）
export function bucket(userId: string, key: string) {
  const h = crypto.subtle ? undefined : undefined; // placeholder for server-side
  // simple deterministic bucket using FNV-like hash
  let hash = 2166136261;
  const s = `${key}:${userId}`;
  for (let i = 0; i < s.length; i++) hash = (hash ^ s.charCodeAt(i)) * 16777619;
  return Math.abs(hash) % 100; // 0-99
}

export function variant(userId: string) {
  const b = bucket(userId, 'invite_step_default');
  return b < 50 ? 'control' : 'treatment';
}

このような変更は、ファネルの詰まりの主因を緩和しやすく、タスク成功率や離脱率、価値体験到達までの所要時間などに有意な差が生じる可能性がある。重要なのは、検出力のある実験設計を前提に、どの指標で差を判定するかを事前に合意しておくことだ。短いサイクルで実装・検証を反復できれば、営業パイプライン（有料化率やSQL化までのリードタイム）にも波及効果が見込める。

ケーススタディ2：ECチェックアウトの摩擦を減らす

別の案件では、ECのチェックアウトで配送先入力に時間がかかり、カート放棄が高止まりしていた。一般的な調査でも、平均的なECサイトのチェックアウトには多くのUX課題が残存し、カート放棄率はおよそ70%に達するとの推計がある。[2][3] また、ページ表示の遅延が売上に与える影響は過去の業界報告でも指摘されている。[5] ユーザーテストでは、郵便番号からの住所補完が遅く、フィールドのフォーカス移動も不自然で、モバイルではキーボードタイプが適切に切り替わらないことが判明した。そこで、住所の自動補完とフォーカス制御、ゲスト購入の提示位置の見直しを同時に行い、Core Web VitalsであるLCP（Largest Contentful Paint：最大視認要素の表示時間）とCLS（Cumulative Layout Shift：累積レイアウトシフト）などのパフォーマンス指標も監視した。住所補完はGoogle Placesを使い、入力確定時にフィールドを分割して自動入力する。

<input id="address" type="text" placeholder="住所を入力" autocomplete="street-address" />
<script src="https://maps.googleapis.com/maps/api/js?key=API_KEY&libraries=places" async defer></script>
<script>
  function init() {
    const input = document.getElementById('address');
    const ac = new google.maps.places.Autocomplete(input, { types: ['address'] });
    ac.addListener('place_changed', () => {
      const place = ac.getPlace();
      const comps = place.address_components || [];
      const get = t => (comps.find(c => c.types.includes(t)) || {}).long_name || '';
      document.getElementById('postal').value = get('postal_code');
      document.getElementById('city').value = get('locality') || get('sublocality') || '';
      document.getElementById('line1').value = get('route') + ' ' + get('street_number');
      document.getElementById('line2').focus();
    });
  }
  window.addEventListener('load', init);
</script>

あわせて、Core Web VitalsのLCPとCLSをテスト中も本番も同じ定義で収集し（p75＝75パーセンタイルで評価すると傾向が見やすい）、UI変更の副作用を検知した。web-vitalsパッケージを用い、計測値をイベントに束ねて送信すると、実験とパフォーマンスの相関が追える。[5]

// web-vitals-client.js
import { onLCP, onCLS, onFID } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name,
    id: metric.id,
    value: metric.value,
    delta: metric.delta,
    url: location.pathname
  }));
}

onLCP(send);
onCLS(send);
onFID(send);

これらの変更は、入力に伴う迷いと待ち時間を同時に削ることで、チェックアウトの完了率や入力完了率の改善につながる可能性がある。パフォーマンス面でも、LCPやCLSを監視しながら改善を行えば、視覚的な完成の速さと安定性を損なわずに体験を底上げできる。重要なのは、UI変更と計測を一体で進め、CVRやセッション当たり売上などのKPIとCore Web Vitalsを同じダッシュボードで観測できる状態をつくることだ。

学びを仕組みにする：計測設計、実験、アクセシビリティ

ユーザーテストからの学びを単発で終わらせないために、私は三つの仕組みを重視している。第一に、イベント設計の整備である。テストの観察項目をイベント名に昇華し、ダッシュボードではタスク成功率をファネルとして常時可視化する。BigQueryのような基盤を使うなら、オンボーディングの各ステップの通過率を次のように集計しておくと、日次で劣化を検知できる。

-- onboarding funnel by day
WITH events AS (
  SELECT user_id, name, event_time, DATE(event_time) AS d
  FROM `app.events`
  WHERE name IN ('onboarding_started','onboarding_step_completed','value_moment_reached')
), started AS (
  SELECT user_id, MIN(d) d FROM events WHERE name='onboarding_started' GROUP BY user_id
), steps AS (
  SELECT user_id, d, COUNTIF(name='onboarding_step_completed') AS step_cnt,
         COUNTIF(name='value_moment_reached') AS value_cnt
  FROM events GROUP BY user_id, d
)
SELECT s.d, COUNT(*) AS starters,
       SUM(step_cnt >= 1) AS step1,
       SUM(step_cnt >= 2) AS step2,
       SUM(value_cnt >= 1) AS value_reached
FROM started s JOIN steps t USING(user_id, d)
GROUP BY s.d ORDER BY s.d DESC;

第二に、実験の計画性である。効果量の見込みと必要サンプルサイズを事前に見積もり、最短期間で意思決定に足る検出力を確保する。サーバーサイド配分を行うなら、バケットはユーザーIDで固定し、イベントに必ずバリアントを付帯させる。AmplitudeやLookerのビューで、テスト群間の差を日次で監視する運用も重要だ。第三に、アクセシビリティを“品質の一部”として先回りで担保することだ。テストは代表性の観点で偏りを持ちやすいが、WAI-ARIAの最低限を守るだけで“迷子”になるユーザーは確実に減る。フォーカスの明示とロール、ライブリージョンの活用は、健常者の操作効率にも寄与する。

<button aria-expanded="false" aria-controls="help-panel" id="help-toggle">ヘルプ</button>
<aside id="help-panel" role="region" aria-labelledby="help-toggle" hidden>
  <h2 id="help-title">よくあるつまずき</h2>
  <p id="tip" role="status" aria-live="polite"></p>
</aside>
<script>
  const t = document.getElementById('help-toggle');
  const p = document.getElementById('help-panel');
  t.addEventListener('click', () => {
    const open = p.hasAttribute('hidden');
    if (open) {
      p.removeAttribute('hidden');
      t.setAttribute('aria-expanded', 'true');
      p.querySelector('#tip').textContent = 'メールは後からでも招待できます';
      p.focus();
    } else {
      p.setAttribute('hidden', '');
      t.setAttribute('aria-expanded', 'false');
      t.focus();
    }
  });
</script>

この三つは、それぞれが独立して効くというより、連結して効果を最大化する。イベント設計があれば実験の解像度が上がり、アクセシビリティの原則が先に守られていれば、ユーザーテストで見つかる“ケアレスミス”は減る。プロセスとしては、テストの設計段階で計測のラベルを固め、実装前にアクセシビリティの受け入れ基準をテストケースに落とし、リリース後に実験とパフォーマンスのダッシュボードで振り返る循環を仕込むことが肝要だ。設計組織と開発組織が別でも、同じ指標を見る仕組みを共有すれば、意思決定の速度は上がる。

より詳細な設計手法については、デザインシステム移行の実務と意思決定をまとめた記事を参照されたい。コンポーネントの再利用とアクセシビリティの標準化が、ユーザーテストの修正コストを下げることを解説している。関連して、イベント設計とデータ基盤の整備については、計測戦略の記事でスキーマ定義とサンプリングの考え方を扱っている。実験文化の定着については、私のA/Bテスト運用論が参考になるはずだ。パフォーマンス最適化とCore Web Vitalsに関心がある読者には、LCP最適化の実装例を集めた技術解説も用意している。

まとめ：小さく検証し、大きく変える

ユーザーテストは、観察メモを共有して終わりではない。問題の核心を言語化し、それをイベントと実験に接続し、最短で実装して検証する一連の流れを回すと、タスク成功率やCVR、LCPといった指標は“測れる形で”動き始める。重要なのは、テストの発見を“決断の材料”に変える計測設計と、実験の検出力を確保する運用だ。次のスプリントでは、一つのタスクにイベント名を与え、仮説とMDE（Minimum Detectable Effect：最小検出効果）を書き出すところから始めてほしい。その小さな一歩が、製品の摩擦を削り、事業の速度を上げる大きな変化につながる。あなたのプロダクトで最初に小さく検証できる場所は、どこだろうか。

参考文献

  1. U-Site（NN/g日本語版）: 5人テストと反復のすすめ（2000年） https://u-site.jp/alertbox/20000319#:~:text=%E3%82%A4%E3%83%B3%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%92%E3%81%99%E3%82%8B%E4%BA%88%E7%AE%97%E3%81%8C%E3%81%82%E3%82%8B%E3%81%A8%E3%81%97%E3%82%88%E3%81%86%E3%80%82%E3%82%88%E3%82%8D%E3%81%97%E3%81%84%E3%80%82%E3%81%93%E3%81%AE%E4%BA%88%E7%AE%97%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%80%815%E4%BA%BA%E3%81%9A%E3%81%A4%E3%80%81%E8%A8%883%E5%9B%9E%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%92%E8%A1%8C%E3%81%8A%E3%81%86%EF%BC%81
  2. Baymard Institute: Checkout Usability — 平均サイトの課題数について https://baymard.com/research/checkout-usability#:~:text=The%20average%20site%20has%2032,nuances%20and%20diversities%20behind%20the
  3. Baymard Institute: Cart Abandonment — 放棄率の推計 https://baymard.com/research/checkout-usability#:~:text=70%25%20of%20all%20e,Why
  4. Smashing Magazine: Sunuva Case Study — UX changes result in increase in conversion (2022) https://www.smashingmagazine.com/2022/05/sunuva-case-study-ux-changes-result-increase-conversion/#:~:text=our%20customer%20has%20reported%20an,after%20nearly%20implementing%20every%20recommendation
  5. Conductor: Amazon page speed study（2006年の事例紹介） https://www.conductor.com/academy/page-speed-resources/faq/amazon-page-speed-study/#:~:text=Back%20in%202006%2C%20Amazon%20found,a%20fast%20site%20is%20important