コードを使用した設計：設計への最新のアプローチ（開発の課題）

公開: 2022-03-10

簡単な要約↬ツールとプロセスの両方で何年にもわたる革新の後、設計と開発の間の闘争は依然として現実のものです。この記事では、設計から開発プロセスを改善するためのベストプラクティスと、Mergeテクノロジを利用したUXPinなどの最先端のソリューションが変更の促進にどのように役立つかに焦点を当てています。

設計者と開発者の間の協力による摩擦は、業界自体と同じくらい古くから進化し続ける議論を煽っています。私たちは今日の場所に長い道のりを歩んできました。ツールが変更されました。私たちのプロセスと方法論は変わりました。しかし、根本的な問題はしばしば同じままでした。

チームのタイプや規模に関係なく、私がよく目にする問題の1つは、信頼できる真実の情報源を維持することです。最高の人材を採用し、実績のある業界標準のソリューションを使用することでさえ、何かが間違いなくもっとうまくできたはずだということに嫌悪感を抱くことがよくあります。悪名高い「最終バージョン」は、多くの場合、技術文書、設計ファイル、スプレッドシート、およびその他の場所に広がっています。 それらすべての同期を維持することは、通常、退屈で困難な作業です。

注：この記事は、UXPinチームと共同で作成されました。 この記事で紹介する例は、UXPinアプリで作成されています。 一部の機能は有料プランでのみご利用いただけます。 UXPinの価格設定の完全な概要は、ここにあります。

デザインツールの問題

信頼できる情報源を維持することについて言えば、設計ツールの非効率性は、最も身に着けている問題点の1つとして示されることがよくあります。最新の設計ツールは進化しており、多大な努力を払って急速に進化しています。しかし、設計と開発の間の架け橋を築くということになると、それらの努力の多くが欠陥のある仮定に基づいているという印象を受けることは珍しくありません。

最新の設計ツールのほとんどは、後で設計を実装するために使用されるテクノロジーとは異なるモデルに基づいています。それらはグラフィックエディタとして構築され、そのように動作します。デザインツールでレイアウトを構築および処理する方法は、CSS、JavaScript、およびその他のプログラミング言語が提供するものとは最終的に異なります。 ベクトル（またはラスター）グラフィックスを使用してユーザーインターフェイスを構築することは、作成したものを後でコードに変換する方法とかどうかを常に推測することです。

デザイナーは、自分たちの作品が意図したとおりに実装されていないことを嘆くことがよくあります。ピクセルパーフェクトなデザインに向けた勇敢な努力でさえ、すべての問題を解決するわけではありません。設計ツールでは、考えられるすべてのケースを想像してカバーすることはほぼ不可能です。さまざまな状態のサポート、コピーの変更、さまざまなビューポートサイズ、画面解像度など、すべてをカバーするにはあまりにも多くの変更変数を提供するだけです。

その上、いくつかの技術的な制約と制限があります。事前の開発経験のない設計者であるため、すべての技術的要因を考慮することは非常に困難です。入力のすべての可能な状態を覚えておいてください。ブラウザサポートの制限を理解します。作業のパフォーマンスへの影響を予測します。少なくとも色のコントラストやフォントサイズよりもはるかに広い意味で、アクセシビリティのためのデザイン。これらの課題を認識し、必要な悪としてある程度の当て推量を受け入れます。

しかし、開発者は推測に頼らなければならないこともよくあります。グラフィックエディタでモックアップされたユーザーインターフェイスが、すべての質問に答えることはめったにありません。それは私たちがすでに持っているものと同じコンポーネントですか、そうではありませんか？別の州として扱うべきですか、それとも別のエンティティとして扱うべきですか？ X、Y、またはZの場合、このデザインはどのように動作する必要がありますか？より速く、より安くなるので、少し違った方法で作成できますか？皮肉なことに、そもそも誰がデザインを作成したかを尋ねることは必ずしも役立つとは限りません。まれではありませんが、彼らも知りません。

そして通常、これは成長する欲求不満の範囲が終わるところではありません。それで、他にもみんながいるから。マネージャー、利害関係者、チームリーダー、営業担当者。製品のさまざまな部分が存在するすべてのツールや場所の中で注意力と精神的能力が薄く伸びているため、彼らは他の誰よりもそれをよく理解するのに苦労しています。

