新機能設計において、体験の検証をどこまで・どのように進めれば良いかは迷うところです。その機能がユーザーにとってまだ慣れていない行動だとすると、さらに検証の難易度は高まります。
昨年、ウエディングパークがつくる結婚式場向けシステム「survox（サーヴォックス）」の中に、接客シナリオを登録・編集できる新機能が追加されました。私はデザイナーとしてこのプロジェクトに参加し、シナリオ編集画面のデザインを担当しています。 結婚式場の方にとって「シナリオを使った接客」という考え方はまだまだ一般的ではありません。そこで私はReactで動くプロトタイプを実装しながら、慣れない操作でもユーザーが自然と行動してくれるような体験に磨き込んでいきました。
単に静的な画面をデザインするだけでは不十分だと考えた理由や、具体的に動作でこだわったポイントをまとめます。
今回の対象プロダクトは、ウエディングパークが結婚式場向けに提供するサービス「survox」です。
survoxは結婚式場のあらゆる業務課題を、顧客の声をもとに変えていくことを目指したサービスです。サーベイや音声AIによる式場を訪れるカップルのインサイト回収・分析や、接客業務の改善などさまざまな機能を提供しています。
survoxが解決しようとしている業務課題の一つが「ウエディングプランナーの育成」です。
ウエディング業界では、人材不足によって新人育成機会が不足しがちという問題があります。そこでsurvoxでは
ベテランプランナーの接客の型や式場ごとの接客のパターンをシナリオとして可視化
実際の接客の議事録とお手本のシナリオを比較して、改善点をアドバイス
という、誰でも質の高い「おもてなし」が実現できるようなウエディングプランナー育成サポート機能群をプロダクトとして提供しています。
今回のシナリオ作成・編集機能はウエディングプランナー育成の課題を解決するための機能群の一つとして2025年8月にリリースされたものです。
ユーザーとなるウエディングプランナーの皆さんが実際の接客で話している内容をシナリオとして登録し、誰でも使いやすいようなトークフローに編集することで、どのプランナーも接客の質を下げずに接客できるようになるような効果を想定しています。
私はデザイナーとして、シナリオ編集画面のデザインや実装を担当しました。
今回の機能設計では、「シナリオ編集」というほとんどのユーザーが経験したことがない行動を、どうすれば自然と行ってもらえるのか検証することがポイントでした。
まず、シナリオを使って接客の質を高めるという考え方は、結婚式場としてあまり馴染みのないものです。ウエディングプランナーはこれまでの自分の経験をもとに接客をするのが普通で、各人に型のようなものがあったとしてもそれをプランナー間で共有するための仕組みは無いことが多いです。 そのような状況だったため、検証段階では各結婚式場から聞いた内容をもとにウエディングパーク側のディレクターがそれぞれのシナリオをつくるサポートをしていたのですが、今回のプロジェクトではプロダクト上でシナリオの作成・編集をユーザー自身に操作してもらうことを目指していました。
現状はシナリオ編集経験がほとんどない方が多い中で、「シナリオ編集機能」を使ってもらうというのは思っている以上にハードルが高いことだろうと想像していました。
なのでデザインにおいては「綺麗な画面」「情報が入ってきやすい」というだけでは不十分で、印象よりもむしろ、編集のしやすさ・操作のしやすさなど「シナリオを編集したことがない人でも使えるか」という体験の検証が必要でした。そしてそのためにはFigmaで静的な画面をつくるのでは不十分だと考えました。
このような要件を踏まえると、デザインを詰める段階から細かな動作・挙動までプロトタイピングしながら体験を磨く必要があるだろうと予想がつきました。編集機能のような「使えるかどうか」が重要な機能は、実際に動かしてみないと検証しづらいからです。
そこで今回私は、普段のデザイナーとしての担当部分を少し越えて、編集時の挙動・バリデートや印刷画面の見え方など、動的なプロトタイプまでReactで実装しながら体験の検証を進めました。
私がプロジェクトに入ったタイミングで、すでに大体の仕様案や画面のイメージはディレクターや前任のデザイナーが用意してくれていました。ウエディングパークではCSSやHTMLの見た目の実装まではデザイナーが役割を持つので、私も最初はCSSでの見た目上のコーディングだけ行おうとしていました。
そこで前述したような背景に気付き「編集画面は操作体験を磨くのが一番大事で、実装するならそこまでつくらないとあまり意味がない」と考えを改めます。
さらにsurvoxは新規事業でチームのリソースにも限りがあります。シナリオ編集機能はあくまで同時に公開するウエディングプランナー育成機能群の一つでしかなく、この機能だけにエンジニアも大きく工数を割けるわけではありませんでした。
ならば自分がデザイナーとして動作の実装まで担当する方がチームにとってより良いのではないかと考えました。
ちなみに前提として、私は2022年にウエディングパークにデザイナーとして新卒入社してから、静的な画面の実装・少し動的な箇所を含むチャット画面などの実装をすでに経験してきています。(こちらの事例にもまとめられているように、ウエディングパークではデザイナーがUIデザインからHTMLやCSSでのコーディングまでを担当します。)
今回のようなほぼ動的な実装となる編集画面のような案件の実装は自分としても未経験でしたが、2週間は編集機能のデザイン+実装のみに集中するように事業部とコミュニケーションしつつ、毎日朝会でディレクターやエンジニアと会話する環境もあったのでうまく進めることができました。
プロトタイピングで意識していたのは、操作時の違和感を限りなくゼロにすることです。
シナリオをつくるという体験はウエディングプランナーの方々にとって馴染みのないものです。そのような慣れない行動を受け入れてもらうためには「そもそもの操作でつまずかせない」ことが大切だと考えました。
磨き込もうと思えば無限に磨けるものではあるのですが、限られた工数の中でこだわるべき品質とは何かを考えながら実装しています。
見た目で違和感を感じると「なんとなく使いづらい」と思わせてしまいます。慣れない操作だからこそ印象面で不信感を抱かせないようにしています。
例えば、接客シナリオの編集ではトークの順序を入れ替えながらより良い会話を考えるのでドラッグ&ドロップが多用されます。この時にコンポーネントが崩れないようにする、など基礎的なところを押さえていきました。
また、シナリオをドラッグ&ドロップしている最中にどのようなデータを表示すべきかも定義しました。
操作中に「どのシナリオを移動させているかがわからない」となるとユーザーが混乱するはずなので、シナリオのタイトルは正規のデータをそのまま表示します。一方で、操作中のシナリオに紐づく全てのデータを表示したままにすると画面が見づらくなるので、掴んだオブジェクトの子要素は非表示になるようにしました。
あくまでドラッグ&ドロップしている時にユーザーがやりたい行動は「シナリオの入れ替え」なので、シナリオの内容確認はできなくても良いと考えています。この仕様に合わせて新規でダミーデータを用意してデータ構造を変更しました。
編集画面でユーザーが一番やりたいことは「追加・入れ替えなどをしながら、より良いシナリオをつくる」ことなので、この目的に集中できるように画面をつくることを意識しました。
操作に集中してもらうためにできることの一つは、メインで扱うオブジェクトを画面の中心にすることです。今回でいうとシナリオのデータが一番扱いたいオブジェクトなので、これを画面幅としても一番広く取るように調整しています。
逆に目次や過去シナリオの呼び出しのようなサブのオブジェクトは画面幅を狭くしたり、非表示にできるようにしました。
また、一つひとつのシナリオは長くなるので「シナリオの全体像を簡単に俯瞰したい」というインサイトに応えるために目次を実装しました。
ただ目次がページ上部に固定される実装だと、毎回ページ上部まで確認しにいかないといけなくてストレスです。なので、ページをスクロールしても目次が常に左側に固定表示されるよう実装しました。これも、編集操作に集中してもらうことがこの画面において最も重要なためです。
実装時に意識したもう一つのポイントは「ユーザーがしたい行動をプロダクトからアシストする」ということです。
シナリオの編集という慣れない行動をウエディングプランナーの方に浸透していくためには「単に編集できる」ということを超えて「これは使える」と思ってもらう必要があるためです。このプロダクトがないと困る、と思ってもらえるように細かなユースケースも考えていきました。
例えば、リリースされた後にウエディングプランナーの方々がシナリオ機能をどう使うのか？まで想定しています。
パソコンやタブレットの台数が限られる結婚式場ではシナリオを印刷して対面ロープレ時に参照したい人もいることが分かっていたので、印刷に対応できる画面になるよう実装しました。
ページを印刷した時に途中で切れたりしないか？白黒印刷しても色味がうまく出るか？などの観点で細かく調整をかけています。
プロダクトの操作に慣れない状態で起こりやすいエラーにも事前に対応しておきました。例えば、編集機能で一番嫌なことの一つは「せっかく操作していた内容が保存されず消えてしまうこと」です。
シナリオ編集機能の初期リリースでは自動保存機能は工数的に実装が難しく、毎回保存ボタンを押す必要がある仕様となっていました。ブラウザバックすると内容が消えてしまう状態だったので、このままリリースするとお客さまからエラー報告がたくさん起こることが予想できました。
操作に慣れない状態でこのような出来事が起こると、「もう触りたくない」とユーザーがシナリオ編集から遠ざかってしまうことも想定されます。
そこで、限られた工数の中で実現できる、ブラウザバックしようとした時に保存しているかどうかをポップアップで確認する実装をつけました。
また、もともと保存ボタンのラベルは「更新する」というテキストになっていたのですが、おそらく認識しづらいだろうと思い「変更を保存する」とテキストを変えアイコンもつけ、スクロールしても自動で付いてくるようにして必ず存在に気付けるよう実装しました。
実装を進めながら本当に違和感なく使えるような操作体験になっているのかをテストします。
ここでのポイントはテストの対象には “業務理解が深い人” を選ぶことでした。結婚式場のウエディングプランナーの方々はこのようなシナリオ編集業務に馴染みがあるわけではないので、プロトタイプの段階でテストしてもうまく声を引き出せない可能性があります。
それよりももともとシナリオ作成に何度も取り組んでいるウエディングパークの社内のディレクターが使えると思えるか？を確認する方が適切だろうと考えました。
なので、チーム内でシナリオ作成・編集に詳しい方を中心にプロトタイプの動作を確認してもらい「違和感なく操作できるか？」を確かめています。
ディレクターに実際の式場のシナリオをプロトタイプでつくってもらいながら気になった点に対してレビューをもらい、すぐに改善していく流れを繰り返します。
「シナリオの必要性や編集イメージを持っている人ならば、違和感なく触れる」というラインをミニマムな品質として、その段階まで磨くことができた段階でリリースしました。
結果として2025年8月にシナリオ編集機能を含めた、survoxとしてのウエディングプランナー育成サポート機能群をリリースすることができました。
ほとんどの結婚式場にとって「シナリオを使った接客体験」はこれまで存在していなかった業務です。それでもこの機能群を導入、活用してくれている式場が増えてきており、それにともなってシナリオ編集機能を自分で触ってくれているウエディングプランナーの方も少しずつ生まれています。
survoxは、これまで解決されていなかったウエディング業界の課題を新しい切り口で解決していくサービスです。survoxの機能はどれも式場の方にとっては新しい業務体験であることが多く、自然と受け入れてもらうためには今回のように体験の滑らかさを磨くことが必須です。
シナリオを使って誰でも質の高い「おもてなし」を提供できるようになる理想に向けて、シナリオ編集機能もさらにアップデートしていきます。
今回のように動的な実装を通して体験検証まで突き詰めていく役割を経験したことで、私自身のデザイナーとしての責任範囲も広がっていきました。
これまでは、UIのデザインからCSSなどでの静的な画面の実装にとどまっていましたが、今回のプロセスで「ここまでやって良いんだ」と気付けたことで、使い心地や体験まで検証していく必要性がある機能ではデザイナーとして動作部分も実装していくように動き方が変わっています。
デザイナーが実装も含めた体験づくりに踏み込めると、エンジニアもより技術的な課題に集中してもらえるのでチームとしての最適配置ができるようになります。
survoxの事業部メンバーからもこのような動き方を信頼してもらえて、2025年の秋から私はsurvoxの専属デザイナーになりました。新規事業を育てていくタイミングで、戦力として認識してもらえたのは純粋に嬉しいです。
ウエディングパークのように新しい体験づくりにチャレンジする会社では、体験を早く精度高く検証するための「プロトタイピング」が大きな武器になります。単なる絵づくりを越えて本当に使われるものづくりにこだわれば、ウエディングパークのデザイナーはもっと価値を出せると思うので、今回のような専門性をさらに軸にしてより良い体験をつくっていきます。