デザイナーと開発者の間のギャップを埋める

公開: 2022-03-10

クイックサマリー↬UXPinは最近、「マージ」と呼ばれる新機能をリリースしました。このツールは、チームが期待する敏捷性と品質を向上させながら、設計と開発の溝を突破することを目的としています。この新しいテクノロジーにより、設計チーム全体とエンジニアリングチームがどのように連携するかについて再考する可能性があります。

過去数年間で、私たちのデザインツールが飛躍的に進化したことは周知の事実です。多くの人が優れたコンポーネント管理とプロトタイピングを行っているので、次にどのような大きな飛躍が起こるのか疑問に思われるかもしれません。

典型的なジレンマを見てみましょう。

あなたが設計システムチームの設計者であり、コンポーネントやバリアントを作成し、変更される場合とされない場合があるすべてのユースケースとプロパティを文書化するために何時間も費やしているとします。最終的に、大規模で複雑なコンポーネントを完成させ、開発者に提供します。

コードが同じUIであることをどうやって知ることができますか？本当にすべてのコンポーネントを監査する必要がありますか？絶えずレビューを行うオーバーヘッドなしに、設計されたものと開発されたものの間のこのギャップをどのように埋めるのですか？

これらすべてと、コンポーネントのさまざまな使用方法、レスポンシブWebの適切な間隔とデザインを人々に教えるのを支援する必要があります。もちろん、将来のユースケースのためにコンポーネントを更新する必要があります。

非常に多くのタッチポイントがあり、関係者がいます。設計システムに深く入り込むほど、すべての人にとってオーバーヘッドが増えるように感じます。さて、トンネルの先の光が輝いているようで、次の大きなことが進行中です。

すべての混沌の中に隠された宝石

私は最近、かなり長い間使用していなかったツール、つまりこのギャップを埋め、すべてのオーバーヘッドを最小限に抑えることを目的としたツール、UXPinを再検討する機会がありました。チームが期待する敏捷性と品質を向上させながら、設計と開発の溝を突破するのに役立つ「マージ」と呼ばれる新機能がリリースされました。この新しいテクノロジーにより、設計チームとエンジニアリングチーム全体がどのように連携し、ユースケースやコンポーネントの構築に取り組むかを再考する人もいるかもしれません。

古いプロセスでアウト

ほとんどの企業が今日採用している現在のプロセスを見ると、いくつかの明らかな欠陥があるため、かなり面倒な場合があります。新しいコンポーネントを最初から作成するときは、コンポーネントの基本レベルを設計し、バリアントを追加し、ドキュメントを作成し、ライブラリに公開して、開発者に提供します。プロセスをリストアップするのは時間がかかりますが、幸いなことに、一度だけ実行する必要があります（私たちは願っています）：

コンポーネントを作成および更新するための今日の一般的なプロセスを示す図 — コンポーネントを作成および更新するための一般的なプロセスのプレビュー。（大プレビュー）

では、コンポーネントを更新する必要がある場合はどうなりますか？新しいユースケースが登場しましたか、それとも境界線を丸みを帯びたものからかみそりのように鋭いものに変更することにしましたか？次に、バリアントをライブラリに追加し、（おそらく）ドキュメントを再度更新し、公開して開発者に提供する必要があります。ふぅ！コンポーネントのすべての再編成によって、設計者が途中で何も壊れないことを期待しましょう。

私はほとんど忘れていました、私たちはまだ開発ライブラリに更新を公開する必要があります！製品チームが期限を守るために独自の方法をとる前に、彼らが終了できることを期待しましょう。

新しいプロセスで

では、疑問に思われるかもしれませんが、UXPin Mergeのテクノロジーは、今日私たち全員が採用しているこのオーバーザトッププロセスにどのように役立つのでしょうか。さて、下の図を見てください。コンポーネントの作成に気付くかもしれませんが、バリアントは必要ありません（ほとんどの場合）。この新しいプロセスは、開発者との相乗的な関係により、自動レイアウトツールをいじる量を減らします。

