Erez Reznikov

Juxのシニアデザイナー

 

プロダクトデザインと開発の世界を悩ませ続ける2つの根強い問題がある。ひとつは表面的な問題であり、それゆえ多くの注目を集め、時には合理的な解決策も数多く提案される。もうひとつは、より深く、より微妙で、見逃しやすいものだ。

まず最初の問題、ハンドオフの問題から始めよう。

実際、ハンドオフ・プロセスが大きな問題となる理由はいくつかある：

1. 摩擦は、ハンドオフにおけるミスの可能性とともに、実際にコード化された製品が、デザインツールに込められたデザイナーの意図と異なる原因となる。重要なのは、実際にコーディングされた製品を使った実際のユーザーの体験だけである。デザインが最終製品に完璧に反映されないと、プロセスは非効率的となり、士気を低下させる。
   
   
2. ハンドオフはデザイナーや開発者にとって多くの時間を浪費する。画面を正しく構築するための関連情報をすべてエンコードし、デコードするには、多くの精神的コストが必要だ。デザイナーは、仕様書、事例、コメント、文書で過剰なコミュニケーションをとらなければならない。一方、開発者は、偏執的で探偵レベルの警戒心でデザインを検査し、時には目を細めて見落としがないようにしなければならない。
   
   
3. デザインを開発者に渡し、一からコーディングしてもらう方法では、デザインデータが無駄になり、形骸化してしまう。一旦コードが稼動すると、デザインファイルと「現実」が一致することを確認するための終わりのない競争を生み出す。このペアリングが必然的に崩れると、不信の連鎖が生まれる。開発者は時代遅れのデザインを目にし、「現実」とはかけ離れていると思われる部分を無視して当然だと感じる。その結果、デザイナーは過敏になり、デザインと実装のミスマッチを探し回るようになる。これは、開発者がコンポーネントの最適解としてライブラリを選択し、それが指定されたスタイリングに適切にマッチしていない場合に頻繁に起こる。
   
   
4. デザインを引き渡す必要があるため、デザイナーは通常、それほど好きでも重要でもないことに時間を浪費せざるを得ない。テキスト・フィールドが製品内でどのようにレンダリングされるべきかをすべて指定し、文書化することは、創造性の本質ではない。特に、これは実際に作られるものではなく、使い捨てのデザインデータに過ぎない。フロントエンド開発者も同様に、喜びや意味の少ない作業に集中することを余儀なくされる。ビューポートが小さくなったり大きくなったりしたときに、どのようにリフローすべきかを確認するためにデザイナーを追いかけながら、すでにデザインされた画面をコードで再現するのも楽しくない。

これらの問題は非常に明確であるため、それを解決しようというモチベーションは昔も今も高い。

そして、市場が進化を許した解決策には、大まかに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つしかない。

1. Flash（マクロメディアが作成、アドビが継承、スティーブ・ジョブズが抹殺）
2. マイクロソフトのXAMLとWPFプラットフォームを使用したVisual Studio用ブレンド

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のネイティブ環境とは大きく異なるのである。

重力がない場合、すべてのもののデフォルトのモードは、Zインデックスの漸進的な順序で、他のものの上に絶対的に配置されることである。何も他のものを押さない。何も相互作用しない。パディングやマージンには何の意味もない。テキストが入力されても、ボックスが大きくなることはない。ビューポートがないため、ビューポートに関連する測定は使用できず、パーセントでさえほとんど使用されない。つまり、相対的なものはほとんど何もないのだ。

 
徐々に、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と呼ばれている。まだ日が浅く、道のりは長いが、私たちは真にラディカルな何かに向かっていると思う。

これらを読んで、さらに深く潜ってみよう：

1. ネイサン・カーティスの、ハンドオフのための仕様には何を含めるべきかについての素晴らしい記事。
2. Brad Frostの記事と、実際にコード化されたオブジェクトを使ったClaudeによるプロトタイピングのデモ。
3. 最も一般的なコンポーネントの実際のインタラクティブ性を知るには、Iain Beanによるこのリストを見てください。コンポーネントのページと素晴らしいデザインシステムのページがあります。
4. Shamsiのハンドオフに対する議論をまとめた記事を読んでください。
5. ジョー・アルテリオの、ツールと技術、そしてAIがそのすべてにどのような影響を与えるかについての深い記事を読んでください。
6. スマッシング・マガジンのヴィタリー・フリードマンによる「ハンドオフなし」に関する素晴らしい記事を読んでください。

英語版参照元：

https://uxdesign.cc/the-root-causes-for-the-dev-design-mismatch-4c66e0fa6740#c3b3-f4ad0c408f5e-reply

DMNでは、他にも様々なブログを「DMN Insight Blog」にて配信しております。
定期的に記事をご覧になられたい方は、ぜひご登録をお願いいたします！

→「DMN Insight Blog」メールマガジン登録