某食品メーカー 様
要件整理、商品カテゴリ設計、サイト構成、情報設計、導線設計、ワイヤーフレーム、Webデザイン、楽楽B2B実装、レスポンシブ調整、公開対応
ゲラップは、法人向けに業務用商品を販売する食品メーカーのBtoB ECサイトを、楽楽B2Bでリニューアルしました。複数のページに分かれていた商品群を大分類・中分類・小分類の3階層に並べ直し、一覧からカテゴリ、商品詳細までを同じ分類でたどれる構成にしています。要件整理から公開までは約5か月でした。
法人のお客様が必要な商品を選び、継続して発注するためのBtoB ECサイトです。取扱商品は業務用の食品を中心に幅が広く、購入担当者が探すときの基準も、用途や必要な仕様によって変わります。
商品の見え方も一律ではありません。会員の登録状況と、商品ごとに設定する販路によって、誰にどの商品が見えるかが変わります。見た目を整えるだけでは終わらず、商品を探す流れと受発注の運用をあわせて見直すことが前提でした。
商品名を知っている人は、検索で見つけられます。ただ、商品名を知らない人には、分類をたどる以外に探す手がかりがありません。何を取り扱っているのかが分からないまま、買う商品を決めることになります。
既存サイトでは、商品情報が複数のページや分類に分かれていました。一つひとつのページは成立していても、並べて見たときに商品同士の関係が分かりません。
着手して最初にやったのは、どの商品をどの分類で扱うかを、一つずつ確認し直すことでした。従来の掲載先をそのまま引き継ぐと、同じ分かりにくさが新しい画面に移るだけです。ページ名を置き換えるのではなく、商品のまとまりそのものを洗い直しました。
画面から先に作っても、分類の基準が決まっていなければ、探しにくさは別の画面に残ります。
検索は、商品名や呼び方を知っている人には有効です。一方、いくつかの商品を見比べて選ぶ人には、検索だけでは商品同士の関係が分かりません。特集やバナーも特定の商品を案内する役割なので、日常的に扱う商品群の整理には向きません。
大分類で取扱領域を示し、中分類で選び方の軸を分け、小分類で具体的な商品群まで絞り込む形にしました。一覧ページ、カテゴリページ、商品詳細ページが同じルールでつながるところまでを最初に決め、検索や特集は、分類を補う導線として残しています。
探しにくいサイトは、検索機能が足りないのではなく、商品の並べ方が決まっていないことがあります。画面を直す前に、どの商品をどの分類に置くかを決めます。
クライアントには、商品同士の関係や取引上の条件を確認いただき、商品情報と画像の準備、登録を担当していただきました。ゲラップは要件整理とワイヤーフレームから入り、分類の設計、主要画面のデザイン、楽楽B2Bでの実装、公開対応までを担当しています。
工程 | クライアント | ゲラップ |
|---|---|---|
要件整理 | 販売方法、取引条件、運用上の要望を共有 | 要望の整理、対応範囲と優先順位の設定 |
商品・情報設計 | 商品情報と分類内容の確認 | 大・中・小分類の設計、サイト構成と導線の整理 |
デザイン | 掲載内容と画面の確認 | ワイヤーフレーム、一覧・カテゴリ・詳細画面のデザイン |
実装・検証 | 取引条件と登録内容の確認 | 楽楽B2Bの設定、画面の調整、表示・動作確認 |
入稿・公開 | 商品情報・画像の準備と登録、最終確認 | 主要コンテンツの入稿支援、調整、公開対応 |
設計と制作で終わらせず、実際の商品登録と公開環境への移行まで工程に入れました。確認の対象は、トップから404ページまでの40を超える画面と、並行して入稿した特集の記事です。商品が入っていない画面と、実データが入った画面では、見え方が変わります。分類と画面だけを見たまま公開日を迎えないよう、確認の場を分けています。
いちばん時間がかかったのは、商品分類とシステム仕様を別々に進められなかったことです。
分類は、商品名を表に並べ直せば終わる作業ではありません。どの基準でまとめるか、同じ商品を複数の入口から案内するか、会員の状態による表示とどう合わせるか。利用者に分かりやすく、運用側も更新を続けられる粒度を探しました。同じ商品群に、容量から探す入口と産地から探す入口の両方を置いた箇所もあります。
楽楽B2Bはパッケージなので、できることの範囲が先に決まっています。そこで標準仕様を確認し、設定で変えられる範囲、画面の調整で対応する範囲、運用で補う範囲を整理しました。表示や遷移に関する確認事項は80件を超えます。一件ずつ、どこで対応するかを確認しながら進めました。
要望の中には、システムで実現できるかどうかより先に、業務側の決めごとが必要なものがありました。受注をどの流れで処理するか、決済のデータをどう受け渡すか、顧客をどの区分で登録するか。ここが決まらないと、どの画面に何を出すかも決まりません。
そこで、画面の要件と運用の要件を同じ表で管理し、公開前に決めることと、公開後に運用しながら調整することを分けました。
ゲラップから出した機能や導線の提案は、一覧にして「絶対に必要」「欲しい」「不要」の3段階で評価していただきました。数は十数件です。評価の理由もあわせて伺い、どこから作るかを決めました。
パッケージのシステムを使うと、標準仕様のままでは実現できない要望も出てきます。そこで「できません」と終わらせずに、別の画面や導線で代われないか、運用のルールで補えないかを確かめます。そのうえで対応方針を決めます。
分かれていた商品群は大分類・中分類・小分類の3階層で整理し、一覧、カテゴリ、商品詳細に同じ考え方を通しました。システム上の要望は、設定で変えるか、画面を調整するか、運用で補うかを確認しながら、公開まで進めました。
項目 | やったこと |
|---|---|
商品分類 | 複数のページに分かれていた商品群を、大分類・中分類・小分類の3階層で再整理 |
商品への導線 | 一覧・カテゴリ・商品詳細を共通の分類ルールで接続 |
システム対応 | 設定変更・画面調整・対応不可・運用対応に分けて、要望を一件ずつ確認 |
制作・公開 | 要件整理から実装・公開までを約5か月で進行 |
同じ進め方をするなら、必要なことは二つあります。
一つは、いまのカテゴリを前提にせず、利用者が何を基準に商品を選ぶかを言葉にすることです。商品名の一覧だけで分類を決めると、社内では通じる区分が、利用者には伝わらないことがあります。用途や比較の軸を答えられる担当者に、分類の検討へ入ってもらいます。
もう一つは、デザインを確定する前に、システムの標準機能と変更できる範囲、そして受注や決済の流れを確かめることです。設定、画面の調整、運用のどこで実現するかも、その段階で決めておきます。
商品が入っていない画面で確認できることには限りがあります。扱う商品が多いECほど、実データを登録したあとにもう一度画面を見る時間を、工程に入れておきます。