中小規模の保険会社が、開発の順番待ちをせずに商品ページを出すには。
- 企業
- OneDegree Global
- 担当
- シニアプロダクトデザイナー
- プラットフォーム
- Web、SaaS
- 期間
- 2022年
プロジェクト概要
Launchpad は、限られた社内 IT リソースの中でも、中小規模の保険会社が保険商品ページを迅速に制作・運用できるよう設計された、モジュール型 CMS です。導入以前は、公開までに3か月以上かかることも珍しくありませんでした。
新しいキャンペーンや商品改定のたびに個別開発が必要で、マーケティング部門による要件整理、プロダクトチームとの調整を経てから開発に着手するのが一般的でした。商品やブランドごとにページ構成や品質にもばらつきが生じ、さらに、ちょっとした文言修正であってもエンジニアの対応が必要で、運用面で大きな負荷となっていました。
そこで Launchpad では、保険業務に特化したテンプレートベースの CMS を構築し、再利用可能なレイアウトブロックを組み合わせることで、ページ構成、フォーム設定、アセット登録、公開までをノーコードで完結できるようにしました。私はエディター全体の UI 設計とインタラクション設計を主導し、プロダクトの進行に合わせて新機能の UX 設計も引き継ぎました。
目標
プロダクト・ビジネス合意- 日常的な変更から開発者を外すレイアウトの微調整や文言修正に、エンジニアのチケットを必要としない状態にする。
- ページ品質を標準化する構造を一つに揃え、商品やブランドごとの品質のばらつきをなくす。
- 市場投入までの時間を短縮する個別開発を前提としない構成にし、リリースを数か月から数週間へ。
- 非技術系チームが扱える設計にするページを作るのはマーケティングと運用の担当者であり、エンジニアではない。
課題
社内ヒアリングでは、3つのペインポイントが繰り返し挙がりました。いずれも根は同じで、ページ上に再利用できるものが何もないため、すべてが個別開発になっていたことです。
- 軽微な変更でも開発者に依存するレイアウト修正やコンテンツ更新であっても、開発側のキューに並ぶ必要があり、日常業務の導線に専門職が挟まっている状態でした。
- 構成と品質にばらつきがある商品やブランドごとに個別に作られてきたため、ページ構成も見た目の品質も揃っていませんでした。
- 公開・更新に3か月以上 — 積み上がった結果要件整理、待ち時間、開発、テストが積み重なり、キャンペーンの前提そのものが変わってしまうほどの遅延になっていました。
リサーチ
社内関係者 — ビジネス・オンボーディング・サポートエンドユーザーに会えない状態での設計
そのため、彼らに最も近い立場にいる社内チーム —— ビジネス、オンボーディング、サポート —— からヒアリングを行いました。いずれも現行プロセスの結果を日々受け止めている部門です。ここでのインサイトは構造上すべて間接的なものであり、それ以上のものとして扱ってはいません。設計判断も、特定のユーザー行動に賭けるのではなく、後から戻せる構造的な選択に寄せています。
タスク整理と優先順位付け
非技術系ユーザーが商品ページを公開するまでに実際に行う作業を整理しました。レイアウトを選び、コンテンツを編集し、フォームとステップを設定し、公開前に確認する。この4つに絞り、例外への対応を意図的に見送ったことが、エディターを予測可能なものに保ちました。すべてに対応するビルダーは、結果として何も教えてくれません。
制約
技術 · ブランド設計を始める前から動かせないものが2つありました。エディターは完全なライブプレビューを描画できないこと、そしてビジュアルは他社のブランドの背後に消えなければならないことです。
どちらも交渉の余地はなく、そして両方が同じ方向を指していました —— これは表現力で勝てるプロダクトではない、ということです。初期案では、柔らかいシャドウや丸み、ブラーなどを用いた、より表情のある UI も検討しました。しかしステークホルダーレビューを通じて、独自の個性を持つインターフェースは保険各社のブランドガイドラインと衝突することが明確になり、最終的にニュートラルで構造的な方向へ引き戻しました。
難しかったのはプレビューの制約のほうです。ライブプレビューのないページビルダーは、ユーザーに「信じて公開する」ことを求めます。それは非技術系ユーザーがツールを信用しなくなる、まさにその瞬間です。制約として受け入れるのではなく、Standard API による実データ連携を提案し、編集中に見えているものが少なくとも構造として公開後のページと一致する状態を目指しました。
実装したもの
編集モデルこのプロダクト全体が、ひとつの判断の上に乗っています。ページは文書ではなく、ブロックの積み重ねであるということ。他のすべてはそこから導かれます —— 一貫性も、再利用も、マーケターが操作できるという事実も。
決められたブロックからページを組み立てるなら、品質は誰が作ったかに依存しなくなる。
すべてのページが個別に作られていたため、リリースを重ねても何も改善されず、一貫性も保たれませんでした。
- ブロック
- 商品ハイライト、FAQ、フォーム、メディアを差し替え可能なブロックとして提供
- 既定レイアウトから素早く着手できる
- テーマカラーの切り替えと背景画像のアップロード
- 構造をシステム側が保持し、編集者の規律に依存しない
- 期待効果
- ページは「作る」ものから「組む」ものになり、それが開発チームを日常業務から外します。
何を選んでも同じパネルが開く —— ブロックの種類ごとではなく、構造をひとつ覚えるだけで済む。
非技術系ユーザーは機能ごとにメンタルモデルを作りません。ひとつ作って使い回します。モジュールごとに編集画面が異なれば、ブロックの種類の数だけツールを学び直すことになります。
- パターン
- どのモジュールを選んでも、右側に同じパネルが開く
- テキスト、アセット、表示設定を同一のレイアウトで扱う
- 選択状態、ドラッグ＆ドロップ、遷移を一度だけ定義
- 期待効果
- ページタイプごとではなく、構造をひとつ覚えるだけで済む。このプロダクトで学習コストを最も大きく下げている部分です。
コア領域
CMS · 購入フロー · デザインシステム商品データは再入力せず取り込む —— 手入力は小さなリスクではなく、コンプライアンス上のリスクだから。
エディターは IXT プラットフォームや外部システムと API 連携します。保険の商品データは規制対象でバージョン管理されるものなので、ページが第二の原本になってはいけません。
- フロー
- 商品情報の取り込み、レビュー申請、公開予約、終了後の非公開化までを、同じテンプレートベースの UI で完結できます。
- 期待効果
- 商品データの参照元がひとつになり、運用担当者が単独で回せる公開フローが手に入ります。
購入までの流れはほとんどの中小規模保険会社で同じ5ステップ —— だから個別開発ではなくテンプレートとして提供した。
ここは保険会社が最も間違えられない部分であり、同時に最も自力で作りにくい部分です。テンプレート化する価値が最も高いのがここでした。
- ステップ
- アカウント作成、プラン選択、フォーム入力、見積もり、決済。
- 期待効果
- 個別の開発プロジェクトを立てずに、完結した購入体験を用意できる状態になります。
トークンは値ではなく状態を名前にする。だからライトとダークは同じ定義から導かれる。
Atomic Design の考え方に基づき、Atoms、Molecules、再利用可能なレイアウトブロックで構成しました。新規モジュールは作り直すのではなく、継承して成立します。
- トークン
- セマンティックカラーシステム —— default、hover、error、success。たまたまその色であることではなく、何を意味するかで名付けています。
- 意図
- 長時間の編集作業でも視認性を保ち、同時に複数の保険会社ブランドの下に置けるだけのニュートラルさを維持すること。
- 期待効果
- 商品ページと購入フローの一貫性が保たれ、状態が既に名付けられているぶん、開発への引き継ぎも明確になりました。
検討して見送ったもの
検討のうえ、採用せず結果
以下の数値は想定値とパートナーからの初期フィードバックであり、計測された結果ではありません。本番データで検証できる段階の前に離任しているため、それ以上のものとして提示するつもりはありません。
保険業界向けに特化して設計されているため、必要な機能が揃っていて使いやすい。
汎用ビルダーではなく保険特化テンプレートに賭けた判断を裏づける声。
WordPress も試しましたが、学習コストが高く、このツールは私たちのニーズに合っていると感じました。
超えるべきは学習コストであり、それを超えたのが統一パネル。
この案件から得たもの
- 理想と、チームの実際の動き方との折り合いをつける伝統的な業界向けの設計では、実際の業務フローとツールの成熟度に照らして調整することが必要です。チームの動き方に合わない先進的な機能は、先進的なのではなく、使われないだけです。
- ドメイン理解そのものが設計である保険の業務ルールの多くは文書化されておらず、人の頭の中にあります。それをヒアリングで引き出し、マーケターが操作できる構造へ翻訳することが、このプロジェクトの実体でした。その上に乗るインターフェースではなく。