プロフィール

作品一覧

その他

SmartOrdee

SmartOrdee（スマートオーディー）は、飲食店の注文体験をスムーズにするQRコードオーダーシステムです。 本プロジェクトはポートフォリオ用に制作した架空のサービスを想定したものであり、実際の提供サービスではありません。 ただし、飲食店での実体験をベースにUX課題を洗い出し、実運用を想定したユーザー導線・機能設計、デバイスごとのUI最適化、視認性や操作性の検証などを通じて、実際のリリースにも耐えうる品質を目指して制作しました。

  • Webアプリケーション
  • リサーチ
  • コンセプト定義
  • 情報設計
  • ビジュアルデザイン
  • デザインシステム

SmartOrdeeのFigmaファイルはこちら

プロジェクト概要

  • カテゴリー：Webアプリケーション
  • 制作種別：自主制作
  • 担当領域：リサーチ、ヒアリング、要件定義、情報設計、UI設計、デザインシステム構築
  • 使用ツール：Figma
  • 制作期間：3ヶ月

どんなアプリか？

SmartOrdeeは、来店客が自身のスマートフォンでQRコードを読み取り、直接注文できるシステムです。 従来の口頭注文や紙の伝票を使わず、スムーズでストレスのない注文体験を提供します。 また、QRコードオーダーを主軸に、注文、キッチン、提供、会計など飲食店のオペレーション全体を効率化・自動化し、誰にとってもスムーズでストレスのない体験を実現するサービスとなっています。

加えて、SmartOrdeeは、単なるUI改修にとどまらず、業界構造の分析や競合リサーチ、ユーザー調査を徹底的に行い、現場の課題と利用者のニーズを深く掘り下げました。 その上で、操作の煩雑さやメニューの探しにくさなど表層的な問題だけでなく、飲食店オペレーション全体の効率化と直感的で迷わない体験を目指した根本的な設計改善を行っています。

プロトタイプ

来店客向けUI

管理画面 ＊拡大推奨

SmartOrdeeのFigmaファイルはこちら

飲食店向けSass型オーダー管理システム「SmartOrdee」

制作の背景

日常的に飲食店で利用するQRコードオーダーシステムに対して、「UIが直感的でない」「情報が見づらい」「操作のフィードバックが曖昧」「誤操作しやすい」といった課題を感じたことが、 本アプリをデザインするきっかけとなりました。

設計プロセス

設計プロセスは以下の手順で進めました。

  1. 課題仮説
  2. 前提知識の強化
  3. 競合リサーチ：競合サービスの強み、弱み、差別化ポイントを明確化
  4. ユーザーリサーチ：探索型の定性調査でユーザーの課題やニーズを把握
  5. コア価値の定義
  6. ペルソナ設計：課題やニーズを深掘り
  7. カスタマージャーニー作成：具体的な操作フローの中での課題を明確化
  8. 要件定義・情報設計：OOUIの手法を用いて整理
  9. ワイヤフレーム・プロトタイプ制作
  10. 検証と改善：タスク達成性、情報構造、導線の観点で
  11. ビジュアルデザイン：配色、詳細なレイアウト、タイポグラフィー等
  12. 検証と改善：ユーザビリティ、アクセシビリティ等

背景・課題仮説

まずは、仮説として「このような課題があるのではないか？」というものを整理し、以降のリサーチ等の方向性を定めました。

  • スタッフの募集が追いつかず常に人手不足になりがち
  • 飲食店における注文業務には、スタッフの負担増大やオーダーミス、待ち時間の長期化といった課題がある
  • 非接触型注文のニーズが高まっている中で、誰でも直感的に使えるデジタル注文体験の重要性が増している
  • 近年、QRコードオーダーシステムは普及しつつあるが、実際に利用してみて「UIが直感的でない」、「情報が見づらい」、「操作のフィードバックが曖昧」、「誤操作しやすい」といった課題を感じるサービスが多い

前提知識の強化

リサーチや設計に入る前に、飲食店業界の構造等についてデスクリサーチを行いました。 これは、ユーザーの行動や課題が、業界固有の制約や文脈に強く依存するため、的外れな設計を避け、実効性のある体験設計を行うには、業界や業務の構造的理解が不可欠であるため。

業界固有の課題

  • 人手不足：慢性的なスタッフ不足で、注文〜配膳の省人化ニーズが強い
  • ピーク時の業務集中：ランチ・ディナーの時間帯に注文が集中し、処理遅延が起きやすい
  • 注文ミスや聞き間違い：ホール注文はミスが起きやすく、自動化による削減が求められる
  • 回転率が重視：注文の速さや会計のスムーズさが売上に直結
  • 厨房との連携：注文情報はリアルタイムでキッチンに連携する必要がある

