デザイン5y+

Startup Web Product Support

新規事業のWebプロダクトで、ユーザー体験、業務運用、管理画面、公開後改善までをつなぎ、サービスとして動く骨格を設計しました。

Service DesignRequirementsOperation FlowWireframeMaintenance
CHALLENGE課題

新規事業では、LPや画面をきれいに作るだけではサービスが回りません。ユーザーが申し込む、事業側が判断する、管理側が確認する、問い合わせに対応する、公開後に改善するという流れまで同時に考えないと、見た目は整っていても運用で詰まります。

APPROACHアプローチ

事業仮説、対象ユーザー、MVP範囲、入力項目、ステータス、通知、管理画面、運用担当者の作業順を整理し、ワイヤー、モック、HTML/CSS/JavaScript実装、改善提案、保守へ接続しました。画面単体ではなく、サービスが動く順番から逆算しています。

RESULT成果

装飾としてのデザインではなく、サービスの構造、仕様、運用、公開後の改善まで見られる点を強みとして示せる内容にしました。UIの見た目よりも、利用者、事業、管理の3者が迷わず動ける設計を重視しています。

CASE STUDY詳細

画面デザインではなく、サービスが動く順番を設計する

この実績では、Webページや管理画面を作る前に「誰が、いつ、何を判断し、次に何が起きるか」を整理することを中心にしています。スタートアップの速度に合わせながら、後から運用で破綻しにくい最小構成を作る支援です。

初期設計

事業の目的とユーザーの行動を分け、最初に作るべき範囲と後回しにする範囲を整理します。

  • 対象ユーザー、利用シーン、初回接点を定義
  • MVPで必要な機能と、後続改善に回す機能を分離
  • 成果指標、問い合わせ導線、離脱しやすい地点を仮説化

体験と業務フロー

ユーザー側の体験だけでなく、裏側で確認、承認、返信、更新する人の流れまで設計します。

  • ユーザー登録、申込、確認、完了までの状態を整理
  • 管理側が見る項目、判断する項目、触らない項目を分離
  • 通知、問い合わせ、例外対応の流れを画面設計に反映

仕様化とワイヤー

抽象的な要望を、画面一覧、入力項目、状態、優先順位、実装単位へ落とし込みます。

  • 画面遷移、フォーム項目、エラー状態を整理
  • LP、申込導線、管理画面、メール文面の役割を分ける
  • エンジニアが実装しやすい粒度で要件を言語化

公開後の改善

公開して終わりではなく、問い合わせ、運用負荷、離脱、文言の伝わり方を見ながら改善します。

  • 運用担当者から出る詰まりを改善バックログへ反映
  • ボタン文言、フォーム順、説明量を利用状況に合わせて調整
  • 小さく直せるHTML/CSS/JavaScript改善まで対応