Figmaと実装の乖離は怠慢ではなく、構造の欠陥である｜Matz

パラダイムの違いって指摘はかなり納得感ある。でも仕様書という中間生成物のメンテコストを誰が払うかで結局揉める未来が見える

HTML/CSSの表現力を持たないFigmaをWeb開発に使うのは最初から間違いだし、スマートフォンアプリについては今やFigmaを使う必要も無いのでは、と思う。1年以上経ってまだ使ってるのが逆に興味深い。

課題意識は激しく同意。Specの維持コストは想像以上に高そう。

Rubyの人かと思った

仕様記述言語の目下の課題は説得力のある標準技術の不在なんだろうと思っているけど、そういう話はやったことある人がしたほうがいいやつだな

デザインの要件/要求定義と非機能機能の仕様化の話。「実装」が何を指してるのか曖昧で混乱した。Figmaもコードも実装の一種。構造の欠陥というより、詳細設計が無く、その設計根拠が曖昧なことが問題。仕様書化は良い

Rubyの人ではない

そもそも何で Figma と実装両方要るの? 生成するならなほさら

figmaの通り実装したら iOSのフォントサイズの変更に対応できなくて詰んだ

初期はFigmaレベルの柔軟さで検討と探索したいし、中後期からは構築を意識した作りにしたい。その隙間をどう埋めるかでLLM前提に文章化するのは面白い試み

合わせて読みたい。Storybookを使用した話だが課題感は同じ。Figmaを正とする運用に構造上無理が来ている。 ■「Figma と違う」をなくす Storybook 運用 https://zenn.dev/micin/articles/54cf1c16773056

figma挟まるの本当になんとかしてほしい。憲法にしたがる勢力がいる。

figmaは初期の柔軟に考えたいフェーズで使いたいのだと思うのだが、今のLLMは視覚的に思考するのでなく、文章として思考するので、そもそも相性が良くないと思っている。figmaからHTMLへ、でなく視覚的思考からHTMLへ

ClaudeDesignで作ったモックをFigmaに取り込んでMCPでつないで実装に回すのはどうかな？とGeminiに聞いたらClaudeDesignで作ったHTMLをそのままLLMに渡した方が(Code to Codeが)ええでって言ってた。Figma経由はノイズになるだけだってさ

俺も真剣に悩んで試行錯誤している。チームのスタッフが作成したPDFからHTMLを一発生成するプログラムを自作してみたりしているが、そもそもCloud Designで生成できる程度のデザインならFigmaの出番は無く悩む事もないのでは

via https://x.com/Matz_Tak/status/2078730900960129161

Claude Design生成レベルでOKならそもそも最初から不要。自分は手作業デザイン側の人間なので絶対必要

Spec駆動のUI開発でFigma言及するのは微妙かなと思った/書いた: https://araen.hatenablog.com/entry/2026/07/21/124518