慣行・現場運用上の注意点

  • オーダー入力はスタッフが行うのが前提の店も多い（特に高級店、個人店）
  • 紙伝票や厨房プリンターとの連携が残っている現場もある
  • テーブル番号や会計処理の運用は店舗ごとにバラバラ（連番、物理札、POS連携有/無）
  • 注文後の変更や注文キャンセルも現場でよく発生

関連する法規制・制度

  • 軽減税率対応：イートインとテイクアウトで税率が異なる
  • インボイス制度：消費税額や事業者番号の明記が必要（会計処理との連携に関わる）
  • アレルゲン表示義務/食品表示法：メニュー表示における注意点

その他設計時の注意点

  • オフライン対応：回線が不安定な環境を想定した設計
  • 多言語対応：訪日外国人向けに言語切り替え機能
  • 会計連携（POS、キャッシュレス）：注文情報と決済の統合の要望が高い

競合リサーチ

同じ課題に対して他社がどのように解決しているかを把握し、業界内で一般的とされるUIパターンやユーザーの期待値を理解した上で、 自社プロダクトの改善点や差別化の方向性を見出すために競合リサーチを行いました。 調査対象は、Squareセルフオーダー、食べログオーダー、QR food、簡単注文、Aire REGIオーダーの5社。リサーチの結果をまとめたものが以下。

競合の強み

  • サポート体制の充実
  • 大手企業の営業力や資本力によるシェア率の高さ
  • POSレジとの連携が容易
  • 決済機能つき
  • 月額費用が安い（大企業は利益率よりシェア拡大を狙って低価格でのサービス提供をしている）
  • オーダーシステムは安く提供し、POS連携や決済端末との連携で利益を得ている
  • 多言語対応でインバウンド需要にも対応
  • 多機能で拡張性が高い
  • 専用端末（タブレット）を提供している会社のサービスのUIUXは優れている

競合の弱み

  • お客さんがQRコードを読み取り自身のスマホから注文するスタイルの会社は、UIUXが考え抜かれていない。一覧性や視認性、操作性の観点で問題が散見される。具体的には、カテゴリの階層が深すぎる、表品名が見切れる、インタラクション不足など。
  • デジタル機器に慣れていないお客さん（特に高齢世代）への対策が薄い
  • カスタマイズ性が低い
  • 初期費用が高く、小~中規模店舗では導入にハードルがある（専用端末を用意しているタイプのサービス）
  • 初期設定が複雑で、導入のハードルが高い

差別化ポイント

基本的な、注文、キッチンとの連動、決済といった飲食店のオペレーション全体をカバーできることを前提に、 ユーザー体験を徹底的に追求し、インタラクションコストを最小化した設計を行うこと。具体的には以下。

  • 初めて使う人でも迷わないシンプルな導線設計
  • 十分なタップエリアの確保やタップエリア間に十分な余白確保
  • 最小ステップで注文完了できる構成にする
  • 重要な操作に対してインタラクションを入れる
  • 余計な情報を削り、情報の一覧性、視認性の向上
  • アイコンボタンには必ずラベルを付与する
  • 初期設定のハードルが下げられるように、利用ガイドを用意するとともに、管理画面も直感的に使えるような設計に

ユーザーリサーチ

次に、現状のQRコードオーダーシステムの問題や、飲食店内のオペレーションに関するペインや潜在的なニーズを把握するため、探索型の定性調査としてユーザーインタビューを行いました。 まずは、利用客と店舗運営者に分け、それぞれのペインを整理。

QRオーダーに関するペインの一覧（一覧性・視認性・フィードバック・誤操作など）

次に、ペインをグループ分けし、それぞれのペインをゲインに変換。

ペインをゲインへ置き換えたマッピング図

コア価値の定義

ここまでのリサーチをもとに、サービスの方向性を定めるため、このサービスが実現するコア価値を定めました。 コア価値は、QRコードオーダーを主軸に、注文、キッチン、提供、会計など飲食店のオペレーション全体を効率化・自動化し、誰にとってもスムーズでストレスのない体験を実現することです。

SmartOrdee のコア価値：注文〜提供〜会計までの効率化とストレスのない体験

ペルソナ設計

次に、ユーザーの解像度深め、必要な機能の優先度やユーザー体験のシナリオを作成するため、ペルソナの設計を行いました。