コンポーネントを管理する新しいプロセスと方法を示す図 — 新しいプロセスのプレビューとコンポーネントを管理する別の方法。（大プレビュー）

文書化と実装に必要な詳細レベルを設計するだけで済みます。ボタンやその他のアトミックレベルのコンポーネントなどの単純なコンポーネントは、設計する必要がない場合があります。わずかなオーバーヘッドで開発をすぐに開始できるのに、なぜ2倍の作業を行うのに時間を無駄にするのでしょうか。ある意味で、私たちは完全に一周しました。静的コンポーネントがドキュメントにわずかな相互作用しか表示しなかったときの古い方法に戻ります。

ライブラリへの公開がプロセスの最後になっていることに注意してください。これは、開発者がコンポーネントを使い終えると、Mergeを利用してUXPinの設計者が利用できるようになり、もちろん、すべての製品開発者が同時にそれを利用できるようになるためです。

コンポーネントを更新する場合、シナリオによっては最初のステップをスキップできる場合があることを除いて、基本的に新しいものと同じです。たとえば、ボタンにアイコンを追加するオプションを追加するとします。これは設計が必要なものではありませんが、代わりに、開発中の新しい親友と連絡を取る必要があります。

この新しい関係は開発者と形成されますが、コンポーネントを設計者に正式にリリースする新しい方法は、開発者によるリリース時のみである可能性があります。製品設計者が製品開発者がコンポーネントを利用できるかどうかを尋ねる時代は終わりました。ライブラリにある場合は、開発中で利用可能であり、設計者はすぐに作業できます。

しかし、プロセスについては十分です。 UXPinMergeがどのように機能するかを見てみましょう。

ライブラリの管理

最良の部分は、ライブラリをGitHub、Bitbucket、GitLab（Reactコンポーネントでのみ機能）などのコードリポジトリから直接インポートできること、またはStorybookからでもインポートできることです。ライブラリが作成されると、ライブラリに名前を付けるオプションがあります。

ライブラリを追加するときに選択するオプションのスクリーンショット — （大プレビュー）

Storybookを使用してインポートする場合、プロセスは非常に簡単です。ライブラリのURLを取得するだけで、UXPinが残りの作業を行います。 Reactコンポーネントでは、CLIを使用して、UXPinライブラリの一意のトークンを指定することで公開されるコンポーネントを制御できます。

バージョン管理とテスト

設計者と設計システムチームの最大の関心事の1つは、バージョン管理です。ほとんどの懸念は、このUXPinのマージ機能で解決できます。簡単な絵を描きましょう：

今日、コンポーネントのアップグレードに着手すると、名前が変更されてクリーンアップされる可能性のある1つまたは複数のコンポーネントが破損する恐れが常にあります。コンポーネントの全体的な再構築が発生する可能性もあり、コンポーネントをアップグレードするか、古いコンポーネントを使用するかについて、（設計者側で）不安につながることがよくあります。

ただし、コンポーネントを開発する場合、プロパティが同じである限り、コンポーネントのレイアウトがどのように変更されるか、またはコンポーネントの実際のマークアップがどのように変更されるかは関係ありません。これにより、設計者は自信を持ってコンポーネントを最新バージョンにアップグレードできます。

もちろん、他のコーディングプロジェクトと同じように、コンポーネントが完全に台無しになるというまれな瞬間に、コンポーネントを簡単にロールバックして、古いバージョンのコンポーネントを再公開することができます。

更新のテスト

新しいコンポーネントやアップデートをテストする場合、今日ではそれほど簡単ではありません。既存のデザインライブラリを編集してテストすることはできません。これは誤って公開され、準備ができている他の更新をブロックする可能性があるためです。また、新しいファイルにコンポーネントを作成してテストし、レイヤーを壊さずに現在のライブラリへのマージを処理しようとするのも非常に面倒です。

