投稿者: UXPin

デザインチームが選んだインターフェースデザインに役立つUI/UX記事10選をご覧ください。デザイン界の最新ニュース、避けるべきミス、そして維持すべきベストプラクティスのすべてをご紹介しています。

Continue reading UX担当者に役立つUI/UX デザイン記事 10選

デザイナーとしての最終目標は、エンドユーザーのために優れた製品を作ることなので、デベロッパーとの連携は、各製品の構築において最も重要です。

デザイナーが製品のコンセプトを考え、モックアップやプロトタイプを作成します。そして最終デザインをデベロッパーに引き渡し、プロジェクトが始動するのです。

この場合、最終的なデザインを開発チームに渡した時点でデザイナーの役割は終わることになっています。

ところが実際には、製品開発のライフサイクルにおいて、この「デザイナー　→　デベロッパー」という直線的なシステムはほとんど存在しません。以下がその理由です：

• プロジェクトを成功させるには、コンセプトから発売まで、デザイナーが製品開発の一翼を担う必要があるから
• 最初のプロトタイプが最終製品になることはほとんどないため、デザイナーはユーザーや他のチームメンバーからのレビューに基づいて変更を加えるフォローアップを行う必要があり、また、然るべきユーザー体験のために、特定のデザイン要素を実行する方法についてのガイダンスも出さないといけないから

そのため、立ち上げ時であっても、デザイナーとデベロッパーのリアルタイムでの連携は、あらゆるプロジェクトの成功に欠かせません。開発チームは、機能面でも、デザイン要素を変更したり、他のチームメンバーからレビューを受けたりと、何度もやりやりとりが必要なのです。

これは私たちデザイナーにとっては大したことではないのですが、もちろん、連携のためのツールや機能はたくさんあります。

ただ、デベロッパーとの連携が必要になったとき、以下が原因でちょっと困ったことが出てくるんです：

• デザイナーはコードを扱わないし、デベロッパーはデザインリソースを扱わない
• チームとしては、仕事を成し遂げるのに色々とツールを使用する

一緒に作業をしないといけないチームが、同じツールを使ってもいないのにどうやって連携できるのでしょうか。

つまるところ、共通の基盤である「信頼できる唯一の情報源（Single source of truth）」を見つけることが解決策となるのです。

UXPinにMergeテクノロジーを搭載すれば、デベロッパーとデザイナーが協力してプロジェクトを稼働させることができます。UXPin Mergeでは、gitの要素をUXPinデザインエディタに取り込むことができるので、サイトに既に存在するコンポーネントや他のチームが開発したコンポーネントを使って簡単にデザインすることができます。その上、これらのコンポーネントは生産準備完了なので、インタラクションを追加したり、標準に合っているかどうか心配したりする必要もありません。また、コンポーネントは視覚的に表示されるので、コーディングの方法やGitを調べる必要もありませんが、一方、デベロッパーにとっては、製品を作るために使える準備万端のコードなのです。Gitとの統合の他に、UXPinはStorybookライブラリと同期して、そこからすぐに使えるUIコンポーネントを提供することもできます。

Gitとは

Gitは、専門用語では「バージョン管理ソフトウェア」と呼ばれ、デベロッパーがコードに加えた変更を追跡し、将来参照できるように保存するプログラムのことをいいます。

Gitで、デベロッパーは以前の変更点を再検討することができます。ソースコード全体をいじることなく、コードの変更を取り消すことができ、要するに、問題を早く発見して修正できるのです。

Gitは、オープンソースの無料ソフトウェアで、個人のパソコンにダウンロードして使えます。 PC上でローカルに動作するため、一度インストールすれば、インターネットに接続しなくても使用可能です。

「Photoshopの［履歴パネル］がどのように動作するか」が、デザイナーにとって、Gitがどのように機能するかの最も近い例でしょうか。Photoshopでは、最終的な画像を得るために追加したすべての移動、追加、編集、効果、その他すべてが履歴パネルに一覧表示されますよね。これは、Gitがデベロッパーがチームに対して行うことと同じです。

Githubとは

Githubは、専門用語では「クラウドベースのレポジトリホスティングサービス」と呼ばれ、Gitリソースをすべて保存し、アクセスするためのオンラインインターフェイスのことをいいます。GitHubの代替品としては、BitBucketとGitLabがよく知られています。

デベロッパーが自分のコードに加えた編集は、すべてGitによって追跡・保存され、Githubの中に保存され、デベロッパーはオンラインになれば、このコードにアクセスできます。デベロッパーは、自分のコードを他のデベロッパーと共有し、フィードバックや編集を受けることができますし、他のデベロッパーが共有したコードを変更することも可能です。

​​デベロッパーは、Githubでシームレスに連携して互いのコードに取り組めるのです。Gitがウェブサイトの画像や文書、ファイルやページを表すとすれば、Githubはこういったリソース（Gitレポ）を保存するホスティングプロバイダーと言えるでしょう。 

GitとGithubの違い：まとめ

1. Gitは、他の人と共有することなく、変更の追跡をオフラインででき、デベロッパーがプロジェクトに加えたすべての変更のスナップショットや紙の証跡を作成し、その「変更」を保存します。一方、Githubはクラウドベースで、どちらかというと連携のためのプラットフォームであり、Gitで作成された「紙の痕跡やスナップショット」が保存され、他のデベロッパーが連携するためにアクセスできるようにする場所です。
2. Gitは完全に無料のオープンソースであり、一方Githubは、個人や小規模な組織向けの無料プランと、大規模なチームや企業向けの有料プランがあります。

​​つまり、この2つのツールは、連携やソフトウェア構築、変更の記録や巻き戻しでエラーを素早く修正するのをサポートするための補完的なツールなのです。

デザイナーがGitを必要な時

Git は主にデベロッパーや IT チームのために作られたものかもしれませんが、最近ではデザイナーがデベロッパーと密接に仕事をする必要があるため、今やGit はデザイナーにとっても重要なツールになりました。

ただ、どの時点でGitがデザイナーにとって便利なものになるのでしょうか？

• モックアップやプロトタイプを作成し、最終的な作品をデベロッパーに出さないといけない時。
• すでに生産している製品や発売済みの製品に、特定のデザイン変更が必要な時。
• 優れたユーザー体験の実現のために、特定のデザイン要素をどのように実行するかについてデベロッパーに指導する必要がある時。
• デザインチームと開発チームの両方がアクセスできる、共有可能なワークフローの構築が必要な時。

デザイナーのためのGit：GitとGithubの使い分け

