#4 画面設計をしてみる

投稿者: | 2021年2月1日

今回は、これまでに検討2パターンのうち飲食店のパターンで、画面設計をしていきます。

画面設計は開発工程でいえば基本設計や外部設計といわれる工程です。ここはユーザ側(=運用側)と、開発側の境目にある工程ですから、どちらにも影響が出ます。じっくりやっていきましょう。

受付には、場所には棚のようなものを設置します。イメージをつかむために、アマゾンで「こういうやつ」というものを探してみました。

申込者向けの機能

棚の上には、申込者向けの端末を1台、2段目はスタッフ向けの端末を配置しておきます。

申込者端末で使う機能は2つです。1つはウェイティングリストに書き込む内容を同じものを登録します。

登録機能

受付で人目のある立ったままの状況、普段使わない端末でキーボード入力は敷居が高いので、選ばせます。大人や子供の人数は1~4人程度までと5人以上の中から選べるようにしておきます。数値で入力させるのは利便性が下がるのでさせません。

機能は主に2つしかないので、もう1つの機能に切り替えるボタンが1つと登録ボタンが1つです。

登録した後は番号が表示されます。そして、印刷ボタンを配置しておきます。印刷ボタンを押すとブラウザの印刷プレビューが起動し、印刷できるようにします。携帯できる小さいサーマルプリンタ(ワイヤレス)に出力するとそれらしいですね。サーマルプリンタにしたほうが良いのは、通常のインクジェットプリンタの場合はインクの維持と紙の維持の両方が必要だからです。A4、B5などの業務用用紙であればよいですが、そのような大きい紙を申込者に配布するのもなんだかおかしな話です。

そこで紙こそ専用ですが、用紙を維持しておけばよいサーマルプリンタにしておきます。例えば下記のような製品があるようです。

QRをつけておき、このアドレスからウェイティングリストを見れるようにしておきます。午後に来店した人にとって、午前中にチェック済の人がリストに表示されているのは邪魔でしかありませんので、非表示にします。

店舗内の申込者端末からは常にこの一覧が見えてもよいですが、QRコード経由からアクセスしたときには注意が必要です。まがりなりにも名前が載っていますし、外から店舗の状況がむやみにわかるというのもよろしくありません。

チェック済になったらもう見れないようにすることと、自分よりも後ろの状況は必要がないので見せません。

店舗スタッフのチェック

店舗スタッフは受付の棚の中に隠し(?)てある端末から、ウェイティングリストを確認し、チェック済に更新します。一応、テーブルを選択してチェックします。

念のため、間違えてチェックにしてしまった場合は、チェック済非表示を外した後、対象選択して未チェックに戻すこともできるように考えておきます。えてして間違えるものなので、最初から設計しておきます。

また、さらに細かいことですが、日付が切り替わるタイミングが面倒なので、2日分を検索できるようにしてあります。

3つの機能だけで、ウェイティングリストを店舗の外でも限定的に確認できる仕組みが出来上がりました。

事前にメールアドレスや電話番号などを入力してユーザ登録を必須にすれば、登録機能を店舗内に限定せずに公開できる余地もあるかもしれません。

バックオフィスな機能

申込者や店舗スタッフの使う機能(=フロントオフィス)としては上記のみでしたが、バックオフィス系ともいわれる、マスタ関係の機能や各種レポート機能がまだ存在します。

マスタ機能には、ウェイティングリストの定義と、リソースの定義をします。レポート機能は今後検討しましょう。レポート機能を検討すると、ほかにも必要なマスタが増えそうです。

レポート機能は見せ方によってはテーブルの設計に大きなインパクトを与えるため、大規模なシステムでは初めに手を付けたほうが良いです。今回は規模も小さいので、作り直しになっても対応できる範囲内ですから後にすることにします。

次回

今回の画面設計を通して考えていましたが、検討していたもう1つのパターン(=携帯ショップの例)では、機能単位で足りていない部分、同じ機能でも足りていない項目などがありそうです。

以前書いたように、携帯ショップの待ちでは担当者という概念も存在し、待ち時間に大きな影響を及ぼすためです。

しかし、今回の検討で最小限の画面設計ができました。次回以降では、さっそくRailsでプロジェクトを作り、モデルの作成などから着手しましょう。

また、次回冒頭で今後のマイルストーンも書いておきます。