私たちにとって幸運なことに、開発者はずっと前にこの問題を理解しており、それはUXPinのMergeテクノロジーにぴったり合っています。新しいコンポーネントをテストするときは、コードをフォークまたはブランチすることがすでにベストプラクティスであり、この新しいブランチはUXPin内のテスト環境に公開される可能性があります。あなたのチームはそれをテストするかもしれませんし、あなたはあなたの会社のベータテスターの小さなグループへのアクセスを許可するかもしれません。コンポーネントのテストと試行が完了すると、コンポーネントをすばやく導入して、ステッチなしでプライマリデザインライブラリに公開できます。

コードを使用した設計

では、現場のチームメンバーはどのように設計し、このテクノロジーは彼らにとって何を意味するのでしょうか。さて、あなたが尋ねてくれてうれしいです！プロダクトデザイナーの観点からは、大きな違いはありません。デザイナがMergeを使用して開発ライブラリのコンポーネントを使用する場合、コンポーネントごとにオレンジ色の六角形でマークされます。新しいものはすべて、開発者のライブラリとまったく同じように動作し続けます。

開発者からのコンポーネントには制限を定義できますが、良い方法です。一般的な問題は、アイコンをボタンコンポーネントでラップするのではなく、リンクとして使用することです。ライブラリのアイコンだけを使用すると、アイコンはロックされ、ユーザーはインタラクションを追加できなくなります。

または、下のアイコンボタンで操作できます。これにより、どのコンポーネントを操作する必要があり、どのコンポーネントを操作しないかを実際に調整および制御できます。標準の観点とアクセシビリティの両方の観点から。

これらのタイプの制限により、コンポーネントを適切な方法で使用する必要があることが設計システムチームに容易になり、オーバーライドすると、レイヤーパネルから何かがカスタムメイドであることが明らかになります。

渡す

開発者に渡す準備ができたら、完成したプロトタイプに各コンポーネントとその構成を表示して、開発者のツールにコピーして貼り付け、プロジェクトをすばやく構築できます。チームにコンポーネントライブラリがまだない場合は、UXPinにデフォルトのライブラリが付属しているか、UXPinで直接利用できるパブリックライブラリの一部を簡単にインポートできます。

アクセシビリティ

アクセシビリティについて言えば、見過ごされたり、すべてのmetaやariaタグなどのドキュメントを作成するのに十分な時間がないことがよくあります。設計者は入力する必要のあるタグを知らず、開発者は面倒な作業をやりたくありません。

UXPinを使用すると、ARIAラベルなど、インターフェイスに表示されない可能性のあるメタレベルのデータでさえ、複数のプロパティを公開できます。その後、設計者は必要なすべての情報（または、チームに情報を持っている場合はコピーライター）を入力でき、製品開発者が実装するオーバーヘッドはほとんどまたはまったくありません。

レイアウト、テンプレート、グリッド

タイトルを読むだけで、何が来るのかがわかります。今、椅子でバウンドしていると確信しています。私はそうだと思います。グリッド、レイアウト、さらにはページテンプレートを「コンポーネント」としてライブラリに取り込むことができます。これにより、ユーザーはコンポーネントをページのアクティブな領域に移動し、すべての間隔を開発ライブラリで処理できます。

一般的なテンプレート（ログイン画面、入力ページ、フォーム、プロファイルページなど）はすべて、ドラッグアンドドロップコンポーネントとしても利用できます。プロセスをスピードアップし、設計における人為的エラーを減らすことについて話してください！

最後に

飛躍する準備ができている場合は、ワークフローを改善するための新しいソフトウェアや新しいプロセスを試すのに遅すぎることはありません。結局のところ、私たちは皆、アジャイルで可能な限り養子縁組をしたいと思っています。チーム全体でより強力な関係を構築し、作業負荷を減らし、より効率的に作業しましょう。 UXPin Mergeのようなツールを使用すると、はるかにシームレスな作業環境に近づくことができます。