プロトタイプをナビゲートし、特定の機能と状態が設計から欠落している理由を理解し、欠落しているもの、進行中の作業、およびスコープから意識的に除外されているものを区別することはほとんど不可能だと感じます。すでに行われたことをすばやく繰り返し、フィードバックを視覚化し、独自のアイデアを提示することも、ほとんど不可能だと感じています。皮肉なことに、ますます洗練されたツールとプロセスは、設計者と開発者がよりよく連携することを目的としています。彼らは基準をさらに高く設定し、他の人々のプロセスへの積極的な参加をさらに困難にしました。

ソリューション

私たちの業界の数え切れないほどの頭が、新しいパラダイム、ツール、および概念をもたらすこれらの問題に取り組むことに取り組んできました。そして確かに、多くのことがより良い方向に変化しました。簡単に見てみましょう、そして概説された課題に向けた最も一般的なアプローチのいくつかは何ですか。

コーディングデザイナー

「設計者はコーディングする必要がありますか？」は、記事、会議の講演、その他すべてのメディアを通じて何度も議論された決まり文句の質問であり、議論の中で新しい声が時折安定して現れます。設計者が「コーディングの方法を知っている」（そもそも「コーディングの方法を知っている」の定義方法にこだわるのではなく）場合、技術を取り入れた設計を作成する方が簡単であるという一般的な仮定があります。制約を考慮に入れ、実装が簡単です。

さらに進んで、実装において積極的な役割を果たすべきだと言う人もいます。その段階で、設計ツールを完全に使用せずに「コードで設計」するのは無意味ではないという結論に飛びつくのは簡単です。

アイデアが聞こえるかもしれませんが、それが実際に証明されることはめったにありません。私が知っているすべての最高のコーディングデザイナーは、まだデザインツールを使用しています。そして、それは間違いなく技術的なスキルの欠如によるものではありません。アイデア、スケッチ、実際のものの構築の違いを強調することが重要である理由を説明する。

事前定義されたスタイルやコンポーネントを利用して、デザインツールに煩わされることなく、完全に機能するインターフェイスをすばやく構築するなど、 「コードでのデザイン」の有効なユースケースが多数ある限り、デザインツールによって制約のない視覚的な自由が約束されます。まだ否定できない価値があります。多くの人は、デザインツールが提供する形式で新しいアイデアをスケッチする方が簡単で、創造的なプロセスの性質により適していると感じています。そして、それはすぐに変わることはありません。デザインツールは、存続し、永久に存続するためにここにあります。

設計システム

過去数年間のデジタルデザインの世界で最も大きな流行語の1つであるデザインシステムの大きな使命は、常にまさにそれでした。当て推量と繰り返しを制限し、効率と保守性を向上させ、信頼できる情報源を統合することです。 FluentやMaterialDesignなどの企業システムは、アイデアを支持し、大小のプレーヤーの両方にコンセプトを採用する勢いをもたらすために、多くの取り組みを行ってきました。そして確かに、設計システムは、より良い方向に大きく変化するのに役立ちました。設計原則、パターン、およびコンポーネントの定義されたコレクションを開発するためのより構造化されたアプローチは、無数の企業がより優れた、より保守しやすい製品を構築するのに役立ちました。

しかし、いくつかの課題はすぐには解決されませんでした。人気のある設計ツールで設計システムを設計することは、信頼できる唯一の情報源を実現するための多くの努力を妨げました。代わりに、統合されていても、設計ソースと開発ソースという2つの別個の互換性のないソースに存在する、多数のシステムが作成されています。通常、2つの間の相互の同等性を維持することは、設計システムが最初に解決しようとしていた最も嫌われているすべての問題点を繰り返して、苦痛な雑用であることがわかります。

設計とコードの統合

設計システムの保守性の問題を解決するために、ソリューションの別の波がすぐに到着しました。デザイントークンなどの概念が注目を集め始めています。デザインファイルから特定の値を直接フェッチできるオープンAPIなど、コードの状態をデザインと同期するためのものもあります。その他は、たとえばコードから設計ツールでコンポーネントを生成することによって、設計をコードと同期させるためのものでした。