最近、誰もがGithubを使うようになりましたが、それはGitから始まるのです。Gitを使えば、デベロッパーと共有できるデザインワークフローの構築ができ、実行された変更や追加はすべて保存され、過去にさかのぼって変更することができます。

Gitではこのような紙の痕跡が残せ、Githubには他のデザイナーと連携してデベロッパーとデザインの共有ができます。

GitHubのデスクトップアプリを使ったGitHubの始め方

Github はブラウザから利用することもできますが、デスクトップアプリにも素晴らしい機能があるので、お使いのOSからでもプロジェクトに貢献することができるんです。ここでは、その始め方について説明します。

アカウントの開き方

まず、https://github.co.jp/ に行き、ホームページの右上にある “サインアップ “ボタンをクリックします。

画面の指示に従って、メールアドレスを入力し、以下のようにパスワードを作成してください。

次のステップでは、メールにアクセスして、次のウィンドウにGithubからのローンチコードを入力します。これで、最初のダッシュボードが表示されます。

ダッシュボードでは、プロフィール写真の横にある矢印をクリックすると表示される「設定」パネルで、2ファクタ認証の設定やプロフィールの経歴を追加できます。

Githubをパソコンにインストールする方法

Githubのデスクトップアプリを入手するには、https://desktop.github.com/に行き、オペレーティングシステムを選択してダウンロードする必要があります。

ダウンロード完了後、アプリケーションを起動し、画面の指示に従ってデスクトップにGithubをインストールします。

アプリのインストールが完了すると、ウェルカムページが表示されます。

インストールすると、デスクトップアプリをアカウントにリンクするための注意事項が表示されることがあります （GithubではこれをAuthenticationと呼んでいます。）

これらの注意事項が表示されない場合は、以下のデスクトップアプリケーションと、先ほど作成したGithubアカウントをリンクさせる方法をご覧ください：

ステップ1：デスクトップアプリの左上にある「ファイル」をクリックし、ドロップダウンリストより「オプション」を選択します。

ステップ2：「Github.co.jp」オプションの横にある「サインイン」をクリックします。その際、ブラウザを使ってサインインするよう表示されます。

ステップ3：「ブラウザで続ける」をクリックして続行します。ブラウザでGithub.co.jpにアクセスし、メール/ユーザー名とパスワードを入力します。

情報を入力すると、ブラウザがこのリンクをデスクトップアプリケーションで開くように表示されます。

ステップ4：ブラウザのプロンプトから「GitHubデスクトップを開く」をクリックします。

すると、デスクトップアプリケーションに戻り、以下のようにユーザー名が表示されます。

この時点で、レポジトリの作成や、Githubアカウント使用の準備ができました。ここでは、そのやり方を説明します。

Githubでレポジトリを作成する方法

まず、レポジトリとは何でしょうか？

平たく言えば、レポジトリとは、物を預ける、あるいは保管する受け皿や場所のことです。これは、Gitにおけるレポジトリも同じです。

Git レポジトリは、コードの保存場所です。このレポジトリには、コード化されたデザインのバージョンがあり、必要なときにいつでもアクセスできます。Git レポジトリは、プロジェクトに加えられた変更をすべて追跡し、プロジェクトのライフサイクル全体を通じて変更の履歴を構築します。

プロジェクトが始動したら、以下の方法でプロジェクト内にレポ/レポジトリを作成します。

デスクトップアプリケーションがまだ新しいので、トップページに何をするかのオプションのリストが表示されます。

ステップ1：「ハードディスクに新しいリポジトリを作成する 」をクリックします。

ステップ2：次にポップアップするウィンドウで、リポジトリ名と説明を入力し、「レポジトリ を作成する」をクリックします。

ステップ3：次のステップでは、作成したレポジトリは自身のPC上でのみ利用できることがわかり、自身でレポジトリの閲覧・編集ができます。

他のチームとの連携や、自身の作品を他の人に見てもらうには、このレポジトリの公開が必要です。

「レポジトリを公開する」をクリックして、公開します。

そうすると、Gitレポジトリが稼動します。

Github で変更をコミットする方法

Github で変更をコミットするということは、自身が実行した変更や編集をローカルレポジトリに保存するということです。

例えば、オンラインでGoogle Docに変更を加えた場合、その変更は自動的に保存されますが、Githubの場合はそのようにならないので、この変更の保存、つまり変更のコミットが必要になります。

変更をコミットする方法は次のとおりです。

ステップ1：Githubのデスクトップアプリで、「Github上のレポジトリページをブラウザで開く」ウィンドウの横にある「Githubで見る」をクリックします。

これにより、ブラウザ上でレポジトリのページが表示され、変更を行うことができます。

ステップ2：開いたブラウザウィンドウで、レポジトリウィンドウの右上にある「編集」のアイコンをクリックします。

次のウィンドウでレポジトリが開かれるので、希望する変更を全て行います。

ステップ3: すべての変更が終わったら、下にスクロールして 「変更をコミット」 をクリックします。

これで、すべての変更点がレポジトリに保存されました。

ブランチとは：統合の方法

ちょうど木の枝が幹から突き出ているように、Githubのブランチも同じです。ブランチは、レポジトリに加えるコードや変更のセットであり、独自の名前がついています。

デザイナーやデベロッパーは、メインのレポジトリを触ることなく、新しい機能やアイデアを試したり、特定の問題を修正したりするのにブランチを使います。

ブランチは、チームが行った他の変更に影響を与えたくない特定の事柄について作業する時に作られます。

ブランチの作成と統合の仕方

ブランチを作成した機能構築やバグ修正が完了したら、それを元のプロジェクトに追加する方法として、統合することが挙げられます。

Githubのデスクトップアプリのトップメニューにある「ブランチ」ボタンに移動します。それをクリックすると、ドロップダウンのオプションのリストが表示されます。

ブランチ作成は、「新規ブランチ」をクリックし、手順に従います。別々のブランチを統合する場合は、「現在のブランチに統合する」メニューを使います。

その他のデザイナー向けのGitライブラリdesigners?

Githubは、Gitレポジトリをホスティングするためのライブラリやデータベースであることは、もうお分かりでしょう。また、他の人と連携する場所でもありますね。

ただ、Gitリソースをホスティングするためのライブラリやデータベースのプラットフォームは、Githubだけではありません。ここでは、その他の利用可能なオプションをご紹介します。

Gitlab

インターフェースや使い勝手が Github に最も近く、オープンソースのツールであるGitlabは、多くのチームに利用されている優秀なGitライブラリです。課題追跡、コード管理、Wiki、とりわけ多くの開発ツールとの継続的な統合など、多くの機能を備えています。

