通販サイト/システムのリニューアルのPoC・プロトタイプ・モックアップ開発について

通販サイト/システムのリニューアルでは、画面の設計から公開後の改善まで段階を追って検証を進め、定期便や申込番号など通販特有の画面を確かめていきます。

一般的なECリニューアルと異なり、定期購入・カタログ通販・テレビ通販に絞って解説します。全体像は次の記事にあります。

▼全体ガイドの記事
・通販サイト/システムのリニューアルの完全ガイド

  • PoC・プロトタイプ開発の位置づけと、他の検証との違い
  • ワイヤーフレームからデザインモックまでの購入導線検証
  • プロトタイピングツールとスマホ実機によるUX検証

通販サイト/システムのリニューアルにおけるPoC・プロトタイプ開発の位置づけ

同じ「通販サイト・通販システムを検証する」というテーマでも、何を確かめたいかによって、組むべき検証プロセスは大きく変わります。そのため、PoC・プロトタイプ開発の進め方を検討する前に、本記事の論点がどこに位置づくかを押さえておく必要があります。

モダナイゼーション・刷新・更改・ECリニューアル(総論)との違い

「通販サイト/システムのモダナイゼーション」のPoCは、既存システムをリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースのどれで刷新するかを、技術面から確かめる検証です。「刷新」のPoCは、会員基盤や受注実績といった資産を前提にした投資対効果の仮説を、経営層への説明材料として実証する検証です。

「通販サイト/システム更改」のPoCは、移行先候補のSaaSやパッケージが自社の会員データや注文履歴で問題なく動くかを確かめる、ベンダー選定の一環としての実地検証です。一方、「ECリニューアル」は、業態を問わない一般的なECサイトを主語に、標準的な検証プロセスを総論として解説するものです。その中身は、ワイヤーフレームからA/Bテストまでです。

これに対し、通販サイト/システムのリニューアルのPoC・プロトタイプ開発は、この標準的な検証プロセスを基にしつつ、定期購入・カタログ通販・テレビ通販という業態特有の画面や導線を検証対象に据えます。その点が最大の違いです。

通販特有の検証ポイント(定期便・申込番号・同梱連動)

ECサイトでは「デザインがかっこいいこと」と「商品が購入しやすいこと」は必ずしも一致しません。通販サイトでは、この原則の重要度がさらに増します。

たとえば、定期便のスキップ・周期変更・解約をマイページ上で迷わず完結できるか、申込番号によるクイックオーダーが高齢層を含む顧客層に直感的か、といった点は通販サイト固有の論点です。同梱物のQRコードから遷移した先の画面も、ログインやクロスセル提案にスムーズにつながるかを確かめる対象になります。

本格的な開発に入る前に、これらの画面や導線をワイヤーフレームやプロトタイプの段階で検証しておくと、手戻り(修正コスト)を抑え、売上(コンバージョン)につながるリニューアルに近づけます。デザインが完成してから使いにくさが分かると、公開後の作り直しやコールセンターへの問い合わせ急増を招きかねません。

ポイント

PoCやプロトタイプで何を確かめるかは、技術の適合、投資対効果、移行先の実地検証のどれが目的かで決まります。そのうえで、定期便や申込番号といった通販特有の画面を検証対象に入れるかを判断します。

ワイヤーフレーム〜デザインモックによる購入導線検証

単品購入、定期購入、申込番号、マイページと定期便管理画面を並べた検証対象の図。
購入前から会員向け画面まで、確認する範囲を見渡せます。

UX改善の第一歩は、ユーザーが「商品を探す」「カートに入れる」「決済する」という目的を果たすまでの手順を、ワイヤーフレームで図にすることです。そこで、画面のビジュアルを作り込む前に、無駄なステップや迷いやすい箇所を洗い出し、改善案を試しておくと、後の開発フェーズでの大幅な手戻りやコスト増を防げます。

探す・カートに入れる・決済するという導線の可視化

通販サイトの購入導線は、単品購入と定期購入で大きく分かれる点が、一般的なECサイトとの違いです。単品購入者にはシンプルな決済導線を用意し、一方で定期購入を検討する顧客には、「初回価格」「2回目以降の価格」「お届けサイクル」を購入前に迷わず理解できる導線が必要です。

