飲食店の QR メニューの作り方を順番に

何かを生成する前に用意しておくもの

失敗する QR メニューのほとんどは、コードが間違っていたからではなく、遷移先が準備できていなかったから失敗します。ジェネレーターを開く前に、遷移先を確定し、実機で見ておいてください。

必要なものは四つで、どれも時間はかかりません。

• メニュー本体。ウェブページか PDF として、ログインを必要としない公開 URL にすでに掲載されていること。
• コードにブランドを載せるつもりなら、背景が透明な PNG か SVG のロゴ。
• 誰が価格を更新するのか、そして変更が反映されたことをどう確認するのかという取り決め。
• テスト用の、自分のものではない端末。自分の端末はページをキャッシュしていて、読み込み速度について嘘をつきます。

PDF かモバイルページか：何が変わるかで選ぶ

PDF のほうが早く公開できます。メニューがすでにデザイン済みの PDF として存在するなら十分で公開でき、内容が少なく安定したメニューならそれは十分に妥当な答えです。

ただし端末上で代償を払います。PDF はブラウザではなくビューアで開き、ページが設計されたサイズのまま表示され、価格を読むために客はピンチして拡大し、ドラッグすることになります。8 ポイントで組まれたアレルゲン表示は、テーブルで腕を伸ばした距離では読めません。

メニューに構造がある時点で、モバイルページのほうが良い答えになります。客が行き来したいカテゴリ、絞り込みたいアレルゲン、売り切れる料理、昼だけの特典。しかもきちんと計測できるのはこちらだけです。ページはどのセクションが開かれたかを教えてくれますが、PDF は教えてくれません。

実用的な目安：メニューが月に二回以上変わるなら、あるいは客が検索したくなる可能性があるなら、ページを作ってください。そうでなければ PDF で十分ですし、印刷済みのコードに一切触れずに後からページへ移せます——それが次の判断です。

飲食店のメニューコードは必ず動的にする

静的 QR コードは遷移先をマトリックスそのものの中に持ちます。永久に機能し、背後にサービスを必要とせず、そして決して変更できません。テーブルカードに刷られた時点で、その URL がその URL です。

動的 QR コードは代わりに短い転送用アドレスを持ち、その背後の遷移先は編集できる設定です。印刷されたコードは変わりません。変わるのは、それがどこに着地するかです。

飲食店にとって、これは接戦ですらありません。メニューは変わります。少なくとも季節ごとに、実際には仕入れが崩れたり価格が動いたりするたびに。静的コードは、価格を一つ変えたその日にテーブルカード、窓のステッカー、テイクアウトのスリーブをすべて刷り直す義務を負わせます。動的ならそれは一度の編集で済みます。

静的コードの唯一の本当の利点——何にも依存しないこと——は Wi-Fi パスワードや連絡先データには意味がありますが、そもそも自社サイトが動いていることに依存しているメニューには意味がありません。

コードを生成し、壊さずにブランドを載せる

コードを作り、遷移先に向け、そして自分が何を変えているのか分かっていない限り技術的な設定には触れないでください。既定値は読み取れるように選ばれています。

メニューが最も傷むのはブランドを載せる工程です。この工程が純粋に装飾的に見えるからです。知っておく価値のある制約が三つあります。ロゴと色について読むことになるあらゆる規則は、ここから導かれます。

• 誤り訂正。QR コードは一部が隠れても読めるよう冗長なデータを持ちます。各レベルはマトリックスのおよそ 7%、15%、25%、30% を復元します。ロゴはその余力の内側に収まることで機能します。レベルが許す以上を覆うと、コードは緩やかに劣化するのではなく、読めなくなります。
• クワイエットゾーン。規格は四辺すべてに 4 モジュール分の余白を要求します。デザイナーは決まってこれを断ち切ります。空きスペースに見えるからです。そうではありません。読み取り機がコードの端を見つける手段です。
• 正しい向きのコントラスト。明るい地に暗いコード。暗い地に明るいコードは一部の端末でしか読めず、メニューはどの端末がそうなのかを確かめる場としては最悪です。

「スキャンしてください」ではなく、行動喚起を書く

「スキャンしてください」は客に手の動かし方を伝えるだけで、なぜかについては何も言いません。コードの隣の文字だけが「自分は何を得るのか」に答えるもので、それはどんなデザインの選択よりもスキャン率を左右します。