Bitbucket

もう一つのよくできたたGitRepository・ホスティング・プラットフォームは、Bitbucketです。Windows、Mac、Android、iOS、Linuxで利用できるBitbucketは、コミット履歴、コード管理、ブランチ比較などの優れた機能を持ち、デベロッパーには最大５人に無料で無制限のプライベート・レポジトリが提供されます。

その他の著名なGit Repositoryホスティング・プラットフォーム

• SourceForge
• Launchpad
• Google Cloud Source Repositories
• AWS CodeCommit
• Apache Allura

まとめ

GitとGithubは、デベロッパーチームのために作られましたが、デザイナーにとっても、これらのツールはプロジェクトを作成・保存するだけでなく、デベロッパーチームとの連携においても威力を発揮するようになりました。もしあなたがデザイナーで、デベロッパーと一緒に仕事をしていたり、きれいなワークフローを保ちたいと思っているなら、GitとGithubはそういったことをするのにピッタリなツールです。UXPin Mergeの技術でGitリポジトリを活用し、デザインと開発のプロセスを一緒にして、信頼できる唯一の情報源（Single source of truth）を使えることを忘れないでください。

多くの企業がそうであるように、ジョンソン・エンド・ジョンソンもかつてはスタイルガイドを利用して、デザイナーが承認された言語やコンポーネントを使用するようにしていました。スタイルガイドは今でもブランドのUX向上に役立ちますが、大企業のニーズとは必ずしも一致しません。また、新しいテクノロジーを使えば、中小企業でも スタイルガイド からデザインシステムへの移行が可能になります。

2021年4月のウェビナーでは、J&Jエクスペリエンス・デザイン・エキスパート・サービス・リーダーのBen Shectmanが、彼と彼のチームが、企業の既存のスタイルガイドを使って、どのようにしてインタラクティブなデザインシステムを構築したかを語っています。これは、適切なプロセスとソフトウェアを採用することで、デザイン部門をより効果的かつ効率的にすることができるという教訓です。

なぜ スタイルガイド ではなくデザインシステムが必要なのか

Johnson & Johnson社では、長年にわたり、PDFファイルで保存されたスタイルガイドを使用していました。静的な スタイルガイド のデメリットは、インタラクティブなデザインシステムのメリットを知っている経験豊富なUXデザイナーには明らかでした。

スタイルガイドをデザインシステムに変換することで得られるメリットには、次のようなものがあります。

• コンポーネントの標準化されたバージョンをすべて保存する場所を作ることができる。
• 製品に一貫性を持たせることで、ユーザーが新機能に遭遇したときに何を期待すればよいかがわかる。
• 社員がアクセスできるデザインコンポーネントを管理し、プロトタイプに追加することができる。
• 誰もが承認されていない機能を追加できないように、あるいは少なくとも極めて困難にするためのガードレールを確立する。
• 設計者が作業中にドラッグ＆ドロップできるコンポーネントを提供することで、効率化を図る。

デザインシステムを導入することで、担当者は製品の設計・開発をよりコントロールできるようになる。一方、設計者は、標準化された承認済みの部品を使って仕事をすることで、設計者や開発者の仕事が楽になる。

スタイルガイドからアトミックデザインによるデザインシステムへ

Ben Shectmanと彼のチームは、J&Jのスタイルガイドをアトミックデザインを用いたデザインシステムに変換することを選択した。アトミックデザインは、ジョンソン・エンド・ジョンソンのような大企業に効果的です。アトミックデザインの利点は以下の通りです：

• デザイナーが部品を組み合わせて新しい製品を作ることができる。
• 製品全体の一貫性を維持するために、一貫性のある定義済みの部品を使用することができる。
• 既存のデザインを更新するのに、それほど手間がかからない。

アトミックデザインを用いてデザインシステムを構築する場合、5つの複雑なレイヤーに焦点を当てることができます：

• 原子—最も基本的で必要不可欠な要素であり、すべてのものを作るために使用される。
• 分子—複数の原子から構成される、より複雑な構造体。
• 生物—分子が組み合わさってできたもの（検索フィールドやナビバーなどの例）。
• テンプレート—デザイナーが生物を配置するための管理された環境。
• ページ—デザイナーのアプローチが期待通りの結果をもたらしたかどうかを示す最終製品。

これらのレベルの複雑さはいずれも重要な役割を果たしていますが、多くのデザインマネージャーはチームにテンプレートを与えることに集中しています。

デザイナー、開発者、その他の従業員のためのテンプレートを作る

デザインシステムには、ユーザーの潜在的なニーズを満たすために、できるだけ多くのテンプレートを用意するのが理想的です。デザイナーは、適切なテンプレートを開き、そこに生物をドラッグすることができるべきです。テンプレートによっては、生物の機能に応じて特定の場所にはめ込むことができます。

J&JのデザイナーであるGil Gerard Austria氏は、テンプレートを使用して、古い社員検索ツールを会社の好みに合った、優れた機能を持つデザインに変えた例を紹介しています。

UXPinでインタラクティブなデザインシステムを構築

UXPin makes it easier than UXPinを使えば、時代遅れのスタイルガイドからインタラクティブなデザインシステムへの移行がこれまで以上に簡単になります。J&JのチームがUXPinを選んだ理由のひとつは、クリック可能なコンポーネントをすべて表示するインタラクティブデザインシステムの構築に役立ち、ユーザーテストにも大いに役立つからです。

インタラクティブなデザインシステムは、不正確さ、インタラクションに反応しない静的なデザイン、各コンポーネントがどのように見えるか、どのように動作するかを確定するまでの開発者とのやりとりの回数など、画像ベースのデザインで起こりがちな多くの問題を解決します。

デザインシステムを次のレベルへ

コンポーネントと最終製品の整合性を保ち、デザイナーと開発者の行き来を減らし、ハンドオフ・ドリフトをなくしたいなら、コード・コンポーネントを使ったデザインを選択すべきです。

当社のMergeテクノロジーにより、デザイナーは開発者がすでに作成し、コード化されたデザインシステムに保存されているUIコードコンポーネントを使用することができます。これにより、製品チーム全体にとって、究極の単一情報源となります。デザイナーは、製品化可能なコンポーネントをデザインに使用し、後に開発者は製品を構築するためにライブラリを検索するだけです。さらに、インポートされたコンポーネントは完全にインタラクティブなので、プロトタイプが最終製品と同じように見え、動作することになります！

デザインシステムやコードベースのデザインの利点について書かれていても、UXPin Mergeのようなツールがどれほど効果的であるかは必ずしも伝わりません。UXPin Mergeへのアクセスをリクエストして、その利点を体験してください。