この分岐を、ワイヤーフレームの段階で検証しておけば、開発に入ってから「定期購入の説明が分かりにくい」と指摘され、大幅な作り直しになる事態を避けられます。さらに、カタログ・テレビ通販特有の申込番号によるクイックオーダー導線も、通常の商品検索導線とは別に明確に位置づけておくことが大切です。

通販特有画面(マイページ・定期便管理)のワイヤーフレーム設計

マイページと定期便管理画面は、通販サイトのリニューアルで最も作り込みの検証が必要な画面です。次回お届け予定日や保有ポイント、会員ランクの進捗、周期変更・スキップ・解約の各ボタンについて、どう配置すれば迷わず操作できるかを、ワイヤーフレームで複数パターン試作して比べることが有効です。

とくに解約ボタンの位置や見せ方は、分かりにくくすると一時的に解約を防げても、ブランドへの不信感を招きかねません。そのため、手続きの途中で周期変更や別商品への切り替えを提案する画面遷移まで、ワイヤーフレームに落とし込んでおく必要があります。この段階で骨格を固めておくと、後のデザインモック制作での手戻りを防ぎやすくなります。

ポイント

購入導線と定期便管理の画面は、デザインを作り込む前に、迷う箇所が残っていないかで判断します。ワイヤーフレームの段階で直しておくほど、後の作り直しを抑えやすくなります。

プロトタイピングツールとスマホ実機によるUX検証

スマートフォンを中心に、カートボタン、商品画像、定期便の周期選択、決済時の入力項目とアクセス割合を示す図。
アクセスの多さを踏まえ、実機で確かめる箇所を整理できます。

ワイヤーフレームで骨格が固まったら、タップや画面遷移ができるプロトタイプを作ります。そのうえで、関係者の認識をそろえながら、より実践的なUX検証へ進みます。

スマホ実機での操作性検証(カートボタン・画像スワイプ・入力項目)

通販サイトへのアクセスの60〜70%以上はスマートフォン経由とされており、PC画面のデザインレビューに加えて、スマホでの確認が欠かせません。プロトタイピングツールを使えば、実際のスマホ画面で操作の感触を確かめられます。

たとえば、「カートボタンは押しやすいか」「商品画像はスワイプしやすいか」「定期便の周期選択は誤タップしにくいか」「決済時の入力項目は多すぎないか」といった、モバイルUXの細部を検証します。

とくに定期便の周期選択やお届け先の複数登録のように、入力項目が多い通販特有の画面ほど、スマホでの入力しやすさを丁寧に確認しておく必要があります。

高齢層を含む顧客層を想定したユーザビリティテスト設計

カタログ通販やテレビ通販の顧客層は、若年層中心のECサイトとは異なり、高齢層の比率が高いという特徴があります。そのため、文字サイズやボタンの大きさ、コントラスト、専門用語を使わない表記といった配慮は、若年層向けのユーザーテストだけでは見落とされがちです。

プロトタイプ検証の対象者には、実際の顧客層の年齢構成に近いモニターを含めることが大切です。あわせて、Webに不慣れな顧客が電話で注文する際に使う申込番号も対象になります。その見つけやすさや入力しやすさは、カタログ誌面のレイアウトと合わせて、プロトタイプの段階で確認しておくと、公開後のコールセンターへの問い合わせ削減につながります。

ポイント

プロトタイプは、スマホ実機で入力や誤タップが残っていないかを判断の基準にします。アクセスの多くがスマホ経由である点を踏まえると、公開後の手戻りを減らしやすくなります。

ユーザビリティテスト〜A/Bテストによる継続的改善

ユーザビリティテスト、UIの修正、A/Bテスト、定期的な分析を循環で示す図。
顧客の迷いを起点に、公開後の分析まで改善が続きます。

プロトタイプの検証が終わったら、実際のユーザーによる評価に進みます。次に、公開後は数値をもとにした改善サイクルへとつなげていきます。

既存顧客モニターを使ったタスク実行型ユーザビリティテスト

