CASE STUDY ・ 人材業界 ・ 福利厚生ポータルを設計するとき、機能より先に決めること｜PerkPort開発事例（仮称）
- 福利厚生
- 会員ポータル
- クーポン
- デジタルチケット
- Nuxt.js
- Vue.js
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
匿名化した福利厚生事業者の、会員ポータル刷新。
本事例の顧客は、企業の従業員向けに全国の優待・クーポンを届ける福利厚生事業者です。機密保持のため、プロジェクト名と顧客名は匿名化しています。
メニューが増えるほど社員が探しにくくなること、申込み後の利用導線が紙や問い合わせに戻りやすいことが、設計上の課題でした。会員が優待を探し、取得し、後から確認できる流れを一つのポータルにまとめる方針を採りました。
利用者が途中で離れないための、4つの設計課題。
- 優待を探す
カテゴリや条件が多く、目的のメニューに辿り着けない。
- 優待を選ぶ
一度見た優待を再度探す必要がある。
- 利用する
申込み後に紙や問い合わせへ戻ると、利用状況を確認しにくい。
- 運用する
更新情報と会員向け表示の責任範囲が曖昧だと、制度を継続的に改善できない。
会員ポータルを、探す・使う・再訪の3領域で構成。
検索・閲覧・利用の導線を、会員向けの一つの基盤として構築しました。開発ストーリーに記載された構築期間は10か月、総工数は36人月です。これは開発範囲を把握するための記録であり、品質や効果を保証する数値ではありません。
- 領域 01探しやすさ課題
カテゴリと条件から目的の優待へ辿り着く必要。
解決策6カテゴリの切り替え、キーワード検索、絞り込みで一覧を整理。
- 領域 02使いやすさ課題
優待の取得後に利用方法を確認できる必要。
解決策デジタルチケットを発行し、会員画面のチケット一覧で管理。
- 領域 03会員ごとの再訪導線課題
次に見る優待を見つけやすくする必要。
解決策お気に入り、閲覧履歴、ランキングを会員トップに配置。
導入判断に使える、確認可能な設計上の価値。
PerkPortで確認できるのは、福利厚生の情報を「探す」「使う」「あとで確認する」という利用者の流れを、会員ポータルに落とし込んだことです。導入後の利用率、問い合わせ削減率、従業員満足度などの業務成果は、本公開範囲では主張しません。
この事例の根拠と読み方
根拠：AMELAの移行記録、匿名化した開発ストーリー、動作デモ。
確認できること：カテゴリ検索、絞り込み、お気に入り、閲覧履歴、デジタルチケット発行という実装の組み合わせ。
確認できないこと：導入後の利用率や業務成果。効果を判断するには、導入前後の期間、対象者、分母、除外条件を別途合意して測定します。
読者が使える実践ツール
| 判断項目 | 記入例 | 自社で追加確認すること |
|---|---|---|
| 探索 | カテゴリと検索から優待を絞り込める | 公開・会員限定データの境界、検索対象件数 |
| 利用 | 会員画面からデジタルチケットを発行できる | 発行取消、再発行、利用済み処理、問い合わせ時の履歴 |
| 再訪 | お気に入り・閲覧履歴・ランキングがある | 推薦ルール、個人情報の保存期間、表示の説明責任 |
- Stakeholder会員優待を探す人一般的に
目的の優待が見つからないと利用まで進みにくい。
本プロジェクトではカテゴリ、検索、絞り込みを一つの導線に配置。
事業インパクト探索導線を確認できる効果測定は別途必要 - Stakeholder運用担当福利厚生担当一般的に
更新情報と会員向け表示の管理が分かれやすい。
本プロジェクトではチケットと会員画面の状態を確認できる。
事業インパクト運用記録の設計工数削減は未測定 - Stakeholder制度責任者経営・人事企画一般的に
制度が使われたかを判断する材料が不足しやすい。
本プロジェクトでは測定項目を後から定義できる導線を用意。
事業インパクト評価条件を先に決める成果は本公開範囲外
05 / DEMO
実際に動くデモで、PerkPortの導線を確認。
- シナリオ優待を探すカテゴリと検索から会員トップを確認。デモを起動 →
- シナリオマイページお気に入りと閲覧履歴の導線を確認。デモを起動 →
- シナリオチケット発行済みデジタルチケットの一覧を確認。デモを起動 →
