操作がうまく機能するかを確かめたいときは、洗練された画面よりも粗い画面のほうが、製品設計の道具として優れている場合があります。Deelでは、デザイナーがAIで素早く生成したプロトタイプを使い、要件を固める前にアイデアを検証します。コンセプトの有効性が確認できたら、Deel UIのコンポーネントを使ったコードベースのプロトタイプに移り、細部や例外的なケースを重視します。
画面を磨く前に操作を検証する
初期の取引照合プロジェクトでは、取引を明細の項目に対応付ける方法が課題になりました。取引をドラッグして所定の位置に置くべきか、それとも左右に並んだ固定テーブルで一致する項目を選ぶべきか。デザイナーは、Webアプリケーションを生成するAIツールのLovableで、どちらもクリック操作できる形にしました。初期の画面は素朴な見た目で、Deelの本番環境向けデザインシステムにも準拠していませんでした。
洗練されていないことには意味がありました。画面を作り込むと、肝心の問いに答えが出ていないうちに、色や文字組み、余白に関心が向いてしまう可能性があります。粗い試作なら、一致する項目をどう見つけ、どう確定するかという操作そのものを話し合いやすくなります。社内ユーザーによるテストでは、テーブル方式が支持されました。このケースでは、ドラッグ＆ドロップ方式よりもヒューマンエラーを効果的に減らせたためです。
▲ 取引照合の2つの方法
コンセプトのプロトタイプに要したプロンプト作業は2時間未満でした。クリック可能なプロトタイプにLoomによる約2分間の操作説明を添えると、本格的な製品要求仕様書（PRD）が確定する前に、1～2日で関係者による妥当性の確認を得られました。このタイミングが重要なのは、まだ試作を捨てられるうちに操作方法を変えられ、不確かなアイデアを開発計画に持ち込まずに済むからです。
粗いことは、手を抜くことではありません。チームが検討している判断を実際に試せるだけの動作は必要です。ただ、その最初の問いに答えるために、完成したソフトウェアのような見た目である必要はありません。
課題に合わせて進め方を変える
Deelのすべてのプロジェクトがプロトタイプから始まるわけではありません。提案された解決策を素早く試すところから始まるものもあれば、より複雑な仕事では調査から始めます。AIは調査結果の整理やパターンの探索に役立ちますが、システムを理解し、担当者間で認識を合わせる作業の代わりにはなりません。
資金管理システムの開発では、画面を決める前に、デザイナーがFigJamで関係者、支払いの流れ、会計要件、例外的なケースを整理しました。その図には、提携銀行やAPIに関する制約も記録しました。APIは、ソフトウェア同士が情報をやり取りするためのインターフェースです。支払いの流れでは、画面上の小さな判断に見えても、顧客の支払いが失敗したり、働き手に報酬が支払われなかったりするなど、画面の外に影響が及ぶ可能性があります。
Deelは、インタビューの文字起こしやアンケートなどの調査資料を構造化されたレポートにまとめるため、社内のAIワークフロープラットフォームも使っています。この調査ワークフローでは、問題の背景、入力情報に欠けがないか、翻訳の正確さ、実行に移せる提案があるかを確認します。レポートによって調査結果をまとめる作業は速くなりますが、その結果が製品にとって何を意味するかは、引き続きデザインチームが判断しなければなりません。
検証済みの案をデザインシステムへ
コンセプトをより実際の製品に近い形で試す必要がある場合、デザイナーはDeelのエンジニアリングチームが用意した社内GitHubリポジトリ、Deel UI Playgroundを使います。そこにはDeel UIの設計ルール、依存関係、文書化されたコンポーネントが含まれています。デザイナーは要件、フロー図、コンポーネントのドキュメントをClaude Codeに渡し、操作可能なReactのインターフェースを生成します。Reactは、これらのプロトタイプで画面のコンポーネントを構築するために使うソフトウェアライブラリです。
▲ コードで作った画面の試作
この2段階の違いは重要です。Lovableによるラフな試作では、その操作方法をさらに検討する価値があるか判断できます。Playgroundのプロトタイプでは、エンジニアが使うものに近いコンポーネントや制約の下で、その操作がどう動くかを確認できます。生成されたコードはエンジニアが確認でき、引き継ぎに向けてプルリクエストとして提出することもできます。
Checks Moduleは、この踏み込んだ段階がなぜ役立つかを示しています。そのプロトタイプには、小切手の一覧、ステータスフィルター、小切手作成用のドロワー、CSVによる一括アップロード機能が含まれていました。CSVは「comma-separated values」の略で、表形式のデータを扱うファイル形式です。社内ユーザーはアップロードを試し、銀行口座を編集し、承認や却下をシミュレーションできました。そうしたフローを試すことで、プロバイダーのAPI応答時間や、待機中、郵送済み、換金済み、照合済みといった小切手のステータスなど、連携に関する課題が見えてきました。
コードで作ったプロトタイプも、慎重な確認が必要です。Claude Codeが誤ったコンポーネントやスタイルを生成した場合、デザイナーはStorybookから正確な仕様とコンポーネントのコードを渡せます。Storybookは画面コンポーネントの文書化や確認に使うツールです。Deel UIのルールは生成結果を制約するのに役立ちますが、余白、角丸、文字組みの不一致などの細部は、デザイナーが見つけなければなりません。再現度が高いと、動作するプロトタイプを完成済みのソフトウェアと関係者が誤認する恐れもあるため、その位置付けを明確にしておく必要があります。
会議を待たずに動作をレビューする
Deelのレビューフローでは、動作するプロトタイプへのリンクとLoomによる短い操作説明をSlackのスレッドにまとめます。プロダクトマネージャー、エンジニア、デザイナーは、時差があっても動作を確認してコメントできます。Checks Moduleのレビュースレッドには23人が参加しました。エンジニアは例外的なケース、不足している入力検証ルール、APIの状態を指摘し、AIはコメントを次のコード修正に向けたアクション項目にまとめる作業を支援しました。
この方法なら、静的な画面だけをレビューする場合より具体的なフィードバックを得られます。実際にフローを試し、何が起きるかを指摘できるためです。これですべてのレビューが自動化されるわけでも、課題や要件を見極めるための調査が不要になるわけでもありません。判断がまだ固まっていないうちに、チームで共有して試せる成果物を用意できます。
次のプロトタイプに生かすこと
実務上の教訓は、その時点の問いに答えられる最小限の成果物を選ぶことです。操作方法自体が不確かな場合は、ユーザーの目的をプレーンテキストで記述し、クリック操作できる粗いコンセプトから始めます。支払いやプロバイダーなど、複雑な依存関係をまたぐ作業なら、まずシステムのフローと制約を整理します。コンセプトをより現実に近い形で試す価値が認められたら、文書化されたデザインシステムのコンポーネントで構築し、動作するプロトタイプへのリンクを短い操作説明とともに共有します。
粗い試作は捨てられるものとして扱い、コードで作った試作には修正の余地を残します。見た目を磨くことも、AIでコードを生成することも、それ自体が目的ではありません。何を作るべきかを見極め、実際に作る人たちが検討できる具体的な材料を渡すことが目的です。