開発日誌をはじめる。まずは毎日いちばん見ている画面の話

開発日誌をはじめることにした。デリヘル管理アプリを作りはじめて、気づけば機能がずいぶん増えた。 自分でも「そういえばこれ、いつ作ったんだっけ」という画面があるくらいなので、 1日1つずつ、既にある機能を紹介しながら振り返っていこうと思う。

初回は迷わずこれ。オペレーターの受付画面。このシステムの中でいちばん長い時間、誰かに見られている画面だ。

オペレーターの受付画面。左に着信・検索と予約フォーム、右にキャスト候補の一覧とキャスト・ドライバーの位置マップが並ぶ
左が受付フォーム、右がキャスト候補と位置マップ。画面はデモデータです。

電話を取ってから予約確定まで、画面を移動しない

この画面の設計方針はひとつだけで、「通話中に画面を切り替えさせない」。 電話口のお客様を待たせられるのはせいぜい数秒で、その間に 「この子は今日出勤してるか」「その時間に空いてるか」「ホテルまでいくらか」に答えないといけない。 タブを行き来している暇はない。

だから着信が鳴った瞬間に、左のフォームには発信者の電話番号が自動で入る。過去に利用のあるお客様なら名前も入る。 右のキャスト候補には、選んだコース・場所に対して「誰が案内できて、いくらで、何時に着けるか」が並ぶ。 移動時間は実際の道路の経路計算で出しているので、「30分後に伺えます」が口から出まかせにならない。

「満員御礼」バッジの話

スクショのキャスト候補に黄色い「満員御礼」というバッジが見えると思う。 これはその子の当日の枠が予約で埋まっている印で、最初は単に行を非表示にしていた。 でもテスト運用で「あの子、今日出てないの?」という電話に答えられなくて困った。 いない子と、いるけど埋まってる子は、電話応対ではぜんぜん違う。 埋まってる子は「本日は予約でいっぱいでして、明日でしたら」と切り返せる。 で、消すのをやめてバッジにした。地味な変更だけど、応対の質はこういう細部で決まる気がしている。

下書きを消した回数がいちばん多い画面

正直に書くと、この画面はいちばん作り直した回数が多い。 情報を詰めすぎて何も読めなくなった版、逆にすっきりさせすぎて結局別画面を開くことになった版。 いま落ち着いているのは「上に急ぎのアラート、左に入力、右に判断材料」という配置で、 これは実際にインカムをつけて受付をやってみた結果でもある。 視線が左右に往復するだけで済むと、通話しながらでも手が止まらない。

明日は、この画面に電話がかかってくる前の話——電話まわりの機能について書く予定。