来店客のペルソナ（ニーズ・行動特性の要約）
店舗運営者のペルソナ（業務課題・要望の要約）

カスタマージャーニー（CJ）の作成

次に、ユーザーの行動や感情を時系列で整理し、どの場面に課題や改善の余地があるかを可視化するためにCJを作成しました。 これは、全体の体験を俯瞰することで、どのポイントに注力すべきかを判断し、より効果的な設計や改善に活かすことを目的としています。

来店客のカスタマージャーニーマップ（来店〜注文〜会計の時系列）
店舗運営者のカスタマージャーニーマップ（受注〜調理〜提供の時系列）

情報設計・要件定義

情報設計と機能要件

これまでのリサーチやCJ等を踏まえ、必要な機能や画面遷移、フローについて整理しました。 なお、ここではOOUIの手法を用いて、想定タスクの洗い出し→名刺抽出→メインオブジェクトの抽出→オブジェクト間の参照関係を整理→ビュー・コレクションの遷移関係→レイアウト作成という手順で進めました。

OOUIに基づくタスク抽出
OOUIに基づくオブジェクト抽出
OOUIに基づく来店客側のメインオブジェクトの関係図
OOUIに基づく店舗運営社側のメインオブジェクトの関係図
来店客側のビューとナビゲーションの構成図

＊店舗運営者側のビューとナビゲーションは検証・改善フェーズで大きく変更することになりました

店舗運営者側のビューとナビゲーションの構成図

非機能要件

また、ここまでのリサーチから得られたペイン、ゲインから非機能要件を整理。

  • 操作性の向上のため、ボタンのタップエリアで44px×44px以上を確保
  • 誤タップ防止のため、タップエリア間は16px以上離す
  • アイコンボタンには必ず日本語のラベルを付与
  • 視認性確保のため、最小フォントサイズは12px
  • 商品一覧の一覧性の向上
  • 商品を探すのに階層の深さは最小限に
  • 商品選択から注文までを最小ステップで実現
  • 重要な操作（削除、注文確定等）には、トーストによるインタラクションを入れる

ワイヤフレーム・プロトタイプ作成

情報設計や要件定義をもとに、各画面のレイアウトや要素配置、導線、構造を視覚化。 ワイヤフレーム・プロトタイプ作成後は、タスク達成性、情報構造の妥当性、導線・フローの明確さを検証し、ブラッシュアップを行いました。

来店客側UIワイヤフレーム

UI設計

配色

全体の配色は、プライマリーカラー（#A52A2A）とニュートラルカラーを基軸に設計しました。 プライマリーカラーにワインレッドを選定した理由は、飲食店での利用シーンを考慮し、食欲を損なわず、かつアプリケーションとしてモダンで洗練された印象を与える色として、赤系の中でも深みのある色味を選んだため。 その他の色は、プライマリーカラーに調和するようにプライマリーカラーの階調から選定し、背景やステートカラー（ホバー・無効など）に使用。 また、サクセス（成功）系にはグリーン系、警告にはイエロー系、危険を示す際にはレッド系を用い、各パーツでWCAG基準のコントラスト比を満たすよう配慮した設計をしました。

SmartOrdeeカラーパレット

タイポグラフィー

飲食店向けに幅広いシーン（居酒屋・カフェ・レストランなど）での利用を想定し、過度なブランドイメージを押し出さず、視認性と可読性に優れた標準的な書体であるNoto Sans JPを採用しました。 フォントサイズは16pxを基準とし、原則4の倍数単位でスケールを構成（例外的に14pxは使用を認める）。最小フォントサイズは視認性確保のため12pxとする。 行間（line-height）は可読性を重視し、1.5〜1.75の範囲で設定。さらに、各フォントサイズに対して、line-height適用後のテキストの高さが4の倍数になるよう個別に調整。 文字間隔（letter-spacing）は、可読性向上のため0.02em程度を基本とする。 また、ディスクレシアへの配慮として、両端揃えは使用せず、左揃え、または、中央揃えを基本としました。

レイアウト等

来店客用のUIでは、情報の優先順位を明確にし、視線の流れを妨げないように、縦スクロール前提の単一カラムレイアウトを採用。商品情報は、商品名・価格・操作ボタンを一つのブロック内にまとめ、視線が自然に「見る→選ぶ→操作する」流れになるよう配置しました。

また、操作ミスを防ぐため、タップエリアは44px×44px以上、ボタンの間隔は16px以上離すことで、タップしやすさと誤操作防止を両立しました。