何が開くのかを言ってください。「メニューを開く」「ドリンクリストを見る」「アレルゲンを確認する」「席から注文する」。コードが予想外の場所へ行くなら——料理ではなくワインリストなら——そう書いてください。望まない場所に着いた客は、二つ目のコードをスキャンしません。

店にいる人の言葉で書いてください。海外からの客が常にいる店では、コードの隣に二言語を置くのは、その場所を使う価値があります。

サイズと位置：読まれる距離に合わせて刷る

一般的な目安は、コードの一辺がスキャンされる距離のおよそ十分の一だということです。腕を伸ばした距離——およそ 30 センチ——で読むテーブルカードなら 3 センチ前後。2 メートル離れて読む窓のステッカーなら 20 センチ前後で、これは多くの人の想定よりはるかに大きく、窓のコードがスキャンされないまま終わる最大の単独要因です。

これは出発点であって仕様ではありません。遷移先の URL が長いほど同じ正方形に多くのモジュールが詰まり、一つひとつが小さくなり、同じ物理サイズでも読みにくくなります——これも動的コードを支持する静かな論拠です。転送用アドレスは構造上短いからです。

位置はサイズと同じくらい重要です。コードがテーブルで失敗するのは、ラミネート面や天井の照明による反射のせい、調味料立てがマトリックスの半分を隠しているせい、あるいはカードが客ではなく通路を向いているせいです。自分の席に座って、そこから見てください。

掲出場所ごとに別のコードを使う

コードを一つ作ってすべてに刷りたくなります。やめてください。掲出の種類ごとに一つ作ります——テーブル、窓、カウンター、テイクアウトの包装、レシート——すべて同じメニューを指して構いません。

費用はかからず、そして数字に意味を持たせる唯一の方法です。コードが一つなら、スキャンが起きたことしか分かりません。五つあれば、窓のステッカーは何もしていない、テイクアウトのスリーブが流入の三分の一を稼いでいる、ドリンクリストは午前十一時に開かれている——そのどれもがあなたが動ける判断材料です。

店舗が複数あるなら店舗でも分けてください。同じ掲出場所を二つの店で比べることは、問題がメニューではなく店舗の側にあると突き止める最短の方法です。

印刷後に価格や料理を変える

これが動的コードで得たものであり、営業中に場当たり的にやるのではなく、実際の手順を決めておく価値があります。

まず遷移先を更新し——ページか、差し替える PDF か——何かをそこへ向ける前に端末で確認します。それからコードの行き先を変え、実際のテーブルから実際の印刷済みコードをスキャンして確かめます。画面上のプレビューではなく、印刷されたほうを。店に実際にあるコードが思ったところに着地すると証明できるのは、それだけだからです。

可能なら営業時間外に切り替えてください。更新の最中にスキャンした客は壊れたページと説明のなさを受け取り、二度目は試しません。

実際に判断につながるものを測る

総スキャン数はダッシュボードで最も役に立たない数字であり、誰もが報告する数字です。忙しければ増えます。それが伝えるのはそれだけです。

あなたの行動を変える数字は比較的なものです。ユニークと総スキャンの対比は、人々がメニューを開き直しているかを教えます。比率が穏やかなら関心、一人の客が一回の食事で六回開いているならナビゲーションの失敗として読めます。掲出場所別のスキャンは、どの印刷物がその場所に見合っているかを教えます。時間帯別のスキャンは、昼の特典が昼に見られているかを教えます。

分かりやすい罠に注意してください。自店のスタッフがコードを試すと初期の数字は膨らみ、忙しい土曜日はすべてが上手くいったように見せます。同種どうしで比べてください——今週の火曜と先週の火曜、このテーブルカードとあの窓のステッカー。

印刷に回す前に確認すること

以下はどれも実際のメニューを壊したことがあります。通しで十分ほど、刷り直しよりはるかに安く済みます。

• 画面からではなく印刷校正からスキャンする——画面上のスキャンはコントラストとサイズの問題を完全に隠します。
• 少なくとも Android 一台と iPhone 一台で、可能なら古い端末でもテストする。
• 夜間を含め、店の実際の照明でテストする。
• ノートパソコンではなく端末で遷移先を確認する。タップ領域、読み込み時間、拡大せずに価格が読めるか。
• クワイエットゾーンが最終レイアウトで残っていること、コードの上に何も刷られていないことを確認する。
• 遷移先が公開されて到達可能であることを確認する——下書きでなく、ログインの後ろでなく、期限切れになるファイルでもなく。
• 行動喚起が何が開くかを述べていること、そして座った位置から読めることを確認する。