FigJam × ハコブくん設計。なんとなくのデザインではなく仕様としてのフロー図作成

UIデザイナーとして日々の業務を通じて実感しているのは、デザイナーの役割が単に綺麗な画面を作ることではなく、プロダクトの意図を汲み取り、実装へと繋ぐ翻訳者であるということです。

今回は、その一環として取り組んだ「ユーザー起点の基本動作のフロー図」の作成プロセスについてまとめます。

フロー図作成のプロセス

まず着手したのは、自身の役割の再定義でした。デザイナーには、プロダクトマネージャー（PdM）やエンジニアの意図を理解し、コミュニケーションを円滑にするための成果物に「翻訳」することが求められています。

具体的な画面制作に入る前に「ユーザー起点の基本動作」をフロー図として整理することが、チーム全体の曖昧さを減らす最短ルートだと考えました。

最初は、ユーザーが状態を確認して操作し、フィードバックを得るという直線的なフローから描き始めました。しかし、実際のシステム運用を考えると、正常系だけでは不十分です。

そこで、以下の要素を段階的に組み込み、ロジックを磨き上げました。

安全性の担保: 異常がある場合の「警告UI」を配置し、ユーザーが「承認/了解」した上で操作に進むステップを追加しました。
リカバリーフローの定義: エラーが発生した際、どのように操作を停止し、復旧操作を経て元の状態に戻るかというルートを明確にしました。
循環するステート設計: 操作完了後にフローを終えるのではなく、再び最初の「状態確認」へと戻るループを作ることで、システムの継続的な動作を可視化しました。

作成したフロー図は、自分自身の整理のためだけではありません。これは、ステークホルダーとの合意形成における重要な「共通言語」となります。

フローを視覚化し、関係者の意見を一致させるというミッションを果たすための一歩として、フロー図面作成は非常に意義のあるプロセスでした。

見た目の美しさと同じくらい、その裏側にある論理構造を重んじる。そんなデザイナーとしての在り方を大切にしながら、これからもチームの意思決定を加速させていけるよう、実務に取り組んでいきたいと思います。

今回整理したフロー図は、あくまでユーザーとUIのやり取りを中心とした基本動作の設計です。しかし、私が今向き合っているのは画面の中だけで完結するサービスではなく、実機としてのロボットが物理空間で動くプロダクトです。

この基本フローをベースに、ロボティクス特有の変数をどう組み込んでいくべきか、その具体的なアップデートについて掘り下げていきたいと思います。

具体的には、以下のような「物理現象とシステム制約」に起因する要素を付け加えていく予定です。

システム（機体）起点の割り込みフロー: ユーザーの操作中であっても、ロボットが自律的に障害物を検知したり、センサー異常を感知したりした際の「強制停止」や「自動回避」の挙動。
ハードウェア状態の可視化: 通信のレイテンシ（遅延）やバッテリー残量、ハードウェアの健康状態といった「目に見えない制約」をどうUIの状態遷移（ステート）に反映させるか。
環境要因による例外系: 段差や照明環境、周囲の動体など、物理環境の変化によって操作が継続できなくなった際のリカバリー設計。
物理的な安全性（Safety）の階層: ソフトウェア上のエラーと、物理的な緊急停止（E-Stop）が連動する際の、UIにおける情報の優先順位とインタラクション仕様。

見た目の美しさを超え、開発エンジニアが実装において一切の迷いを持たないレベルまで仕様を研ぎ澄ますために。デジタルと物理の境界線をデザインの力でどう繋ぐのか、その挑戦を続けていきます。