今日のテクノロジーは、複数の分野にまたがるチーム間でコラボレーション文化を育むことをかつてないほど容易にしています。しかし、ここで問題が発生します。雇用者の75％がチームワークとコラボレーションは重要であると言う一方で、従業員の39％は自分の組織では人々が十分にコラボレーションしていないと考えています。

今回の記事では、以下のことについてお話します。

• 製品の設計・開発時のチームコラボレーションに影響を与えるもの
• ソフトウェア製品の設計において、デザイナーと開発者の作業をより効果的にするためのヒント
• インスピレーションを得られる2つのブランドを共有します。

それでは早速、ご紹介しましょう。

製品開発とデザイン – チーム連携に影響を与える重要な要素

チーム同士の協力体制に影響を与えるのは、大きく分けて2つの分野です。それは、「役割の数と種類」と「デザインチームの設定」です。以下、それらを見ていきましょう。

デザインチームの役割の数と種類

デザインチームは非常に多様な集団です。組織によっては、1人だけの場合もあれば、大人数の場合もあり、各人がそれぞれのスキルを持って共同プロジェクトに参加します。

コラボレーションを深めるためには、ライター、ソーシャルメディア担当者、データアナリスト、SEO担当者など、医療従事者やマーケティングチームのようなメンバーを想定するのが現実的です。

同様に、デザインチームでは、ユーザビリティリサーチやUXデザインから、ユーザーインターフェース、ブランディング、インタラクションデザインまで、各人が独自の役割と専門性を持っています。それぞれの役割によって、社内外のプロジェクトとの関わり方も異なります。

チーム構成

デザイナーと開発者がどのように協働するかを左右するデザインチームの構造には、4つの種類があります。 1. 一元化

中央集権的な構造は、単一の意思決定者と中央の拠点を特徴とします。最も伝統的で認知度の高いチームマネジメントの方法です。UXのVPまたはディレクターにレポートするデザインマネージャーの下で、デザイナーの別々のチームが別々のプロジェクトに取り組みます。一元化されたチームは、よりシンプルなコラボレーションとプロジェクトのビジョンを共有することができますが、デザインプロセスが遅くなり、チームがサイロ化してしまいます。

2. 組み込み

組み込み型のチームは、分散型のチームとも呼ばれ、クロスファンクショナルで、異なる部門のメンバーが特定のプロジェクトに協力して取り組みます。例えば、新しいWebサイトのランディングページを制作する場合、デザイナー、バックエンド開発者、コピーライターなどが参加し、すべてをプロジェクトマネージャーが監督します。エンベデッドチームは、各メンバーの専門性に焦点を当てながら、全社的な信頼関係とコラボレーションを促進しますが、必ずしも効率的とは言えない構造です。

3. フレキシブル

フレキシブルなチームは、集中型と組み込み型のハイブリッドなヒエラルキーを形成しています。デザイナーは、多分野にわたるクロスファンクショナルなチームの一員として、チームリーダーの下で日々の仕事をこなし、デザインマネージャーが管理します。柔軟性のあるチームは、デザインプロセスに集中し、一般的に目的の変化に対応するのに適しています。しかし、この構造は指揮系統の混乱を招くことが多いため、大規模な組織には不向きと言えるでしょう。

4. 契約関係

契約チームとは、フリーランサーとして雇用された外部のデザイナーのことです。この方法は、社内にフルタイムのチームを置く予算がない企業や、既存のチームが特定のプロジェクトで追加のサポートを必要とする場合によく使われます。

デザインチームと開発チームのコラボレーションを向上させる5つのヒント

それでは次に、製品の設計・開発を改善し、チーム間の協力関係を高めるためのヒントをご紹介します。

1. 現在のチーム構成と必要なものを評価する

階層やプロセスは組織によって異なるため、自分のチームに最適なタイプを探ることが重要です。そのためには、以下のような様々な要素が必要となります。

• 会社の規模
• デザインチームの規模
• デザインプロジェクトの種類
• デザインプロジェクトの要求

主要なステークホルダーと一緒に、現在のセットアップを検証します。どこがうまくいっていて、どこを改善すべきかを検討します。可能であれば、プロセスについて貴重な洞察を持っている「現場」の人々からフィードバックを得てください。

これは、組織改革の重要な側面であり、見落とされがちなことです。チーム全体で変革を成功させるためには、変革の影響を受ける人々からの賛同を得ることが重要です。

例えば、現在、組み込み型のデザインチームを配置しているが、複数のメンバーが同じ作業を繰り返していることが明らかになったとします。これではコストがかかり非効率的です（社員のモラルにも良い影響を与えません）。そのような場合は、デザインを重視したスピーディーなコラボレーションを可能にする、より柔軟なアプローチを試すべきかもしれません。

チーム編成を変更する前には、必ず達成可能な明確な目的を持ってください。

2. デザイナーは誰に報告するのかを知るべき

すべてのビジネスにおいて、すべてのチームには明確な指揮系統が必要です。それは、期待値を確立し、効率性を高め、サポートを求めるチームメンバーを助けるためです。

これは、フレキシブルなチーム構成の中で、デザイナーにとって最大の問題の一つです。デザイナーは、プロジェクトマネージャーに相談すべきか、自分のデザインチームのリーダーに相談すべきか迷ってしまいます。このような問題は、手っ取り早い解決策や「次回は…」という約束で簡単に片付けられてしまいますが、本当の問題には対処できません。

その原因は、コミュニケーションの欠如にあります。ある広範な調査によると、従業員との間の不適切なコミュニケーションが原因で、1社あたり年間平均6,240万ドルの損失が発生している」とのことです。そして、コミュニケーション不足はコラボレーションを阻害します。チームは、方向性も目的もオーナーシップもビジョンも共有されていないプロジェクトが延々と続くという状況に直面し、誰もイノベーションを起こそうとしません。

ここでは、中央集権型や組み込み型のチームタイプに移行するのが望ましいかもしれません。どちらも明確なコマンドヒエラルキーがあり、単一のチーム内（集中型）、または部門を超えたコラボレーション（埋め込み型）のいずれかでコミュニケーションを改善することができます。

3. デザイナーが軽視されていると感じないようにする

デザイナーの数よりも開発者の数の方が多いのが現状です。企業の規模や仕事の種類は関係ありません。複数の開発者がいるチームにデザイナーが一人しかいない場合、デザイナーの意見が無視されるというリスクが常にあります。感情的に言えば、それは共感性の欠如です。