これらのアイデアのうち、広く採用されたものはほとんどありません。これはおそらく、まだ非常に不完全なソリューションの必要なエントリコストに対する可能な利益の疑わしい利点によるものです。デザインを自動的にコードに変換することは、ほとんどのプロフェッショナルなユースケースにとって依然として大きな課題です。既存のコードをデザインとマージできるソリューションも大幅に制限されています。

たとえば、コード化されたコンポーネントを設計ツールにインポートできるソリューションは、ソースに視覚的に忠実であっても、そのようなコンポーネントの動作を完全に複製することはできません。今までなし。

デザインとコードをUXPinとマージする

成熟したフル機能のデザインアプリであるUXPinは、デザインツールの段階では新しいプレーヤーではありません。しかし、Mergeテクノロジーなどの最近の進歩は、設計および開発ツールについての考え方を変える可能性があるものです。

UXPinとMergeテクノロジーを使用すると、コードを1行も記述せずに、ビジュアルと機能の両方を維持することで、実際のライブコンポーネントを設計に取り入れることができます。コンポーネントは、デザインファイルに埋め込まれていても、実際の対応物とまったく同じように動作する必要があります。これは、コンポーネントが実際の対応物であるためです。これにより、コードとデザインの間でシームレスなパリティを実現できるだけでなく、2つを中断することなく同期させることができます。

UXPinは、gitリポジトリに保存されているReactコンポーネントのデザインライブラリをサポートしているほか、Storybookとの堅牢な統合により、ほとんどすべての一般的なフロントエンドフレームワークのコンポーネントを使用できます。自分で試してみたい場合は、UXPinWebサイトでアクセスをリクエストできます。

マージテクノロジーを使用してUXPinへのアクセスをリクエストする→

ライブコンポーネントをUXPinのデザインとマージするには、驚くほど簡単な手順が必要です。適切なコンポーネントを見つけたら、クリックするだけでデザインキャンバスに配置できます。デザイン内の他のオブジェクトと同じように動作します。特別なのは、デザインの不可欠な部分であるにもかかわらず、コードの場合と同じように使用およびカスタマイズできることです。

UXPinを使用すると、コンポーネントのプロパティにアクセスしたり、コンポーネントの値や変数を変更したり、独自のデータを入力したりできます。プロトタイプを開始すると、コンポーネントは期待どおりに動作し、すべての動作と相互作用を維持する必要があります。

マージテクノロジーを使用したUXPinでのコンポーネントの追加とカスタマイズ

デザインでは、無制限の数のライブラリとデザインシステムを組み合わせて組み合わせることができます。独自のライブラリを追加するだけでなく、マテリアルデザイン、Fluent UI、Carbonなど、すぐに利用できるさまざまなオープンソースライブラリから選択することもできます。

コンポーネントを「そのまま」使用するということは、ビューポートの幅など、コンテキストの変化に応じてコンポーネントが動作する必要があることも意味します。言い換えれば、そのようなコンポーネントは完全に応答性があり、適応性があります。

注： UXPinを使用して真にレスポンシブなデザインを構築する方法について詳しく知りたい場合は、この記事を確認することを強くお勧めします。

コンテキストは、テーマを意味する場合もあります。デザインツールでテーマ化可能なデザインシステムを構築（および維持）しようとした人、または少なくとも明るいテーマと暗いテーマを簡単に切り替えることができるシステムを作成しようとした人は誰でも、それがどれほど難しいタスクであり、どれほど不完全であるかを知っています。結果は通常です。すぐに使用できるテーマに最適化された設計ツールはなく、その問題を解決することを目的とした利用可能なプラグインは、完全に解決するにはほど遠いものです。

マージテクノロジーを備えたUXPinは実際のライブコンポーネントを使用するため、実際のライブコンポーネントとしてテーマを設定することもできます。必要な数のテーマを作成できるだけでなく、ドロップダウンから適切なテーマを選択するのと同じくらいすばやくテーマを切り替えることができます。（UXPinを使用したテーマの切り替えについて詳しくは、こちらをご覧ください。）