作成したプロトタイプを既存顧客のモニターに操作してもらい、使いやすさを直接評価するのがユーザビリティテストです。具体的には、「定期便の周期を毎月から2ヶ月ごとに変更する」「今月分の商品をスキップする」「カタログ記載の申込番号で商品を購入する」といったタスクを依頼します。そのうえで、どこで操作が止まったか、迷いや誤解が生じたかを観察して記録します。

既存の定期購入者を対象にしたこの検証では、見た目の印象に加えて、開発者側では気づけない「顧客の生の迷い」を拾い出します。その迷いをUIの修正に落とし込むことが、通販サイトのリニューアルで特に重要な工程です。

公開後のA/Bテストとフィードバックループ

通販サイトは、リニューアル(本番公開)して終わりではなく、公開後も改善を続ける継続的な活動として捉えておく必要があります。ユーザビリティテストを経て公開した新しいUIは、実際のトラフィックを使い、A/Bテストで定量的に測定します。

たとえば、「定期便への誘導バナーのどの文言がより申込率が高いか」「解約導線でどの引き止め提案が最も離脱を防げるか」などを測ります。タスク成功率の向上や解約率(チャーンレート)の低下といったデータは、定期的に分析して次の改善策に反映させます。こうした改善の流れを回し続けると、リニューアルの効果を最大化しやすくなります。

ポイント

公開前は、既存の定期購入者や高齢層を含むモニターで迷いや誤解が出ていないかを見ます。公開後は、A/Bテストの数値をもとに、改善を続けるかどうかを判断します。

PoC・プロトタイプ開発を成功させる発注前準備

ここまでの検証プロセスを無理なく進めるには、発注前の準備とパートナー選びの両方が欠かせません。

検証範囲・KPIを明確にした要件概要書

発注前に、検証対象と検証で明らかにしたいKPIを整理した要件概要書を用意しておくと、複数の制作会社・開発会社から比較しやすい検証プランと見積もりを得やすくなります。検証対象の例は、購入導線、マイページや定期便管理、申込番号システムなどです。KPIの例は、タスク成功率、離脱率、解約引き止め率などです。

既存の会員データやアクセス解析データから、現状どの画面で離脱や問い合わせが多いかをあらかじめ把握しておくと、検証の優先順位を明確にできます。そのため、限られた期間の中でも効果の高い検証に集中できます。

プロトタイピング・ユーザビリティテストの実績を重視したベンダー選定

依頼先を選ぶ際は、通販システムの開発実績に加えて、プロトタイピングツールを使ったUX検証や、既存顧客を対象にしたユーザビリティテストの設計・分析に慣れているかを、重点的に確認してください。

デザインをきれいに仕上げる技術力が高くても、定期便管理のような通販特有の複雑な画面を、ユーザーの迷いを踏まえて検証・改善した経験があるとは限りません。その経験がなければ、見た目を新しくしただけで数値が改善しないリニューアルに終わるリスクが高まります。

プロジェクトが始まったら、デザイン、検証、開発の担当者が集まる定例会議で、検証結果と改善方針を共有します。そのうえで、検証で見つかった課題を設計に反映させる体制を整えておくと、リニューアルの成功に近づきます。

ポイント

要件概要書に検証範囲とKPIが書けているかが、複数社の検証プランと見積もりを比べる基準になります。そのうえで、通販特有の複雑な画面を改善した実績があるかも確かめます。

まとめ

ここまで、通販サイト/システムのリニューアルにおけるPoC・プロトタイプ・モックアップ開発を解説してきました。モダナイゼーション(技術検証)、刷新(投資対効果の実証)、更改(実地検証)、ECリニューアル(一般総論)とは異なり、本記事の対象は通販特有の検証です。

その中心は、定期便のスキップ・周期変更・解約導線、カタログ・テレビ通販特有の申込番号によるクイックオーダー、高齢層を含む幅広い顧客層を想定したユーザビリティです。これらを、ワイヤーフレーム、プロトタイプ、ユーザビリティテストの各段階で丁寧に確かめます。

公開後もA/Bテストによる改善サイクルを回し続けると、通販サイトのリニューアル効果を最大化しやすくなります。検証範囲とKPIを明確にした要件概要書を用意し、プロトタイピング・ユーザビリティテストの実績を持つ信頼できるパートナーに、早めに相談することをお勧めします。

▼全体ガイドの記事
・通販サイト/システムのリニューアルの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。