加えて、グローバルナビゲーションは画面下部に固定表示し、ユーザーがどの画面にいてもカート・メニュー・注文履歴にアクセスできるようにしている。 さらに、ページ上部にはカテゴリ名や戻るボタンを配置し、現在の位置や戻る経路を直感的に理解できる設計に。

そして、重要なアクションである「注文確定」や「メニューに戻る」などのボタンは、画面下部に目立つ色と十分なスペースで配置し、ユーザーが次に進むべき行動を迷わず選択できるようにしています。

検証・改善

ハイファイのUIが完成したら、プロトタイプを作成し、それをもとに検証型のリサーチを行ないました。 具体的には、何人かの人に、プロトタイプを利用してもらい、その感想や課題等を聞き取りしました。

来店客側：

  • 「一覧性は高いが、情報が詰まりすぎていてちょっと窮屈な印象があった」
  • 「表示切替ボタンがなんの表示を切り替えるのかよくわからなくて困惑した」
  • 「直感的で使い方はわかりやすいけど、ちょっと事務的な印象。軽やかで洗練された印象だともっといいかも」
  • 「影やボーダーが多くてやや重たい印象がある」
  • 「商品を選択してから注文確定までの流れが悪い。誤操作はしにくいけど、テンポよく注文できない」

店舗運営者側：

  • 「注文管理ページ（キッチンモニター）の状態管理（調理前、調理後、提供済み）がページ遷移が多くて少し手間。各状態へのページ遷移をワンクリックでできた方が便利」
  • 「テーブルが多くなると、スクロール時のヘッダー固定やフィルターUIの再考が必要」
  • 「呼び出し通知は通知だけだと見落とすので、対応済みと未対応のステータスで分けて一覧で見れるページが欲しい」
  • 「スマホ操作が苦手な人やトラブル時のため、スタッフの端末から各テーブルの注文ができるようにしたい」

また、自身でも全体を俯瞰しながら新たな課題や改善点を洗い出しました。 その結果、大きな課題や改善点としては、以下のものが挙がりました。

  • 商品選択から注文確定までの操作フローのテンポが悪い
  • タスク指向のUIになっている部分があり、よりモードレスなUIに改善する余地がある
  • コンポーネントのバリアントとバリアブル（特に色の変数）の肥大化
  • ビジュアル面で業務的かつクラシックなUIという印象が強いこと

1. 注文確定までのフローの最適化に関して

現状のUIでは「商品選択」→「個数選択」→「カートに追加」→「注文の確定」または「カートに追加して注文を続行」というフローを採用していましたが、 特に「カートに追加」以降の操作が、注文のテンポを悪くする原因となっていることがユーザーリサーチや検証を通じて判明しました。

当初このフローを採用した背景には、誤操作による注文確定を防ぐ目的がありました。 ターゲットユーザーの中にはデジタル操作に不慣れな方もいるため、カート機能や確認画面を挟むことで、一度立ち止まって内容を確認できるようにしていました。 しかしその一方で、実際の飲食店利用では、ECサイトのように商品をまとめ買いするケースは少なく、注文操作を分割することでかえってスムーズさを損ねている課題がありました。

そこで、誤操作防止と操作のスムーズさを両立させるため、画面遷移を極力減らす方針とし、カート機能を廃止。 商品ごとに直接注文を確定できるフローへと変更しました。さらに誤操作対策として、商品選択時には注文確定ボタンを非活性（Disable）に設定し、商品個数が1つ以上に設定されたタイミングでボタンを活性化する仕様に変更。 デフォルトでは個数を0にすることで、ユーザーが意図的に操作を行わない限り誤って注文が確定しないよう配慮しました。 この改善により、誤操作のリスクを抑えつつ、注文操作のテンポを向上させることができました。

注文フロー改善後のUI（カート廃止・商品ごとに直接確定、数量1以上でボタン活性）

2. タスク指向UIの改善

全体的にタスク指向で設計されていた箇所が散見されたため、情報設計を見直しました。 具体的には、OOUIの手法を用いてメインオブジェクトを定義し直し、オブジェクト間の参照関係を再整理しました。

さらに、カスタマージャーニーからユーザーの操作フローやタッチポイントを深堀りし、関連性の高い情報や機能は同一ページ内でタブ切り替えができるようにするなど、階層構造を整理。 これにより、不要なページ遷移を削減し、ユーザーがスムーズに目的を達成できる情報構造へと再設計しました。

以下は改善したページの一部

タスク指向UIの改善例

