TesujiUI実装で揉めるのは、デザインが悪いからとは限らない
Figma上で画面が綺麗にできていても、実装段階で止まることがあります。
理由は、画面画像には「見た目」はあっても、「状態」が書かれていないことが多いからです。
たとえばプロフィール編集画面なら、実装側には次が必要です。
- 初期表示
- 編集中
- 保存中
- 保存成功
- バリデーションエラー
- APIエラー
- 権限がない
- データが空
- スマホ表示
- 長い文字列
Figmaだけでも、文章だけでも不足します。
そこで、
- Figma：視覚構造と操作の入口
- ChatGPT：状態・例外・仕様の分解
- GitHub：実装・レビュー・変更履歴
に役割を分けます。
まずFigmaから「見えている事実」を抜き出す
いきなりコードを書かず、画面から要素を列挙します。
たとえばプロフィール画面なら、
- アイコン
- 名前
- Bio
- SNSリンク一覧
- 追加ボタン
- 保存ボタン
- 削除操作
があります。
次にChatGPTへ、
この画面を実装するために不足している状態・例外・操作条件を列挙して
と渡します。
すると、見た目には現れにくい要件を増やせます。
UI仕様は「要素」ではなく「状態」で書く
たとえばSNSリンク追加なら、要件は単に「Instagramを追加できる」では足りません。
最低でも、
| 状態 | 期待挙動 |
|---|---|
| 0件 | 空状態と追加導線 |
| 1件 | アイコン・URL表示 |
| 複数件 | 並び順と折返し |
| 同一サービス複数 | 両方保持 |
| 不正URL | 保存拒否 |
| 保存中 | 二重送信防止 |
| 保存失敗 | 入力を失わずエラー表示 |
| スマホ | 横スクロールしない |
まで考えます。
これを先に決めれば、実装者が「そこはどうするんですか？」と後から聞く回数が減ります。
ChatGPTは「デザインを決めるAI」より「仕様の穴を探すAI」にする
AIへ「良いUIにして」と頼むと、一般論が返りがちです。
代わりに、
- この画面でユーザーが失敗する操作は？
- 空状態は？
- 1,000文字入力されたら？
- 権限がない人がURL直打ちしたら？
- 保存APIが500なら？
- スマホ320px幅なら？
のように、壊し方を考えさせると実装品質が上がります。
Figmaと実装のズレを減らす「受け入れ条件」
GitHub Issueへ渡すときは、見た目の説明だけでなく、確認条件を書きます。
例：
完了条件
- Instagram / YouTube / Xを追加できる
- 同じ種類を複数追加できる
- URL編集・削除ができる
- 保存後の再読み込みでも保持
- 不正な
javascript:URLは拒否 - 320px幅で横溢れしない
- 公開プロフィールにも反映
ここまであれば、AIコーディングエージェントでも人間でも、同じ完了像を共有できます。
GitHub Issueはデザインのコピーではない
Figmaリンクだけ貼ったIssueは、実装者に判断を押しつけます。
Issueには最低でも、
- 目的
- 対象画面
- 操作
- 状態
- バリデーション
- 権限
- レスポンシブ条件
- 完了条件
を残します。
Figmaは「どう見えるか」、Issueは「どう振る舞うか」です。
実装後はFigmaと1px比較する前に、状態を確認する
UIレビューで細部だけを見ると、本質的な不具合を見逃します。
先に、
- 保存できるか
- 失敗時に戻れるか
- データが消えないか
- 権限境界が守られるか
- スマホで操作できるか
を確認します。
その後で余白、文字サイズ、アイコン位置などを詰めます。
機能の壊れ方を先、見た目の差分を後にするとレビューが速くなります。
デザイン変更もPRと同じく差分で扱う
「プロフィール画面をもっと良くする」のような大きい変更は、何が改善したか分かりにくくなります。
代わりに、
- SNS追加導線を改善
- モバイル下部ナビへ変更
- 保存エラー表示を改善
- ノード詳細の情報密度を調整
のように1変更1意図へ分けます。
FigmaでもGitHubでも、差分が小さい方がレビューしやすいという点は同じです。
KPI
UI開発の品質を測るなら、
- デザイン確定 → PRまでの時間
- 実装後の仕様質問数
- QAで見つかる状態漏れ数
- モバイル崩れの再発率
- PR後のデザイン手戻り回数
を見るとよいです。
特に「実装後の仕様質問数」が減るなら、FigmaとIssueの間をうまく埋められています。
次の一手
次のUI改修1件で、Figmaを見たあとすぐ実装せず、ChatGPTへ次の3つを出させます。
- 状態一覧
- 失敗ケース一覧
- GitHub用の受け入れ条件
それを人間が5分レビューしてからIssueへ入れる。
Figma × ChatGPT × GitHubの組み合わせで一番効くのは、デザイン生成ではなく、『見た目』と『動く仕様』の間にある抜けを減らすことです。