これは今回に関しては完全に正しいよ。FigmaのAuto Layoutは、Flexboxの簡略版に過ぎないし、その目的は以下の通りだよ：1. サイズ変更に対応すること 2. 手動で行や列に配置する手間を省くこと

革新的なカスタムデザイナーは、他のツールを使ったり、必要に応じて手動アニメーションやレイアウトを行うことができるよ。

デザイナーにFlexレイアウトを考えさせるのは、彼らの強みを活かさないし、開発者にレイアウトアルゴリズムやコンポーネントの階層に100%指定されたデザインをコードに変換させるのも、彼らの強みを活かさないよ。でも、これがFigmaが推奨するワークフローなんだ。著者が勧めているのは、デザイナーがスケッチやワイヤーフレームでより自由に作業し、開発者が早い段階でそれを受け取って実用的な構造に持っていくこと。そして、デザイナーと開発者のコラボレーションは非同期の引き渡しで終わるのではなく、一緒にデザインを最終化すること、つまりコードでね。ここにいるコメント者の中には、「実装が難しいデザイン」を作るデザイナーにイライラしている人もいるみたいで、だからみんな自動レイアウトでデザインを制約することを望んでいると思ってる。でも、これは問題の原因に対処していないんだ。デザイナーが孤立して作ったデザインが、開発者が100%一致させるべき聖典として扱われているのが本当の問題だと思う。私の意見では、Figmaがこのワークフローを促進することの最も深刻な問題は、機能のギャップだね。Figmaの機能セットはCSSに比べて非常に力不足だし、グリッドすらない。もしデザイナーがFigmaが許すツールだけで作業しているなら、開発者が持ち込むことができるクールでクリエイティブなアイデアは消えてしまう。だって、実際には彼らのプラットフォームでは実装が簡単だから（デザイナーが知らないだけ）。このMatthias Ottのトークをぜひおすすめするよ：https://www.youtube.com/watch?v=1Pq7VqNrtk4

どんな要素でもオートレイアウトグリッドを無視するのは簡単だよ。

そうだね。1990年代には、印刷向けのデザインを「小売」レベル（広告やポスターをデザインする）でできる人がウェブデザインに大量に流れ込んできた。デザイナーからPSDをもらって、当時の原始的なHTMLを使ってそれに似たものを作るのが常だった。今はFigmaがPSDの代わりになったけど、同じ問題が残ってる。新しいiOSが出ると、素人の評論家たちがピクセル単位で見た目をチェックしたがるけど、UXデザインの観点でのインタラクションの流れを考えることには興味がないんだよね。開発者としては、デザイナーからはデザインシステムや、実装すべきもののガイダンスがほしい。デザイナーが関わったように見えるものを作るためにね。ツールのせいにするより、体系的に考えないデザイナーの方が問題だと思う。CSSはデザインシステムを作るために設計された（意味論を反映したCSSクラスを使う）けど、BootstrapやTailwind、Emotion、MUIのテーマシステムはその理想から後退してる。でも、これらのツールが悪いデザイナーを生むわけじゃなくて、逆だと思う。

うちのチームの一つがFigmaを使ってユーザーと苦労してたんだけど、誰かが「LLMにモックUIのコードを生成させよう！」ってアイデアを出して、2日で実現したんだ。ユーザー体験が格段に良くなったよ。

そうだね… デザインフェーズでは絵を描いて、あとはコードにすればいいよ。

今、代替ツールを作ってるところだよ。ブラウザでHTMLとCSSを使ってデザインするためのツールなんだ。トークンを含めて、すべてがパラメトリックに設計されてる。最終的には、エンドツーエンドのプロトタイプを完成させるつもりだけど、まだできてないんだ。

これって、ノーコードやローコードプラットフォーム全般の問題じゃない？ コードは要件を損失なく指定するための、最もシンプルな人間が読める表現に過ぎないと思う。最近は「K8s YAML」や「プロンプトエンジニアリング」でも同じパターンが見られるよね。新しいDSLを再発明している業界があって、要件が複雑になるにつれて、結局はスクリプト言語に収束していく。抽象化を再発明するのではなくて、基盤となる抽象化に損失なくマッピングできるノーコードのUXパターンを見てみたいな。そうすれば、UXパターンを使っていても面倒になったら、コードビューにスムーズに行き来できるし。Gitツリーを操作するためのグラフUI（gitgraph）はいい例だよね。オーケストレーションUIビュー（Airflow / Langraph）もその方向に向かってる。もっと高い抽象レベルでは、Notion（CRDT UI）はブロックを使ってコラボレーションロックをうまく表現してる。最高の視点では、Gather-townがリモートコラボレーションを表現するのがすごく好き。もっとこういうのが見たいな。