3. コンポーネント・バリアブルの肥大化の改善

コンポーネントおよびバリアブルの肥大化が課題となっていたため、それぞれ改善を行いました。 まずコンポーネントについては、サイズバリエーションを細かく作り過ぎたことで、管理が煩雑になり、一貫性や再利用性が低下していました。 そこで、サイズ展開を基本的に sm / md / lg の三種類に統一し、横幅については実装面と同様に最大幅を定義した上で、 画面幅に応じて柔軟に可変するよう調整しました。これによりコンポーネント管理の負荷を軽減し、運用性を高めました。

また、バリアブル（特にカラー）については、各要素ごとに細かく役割ベースでバリアブルを定義し過ぎたことで、 同じ色を使用しているにも関わらず別名で複数のバリアブルが存在し、全体が肥大化してしまっていました。 例えば、Primary/Btn/Text, Primary/Btn/Background, Primary/Btn/Background/Hoverといったように、同色でも役割ごとにバリアブルを分けていました。 この課題に対して、命名を汎用的かつ再利用しやすい形に見直しました。 例えば、Text/Default, Text/Subtle, Text/Inverseなどのように、抽象度の高いバリアブルに統合する方針に変更しました。 これによって、バリアブルの数を抑えながらも役割に応じた使い分けが可能となり、運用の効率化とメンテナンス性の向上を実現しました。

セマンティックカラーの一覧

セマンティックカラーのバリアブル一覧

4. モダンなUIへの改善

改善前のUIは業務的でクラシックな印象が強く、機能や情報設計には注力していたものの、ビジュアル面の検討が不十分でした。 機能的には問題がなくても、ユーザーは視覚的に美しいUIの方が使いやすいと感じることが多く、美的ユーザビリティの観点からも改善の必要性を感じていました。 そこで、モダンなUIへの刷新を目指し、同業他社のUIだけでなく、他業種の優れたUIも参考に分析を行いました。 その上で、色使いや余白、フォント選定、各パーツのデザインやレイアウトなどを見直し、現代的で洗練されたデザインへと改善しました。

モダンなUIへの改善例1 注文フロー
モダンなUIへの改善例2 売上レポートページ

工夫した点と反省点

以上のような流れで設計を進めましたが、実際の制作を通して特に意識した工夫や、振り返って見えた課題もありました。 ここでは、制作における工夫した点と今後の課題についてまとめています。

工夫した点

第一に、本制作では、デザインの一貫性を保つため、カラーやタイポグラフィー、スペーシングなどを変数管理し、コンポーネント単位で整理する簡易的なデザインシステムを構築しました。 また、UI設計においてもデザイン原則を意識し、再利用性や保守性を高める工夫を行っています。 ただし、今回はポートフォリオ制作という前提もあり、Reactなどフロントエンド実装との連携までは想定していません。

第二に、実際の業界構造や利用シーンを深く理解するため、事前に業界分析・競合分析・ユーザーインタビューなどの探索型リサーチを実施。 ユーザーの顕在的な課題だけでなく、日常的な業務に埋もれた潜在的なニーズまで洗い出し、それらを踏まえてUIに落とし込む設計を行いました。 制作後もプロトタイプを用いた検証型のユーザーテストを実施し、実際の操作感や理解のしやすさを確認。 仮説と検証を往復させながら、実際の現場でも使えるレベルのプロダクトを目指しました。デザインは見た目だけでなく、ユーザーの業務効率・認知負荷の軽減といった実用性を重視し、課題解決に直結する形で構築しています。

反省点

今回の制作を振り返る中で、特に二つの課題を感じています。

一つ目は、実装制約の考慮が不十分だった点です。 実務でのプロダクト開発であれば、エンジニアとコミュニケーションを取りながら、技術的な実装制約やデータベース設計との兼ね合いを考慮した上で設計を行う必要がありますが、今回の制作では、その部分まで踏み込んだ検討がやや不足していたと感じています。

二つ目は、UXリサーチの進め方における課題です。 今回は主に定性的なリサーチに留まり、ユーザーインタビューの母数も限られていました。 実務開発であれば、定量的なデータを活用した検証や、より多くのユーザーを対象にした調査、バイアスを避けるためのサンプル設計、さらには定性調査の手法の多様化など、より精度の高いリサーチを行う必要があると考えています。 こうした点を次の課題として捉え、今後はより実践的で精度の高いUX設計を目指したいと思います。

SmartOrdeeのFigmaファイルはこちら

飲食店向けSass型オーダー管理システム「SmartOrdee」