開発者とデザイナーは、まったく異なる角度からプロジェクトに取り組みます。そもそも相手が見ているものを見ていないので、理解することができないのです。

士気とチームの結束力を高めるためには、このような状況に迅速に対処する必要があります。チームメンバー全員の役割、責任、権限を明確にすることで、相互尊重を促します。また、各メンバーの専門分野を明確にすることも大切です。そうすれば、デザイナーがデザインの専門家の視点から発言したり、主張したりすることが容易になります。

4. デザイナーが適切なツールにアクセスできるようにする

テクノロジーの進歩により、チームが世界中のどこにいても、コラボレーションはかつてないほど速く、早く、簡単になりました。しかし、間違ったテクノロジーを選択したり、時代遅れのツールや旧式のシステムを維持することは、コストのかかる決断となります。効率性。競争力。イノベーション。これらのすべては、デザイナーが最高のツールだけでなく、適切なツールを利用できるようにすることで向上します。

UXPin Mergeは、デザイナーと開発者の共同作業の方法を変えます。

そして、車輪を再発明する（あるいは、少なくとも組織内のすべてのシステムとプロセスをオーバーホールする）のではなく、チームを同じ生態圏に引き入れることで効果を発揮します。

強力なGitとStorybookの統合機能を備え、デザイナーは同じReactコンポーネントやStorybookに存在するコンポーネントを使用することができます。これにより、デザイナーは開発者と同じテクノロジーを使用し、最終製品との完全な一貫性を実現できます。同時に、デザイナーは、きれいなUI、完璧なUX、没入感のあるインタラクションなど、自分にとって最も重要なことに集中することができます。

エンドツーエンドのコラボレーションツールとして、Merge はスムーズなコミュニケーションを促進します。デザイナーと開発者が同じシステムを使用しているので、デザインプロセスを通じて両者がシームレスに連携することができます。

5. 開発者のハンドオフのためのフレームワーク

ハンドオフプロセスは、製品開発・設計サイクルの中で最も重要なステージのひとつです。

とりわけ、良いハンドオフは次のような効果があります：

• 回避可能な直前の変更を止める
• 明確な次のステップを伝える
• 効率化と遅延の防止
• 情報格差をなくす
• 早期に主要なステークホルダーから社内の賛同を得る
• 各チームがお互いに何を必要としているかを明確にする。

チームが開発とデザインを同時に行う際、スムーズな移行を実現するためには、明確さとアクセシビリティが優先されます。

ソフトウェア製品開発 – チーム間の効果的なコラボレーションの例

ここでは、ソフトウェア製品のデザインについて、参考になるブランドをいくつかご紹介します。

セグメント

顧客データプラットフォームのリーディングカンパニーであるSegmentは、ソフトウェア製品の開発プロセスを「ディスカバリー」と「デリバリー」の2つのステージに分けています。

発見段階では、プロダクトマネージャーとデザイナーが中心となり、あるアイデアが意味を持つかどうかを検討します。この段階では、製品の使い勝手やお客様にとっての価値、実現可能かどうか、そしてコストはどれくらいかを検討します。

この段階では、ユーザーからのフィードバック、データ分析、競合分析、実験などが行われます。セグメント社では、ディスカバリーは「お客様が直面している問題を共有理解するためのものであり、具体的にどのように解決するかは（まだ）示されていない」としています。

デリバリーフェーズは、「ディスカバリー」が成功し、デザイナーとエンジニアの混合チームに引き渡された後に発生します。この段階では、製品がどのように機能するかに焦点が当てられます。この段階では、ソフトウェアの設計記述を満たすインタラクティブなプロトタイプを作成して文書化し、製品の見た目や操作性、動作を開発者に示します。また、チームは最終的なデザインを確認し、同意します。

Airbnb

Airbnb社は、ソフトウェア製品の設計ツールとしてコードを考え始めた最初の企業の一つです。

元CDOのAlex Schleiferは、同社のコラボレーションギャップを認識し、「デザインツールとしてのコードに投資しています」と述べています。レイアウトやデザインだけではなく、ロジックやデータも含めた資産を扱うことに近づけています。これにより、エンジニアとデザイナーの間のギャップを埋めることができ、設計仕様書やレッドラインの必要性や、ビジョンと現実の間のステップを減らすことができます」。

ツールはその一例です。デザイン技術者のルーク・カーターによると、「シュライファーは、デザイナーがアプリのさまざまなビューをすべて見ることができるツールがあったらいいねと、ふと口にしたんです。これはまさに、Airbnbの複数の部署に影響を与えることができるプロジェクトだと感じました」。

カーターの予感は正しかった。

製品開発とデザインの取り組みは、ソフトウェア開発者だけでなく、会社全体に役立つものでした。エンジニアはAir/shotsを使ってローンチ前に実験的なフローを実行できることに気付き、ローカリゼーション部門はこのツールを使って翻訳を改善することが容易になった。

まとめ

今日の企業では、コラボレーションが生産性と効率性を高め、働きがいある職場環境を作るために役立つことを知りながらもそれを達成するのが難しいと感じています。

費用がかさむ、複雑すぎる。

しかし、その目標を達成するには、費用がかかりすぎるし、複雑すぎる。

確かに、AirbnbのAir/shotのようなプロジェクトを成功させるには時間がかかります。しかし、UXPin Mergeのようなパワフルで使いやすいテクノロジーを導入すれば、誰でもそれを利用することができます。

Mergeは、チーム間の真のコラボレーションを容易にし、創造性を抑制することなくワークフローとコミュニケーションを簡素化します。ぜひ一度試してみてください。

ランディングページに動きを加えることは、エンゲージメントの向上やコンバージョンの増加に一役買っています。しかし、動きのメリットはランディングページに限ったことではありません。人々は、動画、インタラクション、GIFなど、あらゆる種類の動きを含むデジタル製品に、より興味を持ちます。

多くの人にとって、GIFはソーシャルメディアのコメントに反応するための楽しい方法となっています。しかし、デジタルデザインの世界では、GIFはより重要な役割を担っています。ウェブページ、スマートフォンアプリ、その他のデジタル製品を制作する際には、プロトタイプにGIFを追加することの利点について学びたいと思うでしょう。

おすすめの記事: Design Trends 2021

プロトタイプにGIFを加えることのメリット

プロトタイプにGIFを追加することで得られる最も大きなメリットは、ユーザーのエンゲージメントが向上することです。多くの人は、静止した画像よりも動きのある画像を好みます。動きのある画像は、ユーザーがインタラクションできると、さらに魅力的になります。例えば、画面を下にスクロールすると、海の波のGIFが動くかもしれません。

