デザイナーは翻訳者ではなくなるのか
本文の状態
日本語全文を表示中
詳細モードで約10分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Algomatic Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
はじめまして。Algomatic でプロダクトデザイン/デザインリードをしているbuchiです。
Tech blog に書くのはハードルがめちゃめちゃ高くて怯えているのですが、デザイナー視点で昨今の開発におけるデザインやデザインツールのあり方について、自身が思っていることを書いてみます。
この記事は Algomatic 初夏のアドベントカレンダー 21 日目です。前回は ぴやてぃさんの「AI 開発時代の多層防御を設計する〜AWS アクセスキーにまつわる怖い話〜 - Algomatic Tech Blog」でした。
はじめに
私はプロダクト開発に関わる中で、ずっと同じことを言ってきました。
「Figma はあくまでも伝えるための手段であり、目的は伝えることだ」と言うこと。
UI デザインも仕様も、伝えたい相手にちゃんと伝わりさえすればいい。受け取る立場に立ち、欲しい情報を欲しい粒度で渡す。Web デザインやプロダクトデザインの成果物は、それそのものに価値があるわけではなく、何かを前に進めるための手段でしかないからです。
それなのに、現場では成果物（Figma）の精度そのものが目的になりがちです。なかでも、実装されたプロダクトを追いかけて、Figma の中に実物と同じ状態を作り、それを維持し続ける作業です。実装で余白が変われば Figma にも反映し、コンポーネントが増えれば Figma にも足し、修正のたびに両方を直していく。実装された時点で、本当のマスターはプロダクトに移っているはずなのに、それとほとんど同じ複製を別の場所に作って保管し続ける違和感。
他にも、Figma 内のコンポーネント設計やトークン設計にこだわり出したり、全てをコンポーネントで扱うがために Slot（スロット）なんてテクニックも登場し、そこに熱狂するデザイナーたちも少なくありませんでした。かくいう私もその一人だったのですが。
ただし、それでもこれまでは、Figma でデザインデータを作り込む理由が 2 つありました。
伝えるために進化したデザインツール
1 つ目は、より正確に伝えるためです。
デザインツールの歴史をたどると、Illustrator（ベクター描画ツール）、Photoshop（写真編集ツール）で Web デザインをしていました。これらのツールはそもそも Web デザインツールではないので、「どんなものを作ろうとしているか？」をクライアントやディレクターに伝えることは出来ても、エンジニアに「どう実装するか？」「どう動くか（動かすか）？」を伝えることは出来ませんでした。
そこから、Prott や ProtoPie などのプロトタイプツールの登場により、「どう動くか（動かすか）？」をより伝えやすくなりました。
その後、Sketch や XD、Figma などの UI デザインツールが登場しました。中でも Figma は、AutoLayout や Components、Variants など、実装により近づけるという設計思想を持っていたために、「どう実装するか？」「どう状態変化するか？」までをデザインツール上でエンジニアに伝えやすくなりました。
つまりデザインツールの歴史は、より少ないコミュニケーションコストで、より正確に伝えるための歴史だったと考えています。
越えられなかった実装コスト
2 つ目は、実装コストの高さです。
どれだけ精巧なデザインカンプや仕様書を作っても、実際に動くものを確認するにはエンジニアの協力が必要不可欠でした。だからデザイナーは、デザインツールの中で思考しました。
余白を調整し、色を変え、様々なパターンのレイアウトを試す。コンポーネントを整理し、状態変化を書き出す。動く実物に触れない代わりに、Figma の中で考えられる極限まで試行錯誤をしていました。
実装後の認識齟齬を減らすため、Figma の中に多くの情報を詰め込みました。Figma はいつしか単なるデザインツールではなく、設計図・仕様書・プロトタイプ・実装の参照元（マスター）を兼ねる存在になっていったように思います。
正確に伝えるため、そして動かして確かめられない分を補うため。この 2 つの理由が、Figma を大きく作り込ませていました。
デザイナーがやっていたことの多くは翻訳でした。頭の中にある設計を、エンジニアが実装できる形へと変換する。Figma はそのための翻訳ツールでした。
AI によって変わったのは実装コスト以上に翻訳コストかもしれない
AI によってまず変わったのは実装コストです。ラフな UI やざっくりした意図を渡すだけで、ものの数分から数十分で動くものが出てくるようになりました。
しかし、実際に現場で感じているのは、それ以上に翻訳コストの変化です。以前は、「こういうプロダクト（画面）を作りたい」を伝えるために、多くの成果物が必要でした。画面を作り込み、状態を書き出し、補足を書き、仕様を整理していました。
AI は、曖昧な入力でもかなりの精度で意図を汲み取ってくれます。また、AI による能力拡張によって一人が担える領域の幅も広がりました。それにより、そもそも次のプロセスを担う人へ伝えること自体が減りました。
意図を相手に伝わる形へ変換するための翻訳コストが減ったのです。
実際の現場で起きたこと
デザイン QA
最近は、フロントエンドに関してのみ、自身でプロダクションコードを触って修正しています。
これまでは、Figma にデザイン QA というページを作り、スクリーンショットとデザインカンプを左右に並べ、一つひとつ丁寧な修正指示をエンジニアに伝えていました。それが、AI の登場によって、自分で直せてしまうようになり、そもそも修正指示を伝える必要がなくなりました。翻訳すべき相手が消えたのです。
Web サイト制作
Claude Code を使って、自社のコーポレートサイトを一人で作りました。（色々あり、まだ公開できてないのが悔しいです…）
以前なら画面単位で Figma を作り込んでいましたが、今回最初に作ったのは、大枠のトンマナを決めるための一画面だけです。サイト全体のトンマナさえ決めれば、あとは Claude Code にぶん投げてスタートです。
一発で綺麗にはできませんから、そこから先はセクションごとに必要な要素やパーツだけを Figma でサクッと作り、その都度 AI に渡してブラウザ上で細かく作り込みました。AI に対して「ここはざっくりこう見せたい」が伝わればよく、Figma 上での作り込みは必要ありません。言葉で伝えるほうが速ければプロンプトを書き、絵で見せたほうが速ければ、その一部分だけを Figma に描いて渡します。（個人的には、昔コーダーをやっていたことから、ブラウザ上で試行錯誤していたコーダー時代を思い出したりもしました笑）
渡す成果物の作り込みが要らなくなりました。
チームでのプロダクト開発
現在、実験的にプロダクト（プロトタイプ）上での要件定義・仕様詳細化を試しています。
具体的には、大枠の体験設計・情報設計をして Figma にざっくりの UI を作りつつ、その時点から AI を使って 1〜2日でフロントエンドを実装。開発チームやユーザーにも実際に触ってもらい、フィードバックを集める、という進め方です。実際にユーザーが触って試せるプロダクトが出来上がるまでには、プロジェクト立ち上げから 1〜2週間程度でした。
業務システムで重要なのは、ユーザーが業務をスムーズに行えるかどうかです。入力のしやすさ、状況の把握のしやすさ、状態が切り替わるときの挙動。こうした部分は、静止画の Figma ではよく分かりません。
この進め方にしてから、認識のズレや抜け漏れに、以前より格段に早く気づけるようになりました。そして何より、チームやユーザーに伝える媒体が、Figma の成果物（絵）から実物そのものへと変化しました。絵や仕様書で説明するより、触れる実物のほうが、ずっと正確に多くのことを伝えてくれます。Figma を使って翻訳する必要性が低くなりました。
「翻訳」することは必要なくなるのか
この記事を書いている途中に、Config の発表がありました。実はこの発表を受けて、記事の大半を書き換えています笑
新機能はどれも楽しみですが、中でも Code layers が興味深いです。
Figma 上でコードを扱い、より実物に近い形で試行錯誤ができるようになるとのこと。これまでは、どこまで行っても「絵」でしかなかった Figma が、より「実物」に近づいてきました。Figma 自身も、「実物を絵に翻訳して伝えるツール」から、「実物そのものを扱うツール」へと進化しようとしていると感じます。
では、デザイナーの仕事から「翻訳」はなくなるのでしょうか。
翻訳に追われて見失っていた、本当に伝えるべき相手
なくなっていくのは、中間に存在した制作における翻訳作業だけです。
作り込み、仕様化、ハンドオフ。意図を次の作業者へ伝わる形へ変換する、これらの手間のことです。デザインツールの歴史は、その翻訳コストを下げ続けてきた歴史でした。AI によって、作ることと伝えることの境界は更に融けていきます。
私はずっと「目的は伝えることだ」と言ってきました。でも今なら、こう付け足します。
本当に伝えるべき相手は、エンジニアや PdM ではなく、その先にいるユーザーである。
デザイナーはようやく本来向き合うべき相手へ、まっすぐに向き合えるようになるのだと思います。
エンジニアだけでなく、デザイナーも募集しています
Algomatic では、変化の速い領域でも 学びや試行錯誤を続けられる デザイナーを募集しています。
弊社には、まだデザイン組織も文化もありません。これから一緒に一から作り上げていく気概を持った方、お待ちしています！
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
原文を表示
はじめまして。Algomaticでプロダクトデザイン/デザインリードをしているbuchiです。
Tech blogに書くのはハードルがめちゃめちゃ高くて怯えているのですが、デザイナー視点で昨今の開発におけるデザインやデザインツールのあり方について、自身が思っていることを書いてみます。
この記事は Algomatic 初夏のアドベントカレンダー 21日目です。前回は ぴやてぃさんの「AI開発時代の多層防御を設計する〜AWSアクセスキーにまつわる怖い話〜 - Algomatic Tech Blog」でした。
はじめに
私はプロダクト開発に関わる中で、ずっと同じことを言ってきました。
「Figmaはあくまでも伝えるための手段であり、目的は伝えることだ」と言うこと。
UIデザインも仕様も、伝えたい相手にちゃんと伝わりさえすればいい。受け取る立場に立ち、欲しい情報を欲しい粒度で渡す。Webデザインやプロダクトデザインの成果物は、それそのものに価値があるわけではなく、何かを前に進めるための手段でしかないからです。
それなのに、現場では成果物（Figma）の精度そのものが目的になりがちです。なかでも、実装されたプロダクトを追いかけて、Figmaの中に実物と同じ状態を作り、それを維持し続ける作業です。実装で余白が変わればFigmaにも反映し、コンポーネントが増えればFigmaにも足し、修正のたびに両方を直していく。実装された時点で、本当のマスターはプロダクトに移っているはずなのに、それとほとんど同じ複製を別の場所に作って保管し続ける違和感。
他にも、Figma内のコンポーネント設計やトークン設計にこだわり出したり、全てをコンポーネントで扱うがためにSlotなんてテクニックも登場し、そこに熱狂するデザイナーたちも少なくありませんでした。かくいう私もその一人だったのですが。
ただし、それでもこれまでは、Figmaでデザインデータを作り込む理由が2つありました。
伝えるために進化したデザインツール
1つ目は、より正確に伝えるためです。
デザインツールの歴史をたどると、Illustrator（ベクター描画ツール）、Photoshop（写真編集ツール）でWebデザインをしていました。これらのツールはそもそもWebデザインツールではないので、「どんなものを作ろうとしているか？」をクライアントやディレクターに伝えることは出来ても、エンジニアに「どう実装するか？」「どう動くか（動かすか）？」を伝えることは出来ませんでした。
そこから、ProttやProtoPieなどのプロトタイプツールの登場により、「どう動くか（動かすか）？」をより伝えやすくなりました。
その後、SketchやXD、FigmaなどのUIデザインツールが登場しました。中でもFigmaは、AutoLayoutやComponents、Variantsなど、実装により近づけるという設計思想を持っていたために、「どう実装するか？」「どう状態変化するか？」までをデザインツール上でエンジニアに伝えやすくなりました。
つまりデザインツールの歴史は、より少ないコミュニケーションコストで、より正確に伝えるための歴史だったと考えています。
越えられなかった実装コスト
2つ目は、実装コストの高さです。
どれだけ精巧なデザインカンプや仕様書を作っても、実際に動くものを確認するにはエンジニアの協力が必要不可欠でした。だからデザイナーは、デザインツールの中で思考しました。
余白を調整し、色を変え、様々なパターンのレイアウトを試す。コンポーネントを整理し、状態変化を書き出す。動く実物に触れない代わりに、Figmaの中で考えられる極限まで試行錯誤をしていました。
実装後の認識齟齬を減らすため、Figmaの中に多くの情報を詰め込みました。Figmaはいつしか単なるデザインツールではなく、設計図・仕様書・プロトタイプ・実装の参照元（マスター）を兼ねる存在になっていったように思います。
正確に伝えるため、そして動かして確かめられない分を補うため。この2つの理由が、Figmaを大きく作り込ませていました。
デザイナーがやっていたことの多くは翻訳でした。頭の中にある設計を、エンジニアが実装できる形へと変換する。Figmaはそのための翻訳ツールでした。
AIによって変わったのは実装コスト以上に翻訳コストかもしれない
AIによってまず変わったのは実装コストです。ラフなUIやざっくりした意図を渡すだけで、ものの数分から数十分で動くものが出てくるようになりました。
しかし、実際に現場で感じているのは、それ以上に翻訳コストの変化です。以前は、「こういうプロダクト（画面）を作りたい」を伝えるために、多くの成果物が必要でした。画面を作り込み、状態を書き出し、補足を書き、仕様を整理していました。
AIは、曖昧な入力でもかなりの精度で意図を汲み取ってくれます。また、AIによる能力拡張によって一人が担える領域の幅も広がりました。それにより、そもそも次のプロセスを担う人へ伝えること自体が減りました。
意図を相手に伝わる形へ変換するための翻訳コストが減ったのです。
実際の現場で起きたこと
デザインQA
最近は、フロントエンドに関してのみ、自身でプロダクションコードを触って修正しています。
これまでは、FigmaにデザインQAというページを作り、スクリーンショットとデザインカンプを左右に並べ、一つひとつ丁寧な修正指示をエンジニアに伝えていました。それが、AIの登場によって、自分で直せてしまうようになり、そもそも修正指示を伝える必要がなくなりました。翻訳すべき相手が消えたのです。
Webサイト制作
Claude Codeを使って、自社のコーポレートサイトを一人で作りました。（色々あり、まだ公開できてないのが悔しいです…）
以前なら画面単位でFigmaを作り込んでいましたが、今回最初に作ったのは、大枠のトンマナを決めるための一画面だけです。サイト全体のトンマナさえ決めれば、あとはClaude Codeにぶん投げてスタートです。
一発で綺麗にはできませんから、そこから先はセクションごとに必要な要素やパーツだけをFigmaでサクッと作り、その都度AIに渡してブラウザ上で細かく作り込みました。AIに対して「ここはざっくりこう見せたい」が伝わればよく、Figma上での作り込みは必要ありません。言葉で伝えるほうが速ければプロンプトを書き、絵で見せたほうが速ければ、その一部分だけをFigmaに描いて渡します。（個人的には、昔コーダーをやっていたことから、ブラウザ上で試行錯誤していたコーダー時代を思い出したりもしました笑）
渡す成果物の作り込みが要らなくなりました。
チームでのプロダクト開発
現在、実験的にプロダクト（プロトタイプ）上での要件定義・仕様詳細化を試しています。
具体的には、大枠の体験設計・情報設計をしてFigmaにざっくりのUIを作りつつ、その時点からAIを使って1〜2日でフロントエンドを実装。開発チームやユーザーにも実際に触ってもらい、フィードバックを集める、という進め方です。実際にユーザーが触って試せるプロダクトが出来上がるまでには、プロジェクト立ち上げから1〜2週間程度でした。
業務システムで重要なのは、ユーザーが業務をスムーズに行えるかどうかです。入力のしやすさ、状況の把握のしやすさ、状態が切り替わるときの挙動。こうした部分は、静止画のFigmaではよく分かりません。
この進め方にしてから、認識のズレや抜け漏れに、以前より格段に早く気づけるようになりました。そして何より、チームやユーザーに伝える媒体が、Figmaの成果物（絵）から実物そのものへと変化しました。絵や仕様書で説明するより、触れる実物のほうが、ずっと正確に多くのことを伝えてくれます。Figmaを使って翻訳する必要性が低くなりました。
「翻訳」することは必要なくなるのか
この記事を書いている途中に、Configの発表がありました。実はこの発表を受けて、記事の大半を書き換えています笑
新機能はどれも楽しみですが、中でもCode layersが興味深いです。
Figma上でコードを扱い、より実物に近い形で試行錯誤ができるようになるとのこと。これまでは、どこまで行っても「絵」でしかなかったFigmaが、より「実物」に近づいてきました。Figma自身も、「実物を絵に翻訳して伝えるツール」から、「実物そのものを扱うツール」へと進化しようとしていると感じます。
では、デザイナーの仕事から「翻訳」はなくなるのでしょうか。
翻訳に追われて見失っていた、本当に伝えるべき相手
なくなっていくのは、中間に存在した制作における翻訳作業だけです。
作り込み、仕様化、ハンドオフ。意図を次の作業者へ伝わる形へ変換する、これらの手間のことです。デザインツールの歴史は、その翻訳コストを下げ続けてきた歴史でした。AIによって、作ることと伝えることの境界は更に融けていきます。
私はずっと「目的は伝えることだ」と言ってきました。でも今なら、こう付け足します。
本当に伝えるべき相手は、エンジニアやPdMではなく、その先にいるユーザーである。
デザイナーはようやく本来向き合うべき相手へ、まっすぐに向き合えるようになるのだと思います。
エンジニアだけでなく、デザイナーも募集しています
Algomatic では、変化の速い領域でも 学びや試行錯誤を続けられるデザイナーを募集しています。
弊社には、まだデザイン組織も文化もありません。これから一緒に一から作り上げていく気概を持った方、お待ちしています！
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み