自由な形式のデザインツールが必要なら、使えばいい。何百もあるから。Figmaの前は、デザインツールの標準はPhotoshopだったんだよ。「何百もある」わけじゃない。だから、もしFigmaの創設者がほとんどのデザイナーにアピールするツールを開発していたなら、CSS/HTMLよりもPhotoshopに近い形になっていたはずだよ。

自分でデザインをたくさんやる開発者として、デザインがターゲットにしているレイアウトシステムを完全に再現する必要性はあまり理解できない。関わる制約や制限は深く内面化されていて、大体どこでデザインが壊れやすいか、どう対処すればいいかは分かってる。レイアウトシステムは、モックアップを作っている間ずっと頭の中で動いているからね。だから、正しいスペーシングのような単純作業を手伝ってくれるツールがあるのは嬉しいけど、モックアップであらゆる動作を正確に再現するのは、無駄な作業に感じることが多い。チーム環境では少し事情が違うけど、関わる全員がこのレベルの知識や経験を持っているとは限らないから。ただ、デザイナーがこのスキルセットを持つことを期待するのはおかしくないし、デザインやエンジニアリング以外の人たちがデザインに簡単に手を出せるのはあまり良くないことかもしれない。デザインチームを必須の仲介者として設けることで、変更の妥当性をチェックできるんだ。

私はUberで大規模なデザインをやっているけど、全く逆の経験をしてる。

まさにその通り。ありがとう。製品デザイン専用のBlenderみたいなデザインツールが必要だよ。HTML/CSSを使ってレンダリングして、ほとんどのウェブニーズをカバーするようにして、ネイティブアプリのレイアウトエミュレーションも十分にこなせるもの。オープンソースで、技術的で、誰もが一日で理解できるわけじゃないものがいい。Figmaが私たちをデザインボックスに押し込んでいる理由は、実際に素晴らしい体験を作るためのCSS機能が全て揃っていないからだ。

「問題は、エンジニアにとってデザイナー寄りすぎることだ」その通り！何度も新しい個人プロジェクトを始めたいと思ったけど、Figmaのデザインプロセスにハマってしまった。他に選択肢がなくて、純粋なHTML/CSSで書くしかなかった。あのクソみたいなフレームワークとは違って、あれだけはまだ「機能する」。

例えば、どれだけのJavaScriptプログラマーがErlangのスーパーバイザーパターンを知ってるんだろう。JavaScriptがそれをサポートしてないから、知るわけないよね。逆に、私は別の問題にぶつかってる。ライブビューでプロジェクトを作ったんだけど、状態管理が思ったようにはいってない。ほとんどすべてが、単一のオブジェクトのhandle_infoへのコールバックで、socket.assignsに値を設定するだけで、整理するための明確な方法がない。ストリームベースのパイプラインを非同期リデューサーで作るための要素は揃ってるけど、まだ誰もやってない。もちろん、JS開発者はreduxを知ってるから、これはJSの世界では解決済みのパターンだね。

今、HTMLとCSSだけのウェブデザイナーの役割ってどれくらいあるんだろう？「HTMLとCSS」が要件に含まれているポジションが投稿されるたびに、ほぼ確実に何らかのJavaScriptフレームワークも含まれているよね。

誰かがこの記事のAuto Layoutの部分に問題を感じているのを見て、ちょっと嬉しい。形状やテキスト、グルーピングツールは全部揃ってるのに、誰もそれを使って新しいインターフェースを作るのを止めてないのが不思議だよね。自動スナッピングがほぼゼロの状態で。

同感。私にとって、開発者とデザイナーのやり取りで一番汚い言葉は「ハンドオフ」だと思う。どんなデザインツールでも、ライフサイクルの中で必ずその話が出てくるよね。たとえ原則的には静かに反対していても。私の印象では、そういうことを言い出すのは、残念ながらそんな機能不全なチームダイナミクスを実践している顧客を獲得しようとしている時だと思う。デザインをする開発者として、私は常にコードとビジュアルデザインツールの間を行き来しているけど、プロジェクトの現在の段階に基づいていることは少なくて、むしろ自分がどんな考え方をしたいかに基づいていることが多い。制約に取り組みたい時は、コードでやることが多いし、余談を探りたい時はデザインツールを開く。