ウェブページやモバイルプロトタイプにGIFを使用することで、エンゲージメントが向上しますが、メリットはそれだけではありません。モーションデザインとインタラクションを組み合わせることで、次のようなことが可能になります。

• ユーザーが意思決定をするために必要な情報を表示することで、製品の機能性を向上させる。
• ユーザーが製品に触れる時間を増やすことで、広告収入や売上、権威を高めることができる。
• 消費者をセールスファネルに導き、購入を完了させる可能性を高める。
• ユーザーに永続的な印象を与えることで、ブランドの認知度を高めることができます。

動画を使ってエンゲージメントを高めるのはどうでしょうか？

動画でもユーザーとのエンゲージメントを高めることができます。場合によっては、QuicktimeのMOVファイルをデザインに追加することも意味があります。

しかし、動画の使用にはデメリットもあります。例えば、以下のようなものです：

• クリエイティブチームが動画を作るには、GIFよりもずっと時間がかかることがあります。
• 高品質な動画を作るためには、カメラや編集、人材などに多くの費用が必要になるかもしれません。
• 帯域の限られた消費者や、モバイルネットワークでしか製品にアクセスできない消費者には届かないかもしれません。

また、GIFを選択することにはいくつかの利点があります。多くの人がGIFを好む理由は以下の通りです：

• ファイルサイズが小さいので、より多くのユーザーのニーズに応えることができます。
• ファイルサイズが小さく、より多くのユーザーのニーズに応えることができる。
• ほとんどのデザイナーは、魅力的で効果的なGIFを迅速かつ安価に作成することができます。

常にGIFが正しい選択というわけではありませんが、ファイルサイズを小さくしたい場合や、長編コンテンツではなく少量の情報でユーザーを惹きつけたい場合には、動画よりもGIFの方が適していることが多いようです。

おすすめの記事: Create Clickable Prototypes

UXPinでプロトタイプにアニメーションGIFを追加する

UXPinでは、デザインにGIFを簡単に追加することができます。GIFを追加するには、ファイルからアップロードするか、Sketchなどのソフトウェアから他のアセットをインポートするのと同じ手順を踏むことになります。

インタラクションで状態をコントロール

エンゲージメントを高めるために、インタラクションの間で状態をコントロールする簡単な方法も用意されています。インタラクションで状態をコントロールするということは、カーソルを合わせると画像が変化するということです。例えば、ホテルの部屋探しを支援するアプリでは、部屋の写真を表示し、マウスカーソルが画像に重なると情報（価格、広さ、アメニティなど）に切り替えることができます。

また、クリックすると拡大するアコーディオンメニューや、数秒ごとに写真が入れ替わるカルーセルなどのインタラクションを使用することもできます。これらはすべて、あなたのプロトタイプをよりリアルに感じさせるためのものです。

GIFでユーザーを魅了するデジタル製品の例

UXPinでより良いプロトタイピングを

UXPinでは、製品をリリースするずっと前に、プロトタイプにGIFを追加することができます。インタラクティブで魅力的なプロトタイピングにより、リリース後のデザインを正確に体験することができます。プロトタイプが動作することがわかれば、製品が動作することもわかります。

UXPinの14日間のトライアルで、その簡単さと魅力をお試しください。今すぐご登録ください。

UXPinのMerge新機能、「Storybook連携」 を試してみました。

今回はFixel株式会社様より、「Storybook統合」をお試し頂いた感想を共有いただきました。

紹介文

UXPinからMergeの未公開新機能を試すチャンスを頂いたので、弊社のエンジニアがデザイナーとエンジニアのコラボレーションという視点での感想を以下にまとめました。（ちなみに、この文書の公開時点では対象機能は既に公開されておりますので、いつでも試すことは可能です。） 

参考までに、UXPinは既に広く使われているデザインツールで、UXPinだけでデザインとプ ロトタイプの作成が可能です。他のデザインツールとの差と言えば、コードに親和性が高いツールで、プロトタイプでできることが他のデザインツールに比べ柔軟かつ多様であることです。 

MergeはさらにReactベースのUIコンポーネントを実装したコードを使って、UXPinと同じ使い方で迅速にプロトタイプの作成ができるツールです。そのMergeに今回新機能として「Storybookとの統合」を追加したわけです。 

MergeをStorybookと連携して使うための作業フローは下記のようになります。

1. UXPinを使ってデザイン
2. Storybookを使ってUIコンポーネントを作成 
3. Storybookで作成されたUIコンポーネントをGithubのリポジトリーに保存 
4. MergeからGithubのリポジトリーにアクセスしてUIコンポーネントを取得 
5. 取得したUIコンポーネントを使ってプロトタイプを作成し、新しいUIの有効性を検証 
6. 検証が終わったプロトタイプを参考に、プログラミングを行う 

上記の手順からStorybookの使用は必須ではありません。しかし、Storybookが既にあ る程度普及されている現状を踏まえると、Storybookとの連携は賢いアプローチだと思います。 

ここで一つできてないのは、手順５で作成したプロトタイプを手順６のプログラミングの段階でそのまま使えないことです。つまり、実際のプロダクト用のコードは自前で作成する必要があります。それはまた将来の拡張に期待を寄せるしかないです。 

恐らく、Mergeの狙いはデザインシステムから提供されるUIコンポーネントを使って迅速に プロトタイプを作成することだと思われます。 

UXPinの方々とも議論しましたが、Mergeが活用されると期待される環境は、ある程度規模のある企業で、かつデザインシステムの専門チームと各プロダクトのチームが分かれているところです。デザインシステムのチームがデザインシステムを作成し、彼らが作成したUIコンポーネントを企業内で配ります。そうすると、個別プロダクトチームのデザイナーやエンジニアはそれらのUIコンポーネントをMergeに取り込んで各プロダクト用のプロトタイプを迅速に作ることができます。それによってプロダクト開発の速度を上げるだけでなく、同じ企業としてのデザインの一貫性を保つことができます。UXPinはこの一貫性を大事に考えており、Mergeは「A Single Source of Truth（信頼できる唯一の情報源）」をモットーに開発されたと言われました。 

２回に渡るレクチャー、試用とその前後の議論を通して、UXPin社の方々にも話しましたが、まだデザインシステムがそれほど広く浸透しておらず、デザインシステムを活用した社内でのデザイン展開の事例も少ない日本では使えるシーンが（まだ）限られるかと思いますが、一部の大手企業、あるいは先進的な技術スタートアップには有効なソリューションだと思われます。UXPinの方々も日本マーケットへの展開に力を入れており、近々良い事例も出てくるのではないかと思われます。弊社も今回の試用で得た知識と経験を元に、UXPinやMergeの活躍が期待できる案件を見つけ、実導入と活用を行ってみたいと思って おります。 

