本文へ
ハクソク

世界を動かす技術を、日本語で。

Figmaが私たちをデザインし始めるとき

元記事: 原文(designsystems.international)

概要

  • Figma の初期体験とその後の普及による影響
  • デザインツールの エンジニアリング志向 への懸念
  • Auto Layout や Dev Mode の具体例による問題提起
  • デザインの自由度と創造性の縮小への警鐘
  • ツールと働き方 のバランスの重要性

Figmaがデザイン現場にもたらした変化と課題

  • 2013年、Dylan FieldによるFigmaの初期プロトタイプ体験
  • ペンツール の操作性の良さに感銘を受けるも、ブラウザベースの本質的な革新性を見逃し
  • 現在、Figmaは リモートデザイン実践 の中核ツール
  • Figma 無しでは完全リモートなデザイン体制の構築は困難だった現実
  • Dylan Field の成功と自身の立場の対比

Figmaによるエンジニアリング志向の強化とその問題点

  • 過去5年間 でFigmaの方向性に対する懸念の増大
  • Smart Components、 Variables、 Auto Layout、 Interactive Prototypes などの機能追加
  • エンジニアリングとの パリティ を目指す動きへの疑問
  • アイデアの広がりが必要な初期段階で 表現の幅 が狭まる危険性

Auto Layout導入によるデザイン自由度の制限

  • Auto Layout はDOMライクなレイアウト機構
  • 構造が固まったデザインファイルには利点
  • 多くのチームが 初期段階からAuto Layout で全画面デザインを構築
  • 結果として 自由な配置やレイアウトの試行 が困難に
  • 要素の自由なドラッグ や奇抜なレイアウトの組み合わせが制限
  • 小さな変更も レイアウトとの格闘 になる事例の増加

Dev Modeによるプロセスの分断と問題意識

  • Dev Mode はデザインと実装の橋渡しを目指す機能
  • デザインの 仕上げと実装の分離 を強化
  • 複雑なプロトタイプ 作成に多大な時間を費やす現状
  • 実際にはコードでしか体験できない設計要素の多さ
  • 「 Ready for dev」という考え方が 開発者の主体性 を奪う危険性

早すぎる最適化とデザイン空間の狭窄

  • デザイナーが 早期に意思決定 しすぎる傾向の助長
  • アイデアを 過度に構造化 し、展開前に制約してしまうリスク
  • 柔軟な発見の余地が 一貫性と構造 に取って代わる現象
  • デジタルデザインの モノカルチャー化 への懸念
  • 共有された意図ではなく、 共通の制約 による均質化の進行

デザイナーとエンジニアの協働とツールの在り方

  • 15年間 にわたりデザイナーとエンジニアの協働を推進
  • 学際的協働 とは、異なる視点を持ち寄ること
  • デザイナーが エンジニア的思考 に傾倒しすぎることへの警鐘
  • Figma の強力さと同時に、 構造重視の働き方 への誘導に注意
  • デザインは 秩序 ではなく、 問い・遊び・混沌 から始まるべき
  • ツールは 自由な発見と実験 の余地を残す必要性
  • 最初から全てが整然としていると、 グリッドの外側 の発見が失われる危険性

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

うーん、FigmaのAuto Layoutについてはあんまり詳しくないけど、なんかこの不満はちょっと的外れな気がするな。デザインは印刷デザインとは違うし、リフロー可能なメディアのためにデザインするなら、その制約に合わせてデザインしなきゃいけないよ。いいプロトタイピングツールは、一時的にその制約を超えることを許してくれるべきだけど、ウェブやモバイルデザイナーがその制約をエンジニアの問題だと無視するのは、活版印刷の制約を型屋の問題だと無視するのと同じくらい不適切だよ。うまくいかないから。

└

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

└

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

└

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

└

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

ソフトウェア開発者と同じように、既存のパターンでユーザーのニーズに応えるのと、新しいパターンを探求するのは違うんだよね。消費者向けや企業向けの製品の大半は、既存のデザインパターンで作るべきだと思う。Figmaはそれに向いてる。一方で、探求的デザインは新しいパターンを考えることに関するもの。ほとんどのこの作業は面白いけど、実用的ではないことが多いし、誰かが素晴らしいものを思いついても、それがどこでどう使われるべきかはっきりしないことが多い。私の経験では、実際にこれをうまくやってる会社は少数で、残りは既存の慣習に従った方がいいと思う。あと、探求的デザインをする人は、スキルセットが広くて、ペンと紙、物理プロトタイプ、3Dモデリング、コンピュータグラフィックス、動画制作、ソフトウェア開発など、もっと幅広く柔軟なツールを使うことが多い。多くのデザイナーは前者のために雇われるけど、実際には後者をやりたいと思ってるのが課題だね。

いや、問題はここにあるんだ。Figmaは足りないんだよ。スケッチするための自由なデザインツールが必要なら、他のを使えばいい。何百もあるから。私はデザインシステムをデザインツールの中で実装して、複数のブレイクポイント、コンテナクエリ、モード、バリアントを使ってプロトタイプを作りたいんだ。Figmaじゃその仕事は無理だよ。Material 3のFigmaファイルで変数タブを開いたことある？カクカクして、「このタブは応答しません」ってなる。長い変数リストをほとんど見ることができないし、複数のモードで編集なんて無理。変数名が長すぎないことを願うよ、だってUIのほとんどの部分で見えなくなるから。Figmaの問題は、デザイナーにはエンジニアっぽすぎることじゃなくて、エンジニアにはデザイナーっぽすぎることなんだ。Figmaでデザインシステムを実装するのに1ヶ月かけたけど、結局諦めてコードでやったよ。Figmaだと、コードでデザインシステムを構築する際の欠点（深くネストされたアイテムが何かを動かしたり変えたりすると壊れる）に直面するけど、利点は何も得られない。Figmaは半端な（なんとなくウェブっぽい）アイデアの山で、実装もひどい。何度も、理由もわからずに動かなくなったことがある。99%の確率でバグで、アプリを再読み込みしなきゃいけない。もしFigmaよりいいものがあれば、教えてほしい。今はFigmaでスケッチして、Style Dictionaryの拡張機能でデザインシステムを作ってるよ。

└

そうだね。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がリモートコラボレーションを表現するのがすごく好き。もっとこういうのが見たいな。

Hacker Newsで議論の続きを見る