自社プロダクトのUIをAIが再現するデザインビルドシステム

デザインハーネス 2nd 登壇資料

NEWTの開発では、デザイナーがレビューする立場に回り、他の職種の方でもUIデザインができる仕組みを整えています。その取り組みについてまとめた資料です。

Transcript

1. 自社プロダクトのUIをAIが再現する デザインビルドシステム toy / 令和トラベル デザインビルドシステム ─ NEWT 01 / 40
2. 自己紹介 toy Product Designer Affiliation 令和トラベル / NEWT Role プロダクトデザイナー Birthday 1999/10/18 Hometown 山口県 Hobbies ドッグランに行く Favorite Tools Figma, Claude One Word NEWTのデザインシステムを設計・運用しています
3. プロダクト紹介 2:10 ダイヤモンド 海外ツアー 宿・ホテル 東京（羽田+成田） 目的地をえらぶ 2/2(金) - 2/5(月) ±1日 1室 ｜ おとな 2名 さがす 続きからさがす ゴールドコースト 1室 | おとな2名 10/31(水) - 11/3(日) ゴールドコースト 1室 | おとな2名 10/31(水) - 11/3(日) ゴールドコースト 1室 | おとな2名 10/31(水) - 11/3(日)
4. いま できること デザインビルドシステム ─ NEWT 04 / 40
5. いま できること そのプロダクトっぽいUIプロトは、 AIでもう作れる時代 HTMLなどモックを組んで誰でもプロトタイプができる。 デザインビルドシステム ─ NEWT 05 / 40
6. 結論 ただ、それがモックではなく GOを出したらすぐにリリースできるUI ができたらもっと良くないですか？ 開発スピードが上がる、アニメーションやインタラクションなどにもっと時間が割ける デザインビルドシステム ─ NEWT 06 / 40
7. パート 1 / 4 課題と目的 デザインビルドシステム ─ NEWT 07 / 40
8. 課題 開発が速くなるほど、デザインが詰まる。 BEFORE AFTER 3 チーム体制 チーム 1 E 8 チーム体制 E E D チーム 1 E D チーム 2 E D チーム 3 E D チーム 6 E D? AI で高速化 チーム 2 チーム 3 E E E D チーム 4 E D? チーム 5 E D? E E D チーム 7 E D? チーム 8 E D? 全チームにデザイナーがいる デザインビルドシステム ─ NEWT ※デザイナーの人数は増えていない。兼務でカバーしている。 08 / 40
9. 目的 デザイナーがいないチームでも 高品質のデザインを作る デザイナーはレビュー（意思決定）に回り、 制作コストを浮かせながら品質は落とさない仕組みを作る。 デザインビルドシステム ─ NEWT 09 / 40
10. 目的を満たす5つの要件 実現したかった5つのこと。 Claude Code で組み立てる Figma を起点にしない 思考の流れを再現する デザイナーと同じ順序で進める レビューできる成果物にする 画面と判断材料を一緒に出す デザインに集中する APIなどは考慮せずにデザインだけ考えられる 確定版がマスターになる 手作業で反映し直さない デザインビルドシステム ─ NEWT 10 / 40
11. パート 2 / 4 用意したもの デザインビルドシステム ─ NEWT 11 / 40
13. 用意したもの / 置き場所 design-mock newt-design-system/ ├── tokens/ ├── packages/ui/ └── design-mock/ GitHub のリポジトリ 1 つ デザインシステム ─ トークン デザインシステム ─ UI 部品 今日の主役。画面とその仕様とMCP design-mockはマスターとプレイグラウンド デザインビルドシステム ─ NEWT 13 / 40
14. 用意したもの / よく聞かれること 開発環境に直接じゃダメなの？ 本番のコードで直接やらない理由は3つ。 複数案が並べづらい 本番のコードに 3 案を同時には置けない。 状態を全部見られない 読み込み中・0 件・エラー・売り切れを並べられない 実装コストが高い Web もアプリもあり、試すたびに全端末ぶん作る デザインビルドシステム ─ NEWT 14 / 40
15. パート 3 / 4 デザインフロー デザインビルドシステム ─ NEWT 15 / 40
16. 課題と目的は、こう解けました / AS-IS デザイナーが1案件をつきっきりで担当 調査からデザインまでデザイナー 1 人がやる。 ここまで全部、デザイナー 1 人がやる 課題 調査 UI・仕様作成 実装 レビュー ズレを Figma に直す Figma と実装は別物。実装のたびに Figma を直しに戻る。マスターの更新も手作業。 デザインビルドシステム ─ NEWT 16 / 40
17. TO-BE デザイナーのGOが出たらそのまま開発へ 課題から承認したデザインをそのまま開発へ。 課題 design-builder skill デザイナーが GO 開発 エンジニア・PM が持ち込む skill。エンジニア・PM が動かす 描かずに判断 Web / アプリ 開発後の微修正は、デザイナーが直接 PR を出す デザインビルドシステム ─ NEWT 17 / 40
18. DESIGN-BUILDER / 6 手順 デザイナーの考える流れを、そのまま再現するskill ここで動くのが design-builder という skill。条件の 2 つめを担当している。 design-builder ① 曖昧点を質問で潰す ② 既存仕様と他社事例を調査 ③ 複数案を並べてデザイン ④ specページを作成 ⑤ Vercel preview でライブ共有 ⑥ 承認後 本体マスターへ昇格・マージ デザインビルドシステム ─ NEWT 仕様をもらってから、AIが不明点をなくす Notion / slack / BigQuery / devin / web research / mobbin などを使用してリサーチ 複数案を作成 / 推奨案ではエラー/emptyなどの状態も明記する 説明 / 仕様 / 全案 / 推奨理由を一つの画面にまとめる。これだけ読んだらOK コメントができて、そのままAIに取り込める（今はartifactでも同様のことができるけど） FIgmaでのマスター管理をやめて、git上で管理する 18 / 40
20. SPEC 20 / 40
22. REVIEW / OK と言える状態へ デザイナーの思考をなぞって考えさせる 順序 いきなり描かない 調査 → 仕様理解 → 複数案 → 提案。その順番を、そのまま手順にしている。 成果物 1URLでレビューが完結 説明も、仕様も、全案も、推奨理由も、モックの中に 1 画面として入っている。 レビュー リリースまでには微調整が要る。だからリリースできる品質の案を理由つきで複数出し、 デザイナーが OK と言える状態にする。 「雰囲気良さそう」ではだめ デザインビルドシステム ─ NEWT 22 / 40
23. DESIGN-BUILDER / 入口 案件ごとにブランチを切る。 デザインも実装と同じで、design-systemのブランチ内でfeature/を切ってデザインする 承認されたらマージ＝マスターが更新される main 確定したデザイン＝マスター 案件 A 案件ブランチ 案件ごとに、同時に何本でも 案件 B 案件 C それぞれのブランチで作業する。作るのは誰でもOK デザインビルドシステム ─ NEWT 23 / 40
24. パート 4 / 4 詳細の仕組み デザインビルドシステム ─ NEWT 24 / 40
25. design-mock とは デザインマスターとデザイン案を作る場所が、 design-mock。 packages/ui の部品を使ってNEWT のデザイン案を考える。 API やデータの取り回しといった実装の都合は一切持ち込まない。 デザインビルドシステム ─ NEWT 25 / 40
26. design-mock の中身 / 全体 design-mockの中 design-mock/ ├── screens/ ├── app/ ├── design/ ├── foundations/ ├── src/ └── scripts/design/ 画面 一覧 ワークスペース（一覧・端末切替・状態切替）と画面のルーティング 機械可読のドキュメント。contract・禁止ルールなど 原則 MCP サーバー。上のぜんぶを AI に配信する 検査ゲート。CI と MCP と hook が同じここを通る 画面・仕様・原則・検査がひとつの中に揃っている。 デザインビルドシステム ─ NEWT 26 / 40
27. design-mock とは / 構造 デザインを構造化する 4 つの粒度 page 画面全体 section 画面内のまとまり domain-component NEWT ドメイン固有の部品 ui-component 汎用部品 例：ツアー詳細、ホテル一覧 例：ホテルセクション、料金セクション 例：TourCard、HotelCard 例：Button、Alert、Tabs この 4 つがAIに引かせる単位になる。 デザインビルドシステム ─ NEWT 27 / 40
28. design-mock の中身 / screens 画面の中には何が入っているか screens/tour-list/ 1 ├── app/ アプリの画面。Screen.tsx と CSS Modules ├── sp/ モバイル Web の画面 ├── pc/ PC の画面 ├── _mocks/ この画面で使うダミーデータ ├── meta.ts どの端末を作るか・どんな状態があるか・どのセクションでできているか ├── sections.json セクションの索引。id と名前と説明。MCP がこの単位で切り出す └── page.tsx device / state を受けて、上のどれかを出すだけ 画面 =3 端末 + 状態 デザインビルドシステム ─ NEWT + セクションの索引。この 1 ット 全ページ セ が にある。 28 / 40
29. design-mock の中身 / design 仕様/ルールはcontractsに集約 design/ ├── contracts/components/ 部品の contract。props と使いどころ ├── contracts/pages/ 画面の contract。何の画面で、何を出すか ├── contracts/rules.json 禁止ルール。守り方（静的検査 / 実機 / 人）も一緒に宣言する ├── contracts/conventions.json 横断の様式。ページの骨格 7 種 × 主な画面配置のテンプレ 9 種 ├── enforcement.md どのルールを、どの経路で守るか 小さな不具合 台帳 回 たら └── papercuts.json の 。2 育てていく必要があ ため、 回作って終わ で 出 ルールは デザインビルドシステム ─ NEWT る 一 り に昇格 ルール する い はな 29 / 40
30. FIGMA newt-ui MCP デザインビルドシステム ─ NEWT 30 / 40
31. なぜ自前の MCP か newt-ui MCPを通してAIが検索する ルールやモックのみだけだと... 量が入らない 1画面は数万〜十数万文字。粒度を指定して引く。 どれが正か分からない 旧デザインや中間生成物を掴ませない。 順序を強制したい 接続時に「作る前に引く／後で検査」の強制。 デザインビルドシステム ─ NEWT 31 / 40
32. DESIGN-ALLOW ルールを破るなら、理由を書く。 // design-allow-start: USE_MODAL ← ここに理由。書かないと例外が無効 ... // design-allow-end 「既存で表現できず自作した」ものも、全部申告させる。 禁止して止めるのではなく、逸脱を残させる。あとでルールを直すか、パーツを足すかを決める。 デザインビルドシステム ─ NEWT 32 / 40
33. 詳細の仕組み / ルールの立て方 ルール/ふるまいを多角的な視点で考える コンポーネントルールだけではなく、ページや画面構成などのルールなとかないと再現性低そうかも...！ ブランド基礎の言語化よりも、根本的な UI ルールを守らせる方が効きそうじゃないか！ 例えば、新しい商品の予約フォームを作りたいとなると、フォームやボタンなどのコンポーネントルールだけでは なく、AI が「ツアー予約の予約フォーム」と同じルールで作るのが一貫性があって良くなる。その上でその商品の 特性を理解して作らせると、自然とルールが生きる。 → デザイナーが考えてやることをいろんな視点から模倣させる デザインビルドシステム ─ NEWT 33 / 40
34. FIGMA じゃあ、Figma は もういらないの？ デザインビルドシステム ─ NEWT 34 / 40
35. FIGMA もっと探索的なデザインや UIとグラフィックとの微調整に使用 デザインビルドシステム ─ NEWT 35 / 40
36. FIGMA / code → design 例えば、UIリニューアル :0 2 1 9:41 1/1 概要 アクセス S ALE 1/ 日本語OK 30 この施設について ザ リッツ カールトン ミレニア シンガ ポール 日本語OK! ザ リッツ カールトン ミレニア シンガポール The Ritz-Carlton, Millenia Singapore (SG Clean) The Ritz-Carlton, Millenia Singapore (SG Clean) Singapore 4.5 / 5 ( 1,000件のレビュー) Singapore 4.5 / 5 (1,000件のレビュー) 概要 アクセス 部屋 この施設について 36 / 40
37. FIGMA / code → design design-mockそのまま引き継げるskillも活用 絵にならない ちゃんと使った状態で作られる。生 hex や生 px を並べた「絵」にならない。 variables / font style / component 続きから コンポーネントもカラーも揃った状態で続きから探索できる。 0 から作り直さない。 戻せる そのまま実装してもいい。 デザインビルドシステム ─ NEWT Figmaで詰めたものをそのまま実装に持っていける。 37 / 40
38. CODE → DESIGN / Figma には、続きから入れる 2:10 羽田空港 ←→ ホノルル(ハワイ) 2/2(金) - 2/5(月), 1室, 2名 しぼりこみ ならびかえ 行きの時間 帰りの時間 ホテルグレード 航空会社 検索結果 200件 SALE PICK ホノルル (ハワイ) / 5 - 10日間 羽田発、インフィニティプールがある高級レジデ ンスホテルに宿泊 カ ライ ワイキキビーチ LXRホテルズ ＆リゾーツ JAL（日本航空） 乗継便 行き 午前発 帰り 午後発 おとな1名・5日間(燃油込み) ¥150,800〜 10,000ポイント〜 たまる 38 / 40 座席クラ
39. パート 4 / 4 今後の取り組み デザインビルドシステム ─ NEWT 39 / 40
40. 今後の取り組み 次は、ディスカバリーごと回す。 いまあるのは仕様作成とデザインまで。 課題設定 → 調査 → 仕様作成 → デザイン → テスト設計 → 結果の取り込み ▲ いまある これから 結果を、また次の課題に戻す ひとつの施策を課題から結果までぐるぐる回し続けたい。 デザインビルドシステム ─ NEWT 40 / 40