以下は、弊社のデザイナー兼エンジニアであり、Mergeのテストを主に担当したJacoboのMergeに関する記事です。より詳しい情報を知りたい方はお読みください。 

UXPinのMergeとStorybookの統合を試してみる  

はじめに 

数ヶ月前、私はUXPinのMergeの新機能をテストするために提供されたトライアルを試用する機会がありました。以下の記事では、デザイナーとエンジニアのコラボレーションを促進するための次のステップについて、私自身の印象や考えをいくつか紹介します。 

以前の記事をご覧になれば、私がデザイナーとエンジニアの間の境界線上にいることがお分かりいただけると思います。職業や学歴はさておき、私の日々の仕事は、アプリケーション内のプロセスに対する論理的な解決策を見つけ出し、それをコードに書くことです。デザイナーとしての役割は、ユーザーの視点を考慮した上で、エクスペリエンスを向上させるために何らかの変更を加えることです。単に見た目の美しさを追求するだけではなく、ユーザーが目的に集中できるように、アプリケーションのインターフェースを気づかれないように工夫することが求められます。

私は、ユーザーエクスペリエンスの修正に関連して、コーディングの繰り返しに苦労することがあります。コンソールにエラーが表示されて、作ったものを調整する必要がある場合もありますが、プログラムが客観的に動作している場合は別の問題が発生します。その場合、何かおかしいと感じているユーザーがいるかもしれません。確かに、デザインルールやグッドプラクティス、様々な理論を適用することはできますが、お客様が変更を求めているときに理論書を突きつけられても、お客様はあまりいい顔をしないでしょう。このような場合に、デザインシステムが役立ちます。テスト済みで動作するコンポーネントがすでにあるので、それらの内部の細部について深く考えることなく、新しいアプリケーションのビルディングブロックとして使用することができます。

UXPin Mergeは、デザインシステムの既製コンポーネントをUI/UXプロトタイピングツールと接続することで、デザインシステムをプロジェクトのデザインプロトタイピングフェーズに導入することを目的としています。この方法では、デザイナーは実際にコード化されたパーツを使用して、迅速なプロトタイピングを行うことができます。UXPin Mergeのモットーは「A single source of truth（信頼できる唯一の情報源）」であり、プロトタイプで見るものはデザインと実際に動くコードを組み合わせたものだからです。

UXPinとデザインからコーディングへのステップ 

まず、UXPinについて説明します。UXPinは、Sketch、AdobeXD、FigmaのようなUI/UXデザインツールで、これらのツールのコアとなるコンセプトを共有し、ユーザーが簡単に使い熟せることができます。UXPinの場合は、ワイヤフレームから高度なプロトタイプまで全てをカバーしています。

殆どのデザインツールでは、デザイナーがツール上で作成したものと、実際にコードで作られた開発環境での成果物との間で、大きな格差が生じます。例えば、FigmaのInspect tabのようなツールを使えば、あるオブジェクトの背後にあるCSSがどのように見えるかを大まかに確認することができます。しかし、これはデザインされたものとコード化されたもので必ずしも正確に一致しているわけではありません。

デザイナーとエンジニアは、少なくとも日々の仕事で使用するツールに関しては、本質的に2つの異なる世界のようなものです。両者の間に共通項を見出そうとすると、延々と会議が続き、様々なコミュニケーションツールにメッセージが散らばってしまいます。UXPin Mergeは、チーム全体が参照できる「信頼できる唯一の情報源」を持つことで、まさにこの問題を解決しようとしているのです。

UXPin Mergeのアプローチ 

UXPin Mergeは、UXPinの拡張機能のようなものです。基本的に、Merge が行うことは UXPin にGITもしくはStorybookにあるコード化されたデザインシステムを組み込むことです。そのため、デザイナーはモックアップやプロトタイプに実際のコンポーネントを使用することができます。これらのコンポーネントはデザインシステムのリポジトリにすでにコード化されており、デザイナーは必要に応じて UXPin内のさまざまなバリエーションにアクセスすることができます。これにより、各コンポーネントの完全性が損なわれることはありません。これはデザイナーが会社の標準であるデザインシステムと異なる要素を使ったり、間違いをするリスクを減らします。

一度、デザインシステムを用意してしまえば、それを頻繁に修正することはありません。デザインシステムを使って開発しようとする人は、最終製品が意図された通りに見えるように、また、迅速な開発プロセスの利点を得られるように、一連のルールを尊重しなければなりません。もちろん、デザインシステムの中には他よりも自由度の高いものもありますが、ある意味ではガバナンスを構築しているとも言えます。同様に、UXPin Mergeはデザインプロセスを大きくコントロールしています。デザイナーは定義済みのコンポーネントのみを使用し、必要に応じてコード化されたコンポーネントを更新するためにエンジニアに相談しなければなりません。

これらの制限は、実際にはデザイナーの作業を容易にするためのものです。デザイナーは、最も重要な部分であるユーザーエクスペリエンスを構築するために、既製のパーツを受け取っているのです。確かに、カラー、パディング、フォントなどの視覚的要素はエクスペリエンスの重要な部分ですが、細かい部分をいちいち選択していてはプロセスが遅くなってしまいます。デザイナーは、実際にコード化されたコンポーネントを使ってモックアップに取りかかるのが非常に簡単になります。さらに、これらのコンポーネントのコードが変更された場合は、それらを使用しているモックアップ内でも更新されます。

Storybookとの統合  

UXPin Mergeのもう一つの特徴は、Storybookとの統合です。Storybookはデザインシステムのリポジトリのような役割を果たしています。多くの企業で使用されており、様々なフレームワークで作られたコンポーネントを格納できるため、非常に柔軟性があります。さて、Storybookのプロジェクトを立ち上げ、デザインシステムのすべてのコンポーネントを配置するのは、非常に長い作業であり、エンジニアのいないチームは苦労するかもしれません。しかし、ひとたび準備が整えば、デザインシステムをすっきりと保持し、表示することができます。 

UXPin Mergeは、Storybookで定義されたものをUXPinに持ってきて、どのフレームワークで作られたコンポーネントでもUI/UXのモックアップを作れるようにすることを目的としています。統合部分は非常にシンプルで、理論的には、公開されたStorybookプロジェクトのURLを使用するだけで、そのコンポーネントをモックアップに使用するために取得することができます。実際に使ってみたところ、Reactコンポーネントとの連携もバッチリでした。 