利点

マージテクノロジを備えたUXPinにより、これまでほとんど見られなかった設計とコード間の同等レベルが可能になります。設計プロセスのソースに忠実であることは、プロセスのすべての側面に非の打ちどころのない利点をもたらします。デザイナーは、自分たちが作ったものが誤解されたり、誤って開発されたりしないことを知って、自信を持ってデザインすることができます。開発者は、設計をコードに変換して、不明確なエッジケースやカバーされていないシナリオを混乱させる必要はありません。その上、誰もが作業に参加し、基盤となるコードについてまったく知識がなくても、ライブコンポーネントを使用してアイデアのプロトタイプをすばやく作成できます。より民主的で参加型のプロセスを達成することは、はるかに手の届くところにあります。

デザインをコードとマージすると、デザイナーがチームの他の構成員と協力する方法が改善されるだけでなく、内部のプロセスとプラクティスが改善される可能性があります。マージテクノロジーを備えたUXPinは、DesignOpsと呼ばれることもある、大規模な設計作業の最適化に焦点を当てている人々にとって、ゲームチェンジャーになる可能性があります。

適切な正しい情報源を使用すると、チーム内のさまざまな人々によって作成された作業間の一貫性を維持することが不可解に容易になり、それらを調整し、ツールの共同セットとともに適切な問題を解決するのに役立ちます。いくつかの一方的なバリエーションを持つ「切り離されたシンボル」はもうありません。

結論として、私たちが得るのは大幅な時間の節約です。設計者は、コンポーネントを自信を持って使用し、機能をすぐに使用できるため、時間を節約できます。コンポーネントの変更に応じて設計ファイルを更新したり、チームの他のメンバーにビジョンを説明するために作業や「手を振る」ことを文書化したりする必要はありません。開発者は、推測や余分な調整を必要としない、即座に消化できる方法で設計者からコンポーネントを取得することにより、時間を節約します。

テストとQAの責任者は、設計とコード間の不整合を探し出し、意図したとおりに移植が行われたかどうかを判断する時間を節約します。利害関係者や他のチームメンバーは、そのようなチームのより効率的な管理とより簡単なナビゲーションを通じて時間を節約します。摩擦が少なく、シームレスなプロセスにより、チームメンバー間のフラストレーションが制限されます。

短所

ただし、これらのメリットを活用するには、いくらかの入場料がかかります。プロセスでUXPinなどのツールを効率的に使用するには、既存の設計システムまたはコンポーネントライブラリを配置する必要があります。または、常にある程度の制限を提供するオープンソースシステムの1つに基づいて作業を行うこともできます。

ただし、そもそも設計システムの構築に取り組んでいる場合は、プロセスでUXPinとMergeテクノロジを利用することで、追加コストはほとんどまたはまったく発生しません。十分に構築された設計システムでは、UXPinの採用は苦労するべきではありませんが、そのようなシフトのメリットは劇的に証明される可能性があります。

概要

デザインシステムの普及により、メディア開発者やデザイナーが取り組む問題に対処しました。現在、メディアを変換するだけでなく、メディアの作成方法も変換する、より統一されたプロセスへの移行を観察できます。その変化には、適切なツールを使用することが重要です。 UXPin with Mergeテクノロジは、設計とライブコードコンポーネントを組み合わせて、設計と開発が動作するドメイン間のギャップを大幅に狭めることができる設計ツールです。

次はどこ？

UXPinマージ：ストーリーブックの統合
Storybookの統合が製品チームにどのように役立つかを学び、試してみてください。
UXPinマージ：Git統合
アクセスをリクエストして、Gitリポジトリとの統合がどのように機能するかを確認します。
UXPinMergeに関する短いビデオ説明者
「インタラクティブデザインシステム：ジョンソン＆ジョンソンとのウェビナー」の一環として。
コードを使用した設計：UXPinマージチュートリアル
マージテクノロジーを使用したUXPinの入門チュートリアル。
UXPinマージによるレスポンシブデザイン
マージテクノロジーを使用したUXPinでの完全なレスポンシブエクスペリエンスのプロトタイピングガイド。