プロダクトデザインと開発の世界を悩ませ続ける2つの根強い問題がある。ひとつは表面的な問題であり、それゆえ多くの注目を集め、時には合理的な解決策も数多く提案される。もうひとつは、より深く、より微妙で、見逃しやすいものだ。
まず最初の問題、ハンドオフの問題から始めよう。
実際、ハンドオフ・プロセスが大きな問題となる理由はいくつかある：
これらの問題は非常に明確であるため、それを解決しようというモチベーションは昔も今も高い。
そして、市場が進化を許した解決策には、大まかに2つの方向性があった：
1つは、最も人気のあるキャンバス・デザイン・ツールへのヘルパー・アプリの流れだ。それは、検査を容易にするツール（Avocode、Zeplin、Simpli、Abstract）から始まった。その後、デザインツールに検査機能が追加された（FigmaのDev Mode、Sketch、XD、InVisionなど）。その後、特定のツールが登場した。ZeroheightやInVisionのDSMなどである。また、Anima、Locofy、その他の「Figma-to-HTML」ツールのように、多くのプラグインがSketchとFigmaのマーケットプレイスに登場した。
もうひとつの流れは、まったく性質の異なるものだった。それは、開発者の助けをほとんど借りることなく、それだけで「エンドツーエンドで出荷」できる新しい種類のデザインツールを作ることで、ハンドオフを完全になくそうとするものだった。現在、最も著名で強固なものはWebflowとFramerだろうが、25年ほど前のDreamweaverから始まったこれらのツールはたくさんある。
これらのノーコード／ローコード・ツールの最大の問題は、昔も今も、その構築方法がハンドオフをなくすだけでなく、開発者自身の必要性もなくすということだ。このことは、当然のことながら、これらのツールがデザイナーにエンド・ツー・エンドで構築させることができる製品の複雑さの上限をかなり低くしている。主にこの理由から、iOS/Androidやウェブアプリのネイティブ構築ツール（現段階ではPlay for iOSとDraftbitしか知らない）ではなく、ウェブサイト構築ツールが金銭的な成功を収めた。その最大の理由は、アプリでは論理的な複雑さがノーコード・ツールの能力を上回るからだ。ここ数年、Framer、Webflow、Builder.ioのようないくつかの橋渡しツールは、独自のプラグインを使用して、Figmaのようなキャンバスツールからのインポート機能として「橋渡し機能」を構築し始めた。
そして、ハンドオフ問題の解決策の空間は、その中心にトレードオフがある：
世界で最も複雑なアプリをデザインできる汎用的なキャンバスツールがあるが、デザインは単なるデザインデータであり、ハンドオフが必要である。あるいは、自分でデザインして開発する自由を与えてくれる専門的な構築ツールがあるが、作りたい製品の複雑さの上限は低い。
私が知る限り、異なる統一戦略をうまく取り入れたデザイン／開発ツールは2つしかない。
FlashにはActionScriptがあり、デザイナーは同じオブジェクトを自由にデザインし、開発者はActionScriptコマンドを使って論理的に操作することができた。このセットアップにより、関連するすべてのプロがそれぞれの仕事をこなせるようになった。デザイナーは、体験的にも視覚的にも重要なことに集中できた。開発者は、デザイナーが作成した既存のアセットをターゲットにすればよいので、開発者に何かを渡す必要はなかった。使い捨てのデザインデータもなく、ハンドオフもなく、複雑さに制限もない。Flashはあなたのためにコードを書こうとはしなかった。デザイナーが自分の得意な領域まで作り込んだ後、開発者がその続きをスムーズに引き継げるようにしていた。
Visual Studio用のBlendも似たようなものだったが、ファイル、構造、ロジックが異なっていた。ツイン環境のセットアップだった。デザイナーはデザインでき、Visual Studioの開発者はまったく同じアセットをターゲットにできる。繰り返しになるが、ハンドオフもなく、デザインデータも捨てられず、複雑さも制限されない。
ご存知のように、FlashはセキュリティとパフォーマンスがiPhoneと互換性がないために消滅した。BlendとVisual Studioは今やニッチで人気のないツールだ。この7年間、ツールの使用状況に関するあらゆる調査で、私はこれらの名前が挙がっているのを一度も見たことがない。その一方で、Figmaは製品デザインの市場シェアをほとんどすべて奪ってしまった。
このことから、最高のアプローチを持つツールも、他のさまざまな理由で失敗する可能性がないとは言い切れないという結論に達する。ビジネスとは、実に気まぐれで予測不可能なゲームなのだ。
さて、冒頭で述べたように、製品デザインと開発の世界を悩ませ続ける2つの根強い問題がある。より隠れた、しかしより重要な問題を探ってみよう：
素朴なキャンバスベースのツールは、膨大なデザイン特性をデザイナーから隠す。
この問題の影響は大きい。しかし、これはデザイナーを無関心でいさせようとする悪意ある陰謀ではない。デザイナーがその良い面しか見ていなかったトレードオフの悪い面なのだ。自由。そして、デザイナーは自由が大好きだ。私もそうだ。
この業界でいたるところに見られるようになったキャンバス・ツールを使って、私たちがどのように現在に至ったかを理解することは重要だ。
私たちは物理的なページから始めた。グラフィックデザイナーによって完璧に操作された紙、インク、色。ページは静的で、具体的で、明確に定義され、変化することはなかった。その後、Photoshop、Freehand、Corel Draw、Illustratorといったグラフィック・プログラムが登場し、スピードアップに貢献した。どれも、印刷物やほとんど静的なウェブ資産をデザインするのに役立った。その後、重要なことが起こった。コンピュータの画面サイズが多様化し始めたのだ。インターネットとネイティブアプリはそれに適応しなければならなかった。レスポンシブ・ユニットとルールが導入されたのだ。iPhoneとタブレットの登場後、それはさらにエスカレートした。しかし、デザイナーたち、つまりグラフィックデザイナーや初期のインタラクティブデザイナーたちは、ページのメタファーに夢中になった。当然のことながら、収益を生み出すデザイン・ツールは、彼らにまさにそれを与え続けた。最初はマウスとキーボードで、次に指のジェスチャーとスタイラスで）直接操作できる手軽さは、他の利点のために手放すには快適すぎた。その結果、デザイナーはツールによって自由を手に入れることを奨励される一方で、開発者が実装するための、レスポンシブで、システマティックで、スマートで、パラメトリックなデザインルールが求められるというミスマッチが生じた。
そして、ここが大きな分かれ目となる：
直感的で自由形式のグラフィック操作を最大化するツールと能力のセットは、首尾一貫した、堅牢で柔軟でパラメトリックなシステムを定義するのに役立つツールのセットとは正反対である。「重力」という最も基本的な概念について考えてみよう。
数年前にFigmaの自動レイアウトが導入されるまでの主なキャンバス・ツールでは、自由度が高いため、上にも下にも重力がなかった。ウェブやiOS、Androidのネイティブ環境とは大きく異なるのである。
徐々に、UIに適したツールが登場し始めた。Sketchは、XDとFigmaの両方に門戸を開いた。Sketchは、コンポーネント、オーバーライド、frame = divの一般的なマッピング、パラメータ化できる視覚的な品質（色、タイポグラフィ、エフェクト、Figmaのレイアウト・グリッド）を使用することで、これを実現した。それは新鮮な息吹だったが、ツールとともに課題も増えた。
ほとんどのテクニカルデザイナーは、自分でコードを実験し始めることにプレッシャーを感じていた。これは、UIプログラミングの現実の世界がどのように機能するのかについて、彼らのそれまでの素朴なスタンスに情報を与えたため、彼らにスーパーパワーを与えた。より堅牢なツールを手に入れようとする動きがあり、主要なツール（Sketch、Figma、XD）は、Flexboxの少し上限があるが友好的なバージョンであるAuto Layoutを導入した。それは、何でもできるキャンバスの宇宙の中に、DOMのような重力を持つミニ宇宙があり、その中に「オートレイアウトを有効にするフレーム」があるようなものだった。
これは革命的だった。デザイナーは、コンテンツがコンテナのサイズにどのような影響を与えるかを考えるようになった。レイアウトのリフローはより強固になり、ついにパディングが重要になった。
賢明なデザイナーは、UIのほとんどすべてをオートレイアウトで構築し始めた。
さて、少し考えてみようか...。
重力のない宇宙で、私たちはほとんどすべてのものを、重力のある微小な宇宙の束として創造している！デフォルトの現実が重力のあるもので、デフォルトで自動レイアウトされるようなものだったら、もっと簡単ではないだろうか？待って、それこそがウェブ、iOS、Androidがすでに機能している方法なのだ。
つまり、この10年間を見れば、進歩の軌跡は明らかなようだ。ツールは、デザイナーをシステマティックで柔軟なデザイン・ルール作りにどんどん近づけようとしている。
しかし
私たちはまだ、最大の、そして最も重要な飛躍の前にいる。
実際のUI構築（コンポーネントやページ）については、プロダクトデザイナーは愛着のあるフリーフォームのキャンバスを手放さなければならない。
私が見る限り、デジタル製品のデザインと構築は、それらがコード化されテストされるプラットフォームの制約に従わなければならない。デザイナーとして、私はフレックス、グリッド、パディング、マージン、すべての測定値のパーセント、ビューポート単位、その他多くのツールを使用するためのすべてのスペクトルを持たなければならない。ビューポートを簡単に変更し、影響を受ける必要のあるものすべてを見ることができなければならない。コンポーネントは、ステートとプロパティの違いを持つべきだ。そのバリアントはルールベースで設定されるべきで、すべてのバリアントをひとつずつ指定するべきではない。スタイルの代わりに、Design Tokensがすべてをパラメータ化するべきだ。エイリアスや複合トークンタイプ（タイポグラフィのような）を持つ、堅牢で多層的なトークン。
ツールのデフォルトは、私がより良い決断を下せるようにするものであって、より素敵でより簡単な決断を下せるようにするものではない。素朴で、混沌としていて、一貫性のない混乱したシステムに安易に陥らないようにしなければならない。気まぐれに作るのは簡単だが、維持するのは悪夢のようなシステムだ。インタラクティブなデジタル体験をデザインするとき、私たちが実際に何をしているのかを知るために、フランク・キメロが彼のエッセイ『ウェブの穀物』で書いていることを読んでみよう。この部分は、スクリーンのデザインをマスターすることがいかに難しいかについて書かれている：
複数の視点からの、小さく、個別的で、可変的な要素で構成される、未知の大きさを持つ境界のないのない表面は、瞬間を記録する読みやすい全体へと組み合わされる
これは、デジタル製品やウェブ、その他の場所の粒子である。だから、私たちが使うデザイン・ツールは、この「表面」を隠したり抽象化したりするのではなく、私たちが実際にこの「表面」と対話するのを助けるものでなければならない。今こそ、私たちはデザイナーとして成熟する時なのだ。プロセスの質、開発者との関係、製品、そして顧客の幸福は、すべて努力に値するものなのだ。
コラボレーションのためには、適切なツールを作らなければならない。ハンドオフではなく、真のコラボレーションだ。複雑な製品（これが大半を占めるだろう）には開発者が必要だからだ。魔法のAIの妖精の粉や、ノー・コード、ノー・デベロッパーの簡易ビルダーの夢を見ても、それを避けることはできない。
私は、破壊が順調に進んでいることを願っている。私は友人と一緒に、このような特性を持つツールを作ろうとしている。Juxと呼ばれている。まだ日が浅く、道のりは長いが、私たちは真にラディカルな何かに向かっていると思う。
これらを読んで、さらに深く潜ってみよう：
英語版参照元：
https://uxdesign.cc/the-root-causes-for-the-dev-design-mismatch-4c66e0fa6740#c3b3-f4ad0c408f5e-reply
DMNでは、他にも様々なブログを「DMN Insight Blog」にて配信しております。
定期的に記事をご覧になられたい方は、ぜひご登録をお願いいたします！
→「DMN Insight Blog」メールマガジン登録