文章で合意できていても、担当者ごとに思い浮かべる操作は違います。SQairは長い仕様書を先に完成させず、業務フローを整理したあと、早い段階で画面にして認識の差を表へ出します。
画面を描く前に、
目的と現在の仕事を聞く。
最初に「欲しい画面」を聞くだけではありません。誰が使うか、今はどのファイルやシステムを見ているか、何を判断したいか、次の担当へ何を渡すかを確認します。二重入力、確認待ち、電話でしか分からないルールも拾います。
例えば「進捗一覧が欲しい」という相談なら、一覧を見る目的が遅延発見なのか、担当者の割り振りなのか、顧客への報告なのかで必要な項目は変わります。目的を一文にできてから、最初の画面へ進みます。
最短約2日で作るのは、
完成デザインではない。
初回相談、業務フロー整理、主要画面のワイヤーフレーム作成までを短く回します。色、細かな余白、すべての設定画面まで仕上げるのではなく、情報の優先順位と操作の順序が議論できる粒度に絞ります。
2日という速さは納期の約束ではなく、認識合わせを始めるまでの目安です。案件状況や複雑さによって変わります。
ボタンが見えると、
言葉になっていない条件が出る。
画面に入力項目、一覧、操作ボタンを置くと、「この担当者には金額を見せない」「承認前は確定できない」「同じ時間に予約が重なってはいけない」といった例外が具体的になります。
確認するのは通常時だけではありません。データが0件のとき、入力が不正なとき、外部サービスが停止したとき、処理途中で画面を閉じたとき、権限がないときも考えます。後から見つかるほどデータ構造や連携処理への影響が大きくなる条件を、実装前に集めます。
好みを聞くのではなく、
次の判断ができるかを確かめる。
レビューでは「この見た目が好きですか」だけを聞きません。この情報で担当者は判断できるか、重要な状態を見落とさないか、次に押すボタンが分かるか、誤操作から戻れるかを確認します。
早く作るのは、早く正解するためではなく、修正コストが小さいうちに間違いを見つけるため。
画面を見ながら出た質問は、その場の会話で終わらせず、仕様、保留事項、顧客側の確認事項へ分けて残します。変更理由まで記録すると、後の機能追加でも判断を再利用できます。
画面が決まってから、
動作とデータを仕様にする。
画面案で方向がそろったら、項目定義、権限、入力チェック、更新先、通知、外部連携、エラー処理、受入テストの条件を詰めます。画面だけ先行して中身が曖昧なまま実装へ渡すことはしません。
この方法は、完成した仕様書を用意できない企業ほど効果があります。「こうしたい」という業務の言葉から始め、見えるものを介してシステムの言葉へ変えていきます。