住宅アプリは「送った後」まで設計する――施主が迷わない画面と運用
住宅アプリで「点検を依頼する」を押したのに、送信できたか分からない。施主は結局、電話で確認することになる。受付フォームを用意するだけでは、この二度手間はなくならない。依頼が届いたことに加え、次に誰が対応し、いつ連絡が来るのかまで分かって、ようやく安心してアプリを閉じられる。
住宅会社がアプリで目指したいのは、機能の数を増やすことではない。検討中の相談から設計・施工、引渡し、入居後の対応まで、施主が必要な情報や担当者に迷わずたどり着けることだ。とはいえ、すべての接点を一つのアプリに集める必要もない。各段階の不安や手間を確かめ、アプリが役立つ場面を選びたい。
機能一覧より先に「利用場面」を決める
住まいに関する用事は、毎日あるわけではない。施主がアプリを開くのは、打ち合わせ前に資料を見る、仕様変更に返事をする、設備の説明書を探すといった、目的がはっきりしたときが多い。利用頻度を上げること自体を目標にすると、不要な通知や機能が増えてしまう。
まず、施主と住宅会社の行動を時系列で並べ、「施主が知りたいこと」「会社側で確認・判断が必要なこと」「連絡が途切れやすい箇所」を書き出す。設計打ち合わせ後なら、施主が知りたいのは資料の保管場所だけではない。変更案のうち何を決める必要があり、返答期限はいつか。一方、会社側には届いた回答を設計担当へ引き継ぐ工程がある。
こうして整理すると、アプリに置くべき接点が見えてくる。
- 確認したい：最新版の資料、決定済みの内容、次回予定を見つけられる
- 返答したい：判断に必要な情報を読んでから、回答や質問を送れる
- 頼みたい：点検・修理の相談を送り、受付後の状況を確認できる
ただし、緊急の漏水や停電は別だ。即時の判断が必要な場面で、フォーム入力を最初の手段にしない方がよい。アプリには緊急連絡先と対応時間を明示し、通常の問い合わせとは経路を分けておく。
施主の言葉で情報を並べる
社内では「案件」「工程」「是正」「竣工図」で分類できても、施主がその言葉で探すとは限らない。画面の入口には「打ち合わせ内容」「工事の予定」「住まいの書類」「困ったとき」など、用事から選べる名称を使う。書類名に内部用語が残るなら、短い説明を添えたい。
トップ画面も、情報をすべて並べるより、いま行動が必要なものを先に示す。「確認待ちの変更案が１件」「次回点検は６月」のように、状態と次の行動が分かる表示が役立つ。日程がまだ決まっていないなら、「担当者が調整中」と示し、確定した予定と混同させない。
資料には「どれが有効か」を示す
図面や見積書を開けても、似た名前のファイルが複数あれば、どれを見ればよいか迷う。資料には版、更新日、対象範囲、確認が必要かどうかを付ける。古い版を残す場合は履歴として扱い、通常の画面では有効な版を優先する。回答画面にも、対象となる資料名と版を表示しておきたい。
これは画面だけでは解決しない。担当者が新版を登録したとき、旧版をどう扱うかも決めておく必要がある。小規模な会社で情報の置き場所から整理するなら、小規模工務店のクラウド導入で費用と情報共有を整理する考え方も参考になる。
「送った後」の体験を業務と一緒に設計する
使い勝手の差が出るのは、施主が操作した後だ。修理依頼なら、完了画面に受付番号を出すだけでなく、「受付済み」「内容確認中」「訪問日調整中」「対応完了」といった状態を、実際の業務に合わせて見せる。ただ、社内で更新されない表示はかえって不信感を招く。最初は区分を少なくし、誰がいつ更新するかを決めておく方がよい。
返信の速さを保証できなくても、次の連絡の目安や営業時間外の扱いは伝えられる。たとえば「次の営業日までに連絡します」と表示するなら、休日や担当者不在のときも守れる体制が必要だ。受付通知の文面と社内の通知先は、画面と一緒に確認する。
通知は量より判断しやすさ
工事写真の追加、資料の更新、回答期限、点検日程の確定。これらを同じ強さで通知すると、重要な連絡が埋もれる。「対応が必要」「予定が決まった」「後で確認できる」と優先度を分け、件名を見れば内容と必要な行動が分かるようにする。施主がアプリを開けない場合に備え、どんな連絡で別の手段を併用するかも決めておきたい。
家族・担当者の役割を画面に反映する
住まいの意思決定には家族が関わることが多い。ただし、全員に同じ操作を認めるとは限らない。資料は家族で閲覧できるようにし、仕様変更の承認は契約上の確認者に限る、といった分け方がある。承認画面では対象に加え、費用や日程への影響、取り消しや修正の連絡方法を示し、単なる「確認」ボタンとは区別する。
会社側も、営業、設計、現場、アフター担当で扱う情報が違う。施主の質問を受ける窓口は一つでも、社内では内容に応じて担当へ渡せるようにする。担当者が交代するたびに施主が同じ説明をする事態を避けるには、やり取りの履歴に結論と未対応事項を残せる構造がほしい。
試作では「使えたか」だけでなく迷い方を見る
開発前の画面案は、実際の利用者に具体的な用事を頼んで確かめる。「資料を探してください」より、「前回の打ち合わせで変更した窓の位置を、最新版の図面で確認してください」の方が、目的の情報にたどり着けるかを見やすい。点検依頼なら、不具合の場所を選び、写真を添えて送信し、その後の状態を確認するところまで試す。
記録したいのは完了までの時間だけではない。どの言葉で立ち止まったか、戻る操作を繰り返したか、送信できたと確信できたかも見る。年齢やスマートフォンへの慣れだけで利用者を決めつけず、住宅づくりの段階や家族内での役割が異なる人にも試してもらう。
文字の大きさやボタンの押しやすさ、読み上げ時に意味が通る項目名も確認する。通信が不安定なときの表示も見落とせない。写真の添付中に通信が切れた場合、入力内容は残るのか、再送できるのか。修理依頼では、こうした挙動が使いやすさを左右する。
段階的に公開し、評価指標を業務につなげる
打ち合わせ、工事共有、IoT操作、アフター対応を最初から一体化すると、開発も運用も複雑になる。まずは資料確認や問い合わせなど、利用場面が明確で担当者も決めやすい範囲で試す。施主と社内の双方にどんな手間が残ったかを確かめてから、対象を広げればよい。
評価するのはダウンロード数だけでなく、施主が用事を終えられたかどうかだ。「有効な図面を見つけられた割合」「依頼の送信後、同じ内容の電話が入った件数」「担当者が回答する前に不足していた情報」などを確認する。問い合わせが減っても、施主が連絡を諦めただけなら改善とはいえない。短い聞き取りや対応履歴と合わせて判断したい。
入居後は、アプリを開く目的も変わる。工事中の通知より、保証書や設備の説明、点検の連絡先が必要になる。引渡しを境に画面の優先順位と通知設定を見直しつつ、施主が必要な履歴は引き続き参照できるようにする。IoT機器の操作を加える場合も、住宅情報の閲覧とは利用頻度が違うかもしれない。入口を混在させすぎない配慮が要る。
公開前には、点検依頼を一件テスト送信してみる。施主画面の受付表示から社内通知、担当者の割り当て、返信後の状態変更まで通して確認する。途中で手入力や口頭連絡が必要なら、その担当者と手順を決めてから本番運用に移したい。