最近、こういう小文字の「アジャイル」な働き方にすごく慣れてきた。キャリアの初めは、デザインがすべて整って準備万端であることを望んでいた。それが彼らの「仕事」だと思ってた。でも、何度もそれが失敗するのを見てきた。時々、同僚にそれを伝えるのが難しいけど、みんなが自分の仕事を出荷する製品を作ることだと理解すれば、もっとスムーズになると思う。デザインは製品じゃないし、リポジトリもそうじゃない。デザイナーが鉛筆を持って、私がブラシを持っているかもしれないけど、私たちは同じキャンバスで作業しているんだ。

コンテンツマーケティングやそれに類するものを作っているわけじゃない限り、探索フェーズを自由に進める必要はあまりないと思う。新しいデザインを実装するたびにデザインシステムが伸びたり修正されたりするプロダクトでデザインを実装しようとするのは、開発者としては本当に面倒だよ。特に、小さなチームで新機能を出そうとしている時はなおさら。アクションを呼びかけるための第十のバリエーションなんていらないし、ただこの一箇所のために新しい第十の青や緑の色合いを使う必要もない。既存のパディングルールに対する第20の例外もいらない。デスクトップでは一つのサイズで、モバイルでは別のサイズにするなら、その新機能でも同じようにサイズが変わるべきだよ。デザイン言語が整ったら、意味のある一貫した変更がない限り、放っておいてほしい。昔、Photoshopファイルを切り刻んでた時代を思うと、今はコラボレーションのための良いツールがあって本当に嬉しい。

Figmaは本来のユーザーであるデザイナーを無視してるよね。今は誰にでも合うようにしようとしてるけど、結局誰にも満足されてない感じ。全部はFigJamから始まったんだよね。まだまだ中途半端な製品で、Miroからシェアを奪おうとしてる。で、収益を増やすためにDev Modeを出して、今度はFigma Sitesをリリースしてウェブビルドやホスティングサイトと競争しようとしてる。中途半端な製品が多すぎて、ほんとイライラする。市場での独占的な立場を悪用してるよ。いつかGoogleみたいに、うまくいかなかった製品を引退させる時が来ると思う。

「ここでの「近づける」がキーワードで、「強制する」じゃない」 それを変えるためのグローバルトグルを作る方法はないの？強制することが望まれることが多いけど、それを実現するための十分なガードレールを設置するのは難しい。エンジニアにはテストやリンターがあるけど、デザインの世界にはそれに相当するものがなくて、切実に必要だと思う。>「一番大事なのは、いつでもそれから切り離せるってこと」 デザインシステムの著者からのリクエストの中で、切り離しを防ぐことが多くなってきたけど、私たちはそれを実装したことがない。なぜなら、デザイナーが完全に自由なデザインの考え方に戻れる方法を常に持っていてほしいから。オートレイアウトを削除することもできるし、インスタンスを切り離すこともできるし、変数を壊すこともできる。これらはオプション機能であって、あなたを縛る手錠じゃない。さらに進みたいなら、選択した要素の制限をすべて切り離すプラグインもたくさんあるよ。すべての色を16進数にし、オートレイアウトを削除し、すべてを絶対位置にして、自由にドラッグできるようにする。私たちはこれを行うネイティブ機能は提供していないけど（これは多くの役立つメタデータを削除するかなり極端な手段だから）、本当にクリエイティブな極限に行きたい人にはこういった行動を妨げてはいないよ。アプリケーションデザイン側で機能を実装する場合、エンジニア側で実装するチームの制約を最適に表現する必要があるから、共有の制約があれば素晴らしいと思う。そうすれば、あまり乖離せずに実際の一貫性を得られる。要するに、あなたが言っているのは「一貫性なんてクソくらえ、このツールは組織のニーズを気にしない」ってことだね。

参考までに、あなたはほぼ正しい方向に進んでいると思う。Figmaのオートレイアウトが導入されてから、デザイナーから来るデザインの「実装可能性」が大幅に向上したのに気づいた。創造性を抑えているという意見もあるかもしれないけど（私は完全には納得していないけど）、それは「非標準」な要素の実装にかかるエンジニアの時間を大幅に節約している。特にレスポンシブデザインに関しては、デザイナーがその影響を理解していないことが多いから、意図的でないことが多い。参考までに、次の大きな改善点は、Figmaのための何らかの（簡略化された？）Gitスタイルのバージョン管理になると思う。大規模なプロジェクトで多くの人が協力する場合、これは非常に役立つけど、小さなチームでも実際に非常に有用だと思う。私たちはしばしば、デザインを実装するのに多くの時間を費やして、実は一つ前のリビジョンだったり、まだ承認されていなかったりすることが多い。特にリモートで作業しているときはね。