FigJamで描くロボットの意思｜物理空間を制御するフロー図の構築
デジタルからロボティクスへの拡張
UIデザイナーがユーザー起点の基本動作を整理する重要性について触れました。本記事ではその基本フローをベースに、ロボティクス特有の変数である物理現象とシステム制約をいかにして仕様へと組み込んでいったのか、その具体的なプロセスを記録します。
私が向き合っているのは、画面の中だけで完結するサービスではありません。実機としてのロボットが物理空間で動くプロダクトだからこそ、デジタルな理想論を超えた泥臭いロジックの構築が不可欠となります。
※本記事は、ロボティクスデザイナーが実務における仮想のフロー図作成のプロセスを振り返り、言語化した思考の記録です。
物理とデジタルを接続するフロー図の重み
ロボティクスにおけるUIデザインは、画面内の遷移を定義するだけでは完結しません。ロボットという物理的な実体が伴う以上、そこには「通信の瞬断」「センサーの誤検知」「物理的なスタック」といった、デジタル完結のサービスでは想定し得ない不確実な状態が無数に存在します。
UIデザイナーがユーザー起点の基本動作を整理する重要性について触れました。基本フローをベースに、ロボティクス特有の変数である物理現象とシステム制約をいかにして仕様へと組み込んでいったのか、具体的なプロセスを記録します。
設計において最も時間を割くのは、これらの「状態（ステート）」を可視化するフロー図の作成です。このフロー図は、単なるユーザー体験の導線ではなく、システムが次に何をすべきかを判断するための仕様そのものであり、PdMやエンジニアとの共通言語となります。
FigJamで機体の都合を可視化する
具体的なフロー図の構築にあたっては、まず以前に定義した「正常・警告・異常」の3軸構造を土台にしました。そこから物理レイヤーの事象をマッピングするために、以下の手順でFigJam上に要素を追加していきました。
ユーザー起点のフローに「システム発火」を並走させる: ユーザーの操作フローのすぐ隣に、機体側がセンサーやシステム状態に基づいて自律的に判断を下す「別系統のフロー」を配置しました。
割り込みゲートの設置: ユーザーが「操作」を行う直前、あるいは操作中のどのタイミングで、機体側の「強制停止」や「自動回避」が入り込む余地があるのかを、判断分岐として視覚化しました。
ロボティクス特有の4つの変数
物理的な制約をロジックへ変換するために、以下の要素をフローの中に具体的に落とし込みました。
システム（機体）起点の割り込みフロー: ユーザーが操作中であっても、ロボットが自律的に障害物を検知した際の強制停止や自動回避の挙動。これを「ユーザーが止めた」のではなく「機体が止まった」という別個のステートとして定義しました。
ハードウェア状態の可視化: 通信のレイテンシ（遅延）やバッテリー残量、ハードウェアの健康状態といった目に見えない制約をUIの状態遷移（ステート）に反映。例えば、遅延が発生している際に「ユーザーに今の操作が届いているか」をどう伝えるか、という仕様を固めました。
環境要因による例外系: 段差、照明環境の変化、周囲の動体など、物理環境によって操作が継続不能になった際のリカバリー設計。環境をソフトウェア側でコントロールできないからこそ、UIによる適切な誘導が安全の鍵となります。
物理的な安全性（Safety）の階層: ソフトウェア上のエラー表示よりも、物理的な緊急停止（E-Stop）が連動する際のインタラクションを最優先事項として定義。情報の優先順位を整理し、緊急時におけるUIの振る舞いを明確にしました。
Gemによる仕様レビューと改善のプロセス
作成したフロー図に対し、AI（Gem）を作業パートナーとして活用し、仕様の網羅性と論理的整合性を検証しました。客観的な視点を入れることで、デザイナー特有の「正常系のバイアス」を排除するのが狙いです。
ステート遷移の漏れに対する指摘
Gemからは、特に「異常系から復帰する際の遷移」について具体的な指摘を受けました。
指摘内容: 障害物検知による強制停止後、障害物が取り除かれた際の「待機状態」への戻り方が定義されていない。
改善: 「自動復帰」か「ユーザーによる再開操作」が必要かを明示し、安全性を担保するための再認証ステップをフローに追加しました。
用語の定義と一貫性の確保
エンジニアとのコミュニケーションロスを防ぐため、フロー図内で使用する用語の統一を行いました。
改善: 「エラー」「アラート」「ワーニング」といった曖昧な表現を排し、機体状態に紐づくステート名（Idle, Moving, Blocked, Fault等）へと定義を更新。これにより、UI上の表示文言と内部ロジックの紐付けを強固にしました。
リアルタイム性の考慮
通信環境が悪化した際の「タイムアウト」の定義についても再検討しました。
改善: 何秒の遅延で「操作不能」とみなすのか、その閾値をフロー図内に注釈として追加。UIが応答待ちを表示すべきタイミングを厳密にルール化しました。
実装において一切の迷いを持たせない
このようにフローを深掘りし、外部の視点でブラッシュアップする目的は、単に複雑な図を作ることではありません。それは、PdMやエンジニアが実装を進める上で、一切の迷いを持たないレベルまで仕様を研ぎ澄ますことにあります。
画面の外で何が起きているかをデザイナーが把握し、それをロジックとして定義しておくことで、実装時の手戻りは劇的に減ります。デザイナーが物理とデジタルの境界線を繋ぐことで、開発チーム全体が「安全で、予測可能なプロダクト」を自信を持って構築できるようになります。
デザインが物理を制御する
整理したフローは、物理現象をUIがどう受け止めるか、という設計です。しかし、次なるステップは、UIを通じて物理的な挙動をより直感的に、かつ安全に制御する領域へと進みます。
見た目の美しさを超え、ロジックで物理を制する。デジタルと物理の境界線をデザインの力でどう繋ぐのか、その挑戦をこれからも続けていきます。