将来への想い  

UXPin Mergeが目指すデザインプロセスを整理してみると、以下のようになります： 

UXPin Mergeは、モックアップを設計する際に繰り返し使用できる既製のコード化されたコンポーネントを提供しているため、ステップBに焦点を当てています。しかし、ステップAとステップCにはいくつかの緩い部分があります。定義されたデザインシステムでは、ステップAは不変であると考えられているので、本当に心配する必要はありません。しかし、コード化されたコンポーネントの中で何かを調整しなければならない可能性は、特に自分のデザインシステムを開発している最中であればあります。

UXPin Merge はこれらの障壁のいくつかを満たすことを目的としており、既存のデザインシステムから来る既製のコンポーネントを使った高速プロトタイピングのための素晴らしいソリューションであると思われます。しかし、いくつかのステップはまだカバーされていないようです。

ある意味、既製のコンポーネントだけを利用するデザイナーとしては、制限が掛けれているように感じるかも知れません。しかし、コード化されたコンポーネントでプロトタイピングができることで、デザインと開発プロセスを一本化するだけでも、時間とコスト効率はかなり改善されるはずです。

 

作者について　　

金 成哲　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Fixel株式会社　代表取締役

モレノ　キロガ　ハコボ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Fixel株式会社　エンジニア/デザイナー　　　　　　　　　　　　　　　　　　　　　　https://www.linkedin.com/in/jacobo-mq/

Fixel株式会社　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　https://fixel.co.jp/　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　UX/UIデザイン、デザインシステム作成・運用、新規サービス開発支援

デジタル製品のブランドを維持するために、静的なスタイルガイドは重要な役割を果たします。しかし、実際に製品をデザインする際には、インタラクティブなデザインシステムを使うことで、プロジェクトの目標を達成する製品を簡単に作ることができます。

スタイルガイドの成功例

スタイルガイドは、新しいデザインを生み出すよりもはるかに昔から存在しています。スタイルガイドは、新聞の適切なフォントの選択から、学者がソースを引用する方法まで、あらゆる場面で重要な役割を果たしています。

スタイルガイドは、今ではすっかり廃れてしまいましたが、インタラクティブなコンポーネントやデザインシステムを作る上で必要な情報を提供しています。

もし、あなたがデザインチームを率いることになったら、その会社がすでにスタイルガイドを持っていることを嬉しく思うでしょう。スタイルガイドがないと、最初からやり直しになってしまいます。ジョンソン・エンド・ジョンソンのデザインチームが、静的なスタイルガイドをインタラクティブなデザインシステムに変えるのに約6ヶ月かかったことを考えれば、ゼロから始める作業はしたくないはずです。

静的スタイルガイドの失敗例

すべてのデザインチームは、期待通りの製品を作るためのガイドラインを必要としています。しかし、静的なスタイルガイドは、いくつかの点で今日の現実的なニーズを満たすことができません。

静的スタイルガイドは進化しない

静的なスタイルガイドは、実際には変化しません。新しいバージョンをリリースすることはできても、すでに作成したものを更新することはできません。これは、静的なものの不幸な宿命です。

会社のブランドの変更を反映するようにスタイルガイドを更新するとどうなりますか？組織全体のコンピューターに保存されている古いガイドのすべてのコピーを置き換えることはできますか？

古いバージョンをすべて回収して、最新のコピーに置き換えようとしても、どうしても誰かが古いものを保持して使ってしまいます。これでは、どうしようもありません。

静的なスタイルガイドは限られた指針に過ぎない

スタイルガイドがガイダンスを提供するだけであることは、明白に聞こえるかもしれません。デザインの指針となること以外に、スタイルガイドに何を期待すればよいのでしょうか。この課題は、以下の「デザインシステム」のセクションでより明らかになります。

静的なスタイルガイドを使用したことがある人は、自分のデザインをスタイルガイドのイメージと比較しようとしたことがあるでしょう。優れたガイドは、テキストの各行間の距離を教えてくれますが、だからといって画面上でその通りに見えるわけではありません。

また、静的な画像では、機能がどのように動作するのかを示すことはできません。ボタンをクリックするとメニューが下に落ちるのか、それとも横に開くのか。

自分の能力を最大限に生かすことはできますが、それだけでは、権威ある情報源なしに判断を下すことになってしまいます。

インタラクティブなデザインシステムが有効な理由

インタラクティブデザインシステムは、上記のような問題をすべて解決します。

進化がインタラクティブデザインシステムの本質である

重要なことは、インタラクティブデザインシステムは、必要に応じて更新できるデザイナーのための信頼できる唯一の情報源を提供するということです。デザインリーダーは一般的にデザインツールを使って、チームにデザインシステムへのアクセスを与えます。デザインシステムを更新すると、その変更はグローバルに行われます。自分のコピーにだけ適用されるわけではありません。デザインシステムを見る人は誰でも、あなたが行った変更を見ることができます。UXPinでは、いくつかのコンポーネントが同期していない場合は通知され、迅速に更新するチャンスが与えられます。

 

インタラクティブデザインシステムは、ドラッグ＆ドロップ機能を備えています

インタラクティブデザインシステムでは、ガイドラインに沿っているかどうかを心配する必要はありません。その代わり、ドラッグ＆ドロップ機能を使って、デザイン環境にコンポーネントを配置することができます。もちろん、スペースの修正や新しいテキストの追加などの調整は可能ですが、コンポーネントはピクセル単位で完璧に再現されます。

UXPinで始めるインタラクティブなデザインシステムの構築

UXPinは、最も先進的なデザイン・プロトタイピングツールの一つです。独自のデザインシステムを作成することも、Material Designのような一般的なオプションを利用することもできます。

いずれにしても、製品のデザインとプロトタイプを作成するためのエレガントなコードパワーを得ることができます。デザイナーと開発者を隔てる壁を取り払いたいなら、GitリポジトリとStorybookの2つの統合を可能にするMergeテクノロジーを搭載したエディタをお試しください。UXPinは、開発者が製品化可能なコンポーネントを保管している場所に接続し、それらを私たちのライブラリにインポートすることができます。UXPinでは、インタラクティブなコンポーネントをキャンバスにドラッグ＆ドロップするだけでデザインすることができます。忠実度の高いプロトタイプを数分で構築でき、面倒なハンドオフの苦痛から解放されるので、未来は今です。

今すぐMergeへのアクセスをリクエストして、コードベースのツールがあれば、インタラクティブなデザインシステムの管理がどれほど簡単になるかを確認してください。