この記事は、綿貫様にご執筆いただきました。

デザインツールであるUXPin Mergeを導入するにあたり、TypeScriptでの環境構築の仕方をまとめた記事です

• 公式ドキュメントには通常のJavaScriptでの導入の仕方しか記載がなかったので書いてみました。

また、今回の記事内のコードはこちらのリポジトリに全て載せています。

yarn init -y

このような内容のpackage.jsonが生成されました。

{ "name": "uxpin-with-typescript", "version": "1.0.0", "main": "index.js", "author": "Keisuke Watanuki", "license": "MIT" }

1. React + TypeScriptの準備

ターミナルでコマンドを叩きます。

yarn add -D react @types/react react-dom @types/react-dom typescript


{
 "name": "uxpin-with-typescript",
"version": "1.0.0",
"main": "index.js",
"author": "Keisuke Watanuki",
 - "license": "MIT" + "license": "MIT",
+ "devDependencies": {
+ "@types/react": "^17.0.34",
+ "@types/react-dom": "^17.0.11",
+ "react": "^17.0.2",
+ "react-dom": "^17.0.2",
+ "typescript": "^4.4.4"
 + }
  }

更にコマンドを叩きます。

npx tsc --init

tsconfig.jsonが生成されるので適宜設定して使います。
今はコメントアウトを消すなど、最低限にとどめておきました。

{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"strict": true,
"skipLibCheck": true,
"jsx": "react",
}
}

https://www.typescriptlang.org/tsconfig

2. Storybookの準備

ターミナルでコマンドを叩きます。

npx sb init

プロジェクトのルートに.storybookとstoriesというフォルダが追加されたり、package.jsonにdependenciesやscriptsが追加されたり、TypeScript + React用のコードが自動で追加されます。

※コンポーネント類が「stories」というディレクトリに格納されていて、実際の運用では「components」などにリネームすると思われますが、話を簡単にするためにこのまま進めます。

この段階で以下のコマンドを叩くと、localhost:6006でStorybookが起動します。

yarn add -D @uxpin/merge-cli

package.jsonにscriptsを追加しておきましょう

{ "name": "uxpin-with-typescript", ... "scripts": { "storybook": "start-storybook -p 6006",　- "build-storybook": "build-storybook" + "build-storybook": "build-storybook", + "uxpin": "uxpin-merge --disable-tunneling" } }

yarn add -D babel-loader ts-loader@^8.2.0 style-loader@^2.0.0 css-loader@^5.2.7

@uxpin/merge-cliの2.7.9においてはloaderのバージョンが最新だと動きませんでした。根本解決ではありませんがこれらのバージョンを指定してインストールすると動作することは確認したため、ひとまずこちらをお試しください。

追加でコマンドを叩きます。

touch uxpin.config.js uxpin.webpack.config.js

それぞれのファイルには以下を記載します。

module.exports = { components: { categories: [ { name: 'General', include: [ 'stories/Button.tsx', 'stories/Header.tsx' ] } ], webpackConfig: 'uxpin.webpack.config.js' }, name: 'UXPin Merge + TypeScript + Storybook' }

StorybookのイニシャライズでPage.tsxというファイルも生成されていますが、

ここでは登録していません。説明すると少し長くなってしまうので次回の記事で紹介します。

</p>
preconst path = require('path')


module.exports = {
output: {
path: path.resolve(__dirname, 'build'),
filename: 'bundle.js',
publicPath: '/'
},
resolve: {
modules: [__dirname, 'node_modules'],
extensions: ['*', '.tsx']
},
devtool: 'source-map',
module: {
rules: [
{
loader: ['babel-loader', 'ts-loader'],
test: /\.tsx$/,
exclude: /node_modules/
},
{
test: /\.css$/,
use: [
{
loader: 'style-loader',
},
{
loader: 'css-loader',
options: {
importLoaders: 2
},
},
],
},
]
}
}
<p>

ここまで来たら、ターミナルで以下のコマンドを叩くとUXPinのexperimental modeが起動します。

</p>
yarn uxpin
<p>

ターミナル上に表示されたURLにアクセスすればexperimental modeで挙動を試せます。

次回

この記事で作った環境にCSS Modulesを適用します。

この記事からUXPinに興味をお持ちいただけた方は、 14日間の無料トライアルにサインアップして、今日からより是非ご利用を開始してみてください。また、UXPin Mergeをご希望の方は、こちらよりデモをご予約ください。

この記事は、株式会社Incrementsの綿貫様にご執筆いただきました。元記事は、こちらから。

The post 0から作るUXPin Merge + TypeScript + Storybookの環境 appeared first on Studio by UXPin.

UXPinによって顧客のデザイン体験がどのように改善されたかについてフィードバックを受けると、私たちはいつもワクワクします。その顧客が世界最大のデジタル決済プラットフォームの１つであれば、特別感はなおさらです。

今回、PayPal のデベロッパーツールおよびプラットフォームエクスペリエンス担当のシニアマネージャーであるエリカ・ライダー氏と、彼女のチームのシニアUX デザイナーであるアンソニー・ハンド氏にお話を伺うことができたのでご紹介します。

エリカは、PayPal で解決しなければならなかったデザイン上の課題、すなわちデザイン、製品、開発の間のギャップを埋めることについて、彼女自身の言葉で説明しています。

多くの企業では、デザイナーとデベロッパーの比率は、「デベロッパー１０人」に対して「デザイナー１人」ですが、PayPal では、「１０００人以上のデベロッパー」に対して「デザイナー５人」です。

PayPal はこの課題を克服するためのツールや戦略を必要としていました。そこで、彼らは UXPin Merge に注目し、DesignOps のプロセスを改善しました。

彼女とPayPal のデザインチームが、UXPin Mergeを使ってどのようにデザインと開発のプロセスに革命を起こしたかを、これからご紹介します。

体験談を動画で見る 

PayPalの主な２つの課題

 デザイン拡張 の課題：

私を含め、５人のデザイナーからなる小さなデザインチームがあり、６０〜１００の製品と、１０００人を超えるデベロッパーを担当しています。

このような大きな組織を支える小さなデザインチームとして、私たちは革新的な問題解決のアプローチを開発しなければいけませんでした。デザイナー増員の予算は確保できないので、デザインそのものをスケールアップする方法を考えなければならなかったのです

一貫性の課題：

PayPal の製品チームには、経験豊富な UX 担当者やUIデベロッパーはおらず、その結果、さまざまなユーザビリティとデザインの一貫性に問題が生じ、製品がどれ１つとして同じにならなくなってしまいました。

そこで私は、まとまりのある一貫したユーザー体験を生み出すという、難しい仕事を任されましたが、３人のデザイナーと無限の製品チームからなる私たちは、従来のようなモデルで規模を拡大するのは無理だと思いました。加えて、デザイナーの増員が問題解決になるとも思えませんでした。

製品チームを成功に導くには、私たちにはデザインの拡張が必要だったのです。

今までは…

PayPalが使ってみたツール

まず、製品チームは自分たちで製品をデザインしないといけないことが分かっていたので、私たちはさまざまなツールを検討し、まずはデザインシステムや規格がある従来型のモデルから始めました。

最初の考えは、デザインについて製品チームを教育しながら、従来のデザインアプローチを適応させることでしたが、ドキュメント作成、サポートの提供、デザインツールの学習曲線をたった３人のデザイナーで行うとなると、従来のモデルではうまくいかないことにすぐに気づきました。

製品チームが製品をうまくデザインするには、彼らが学ぶべきツールやスキルを最小限に抑える必要があったのです。

従来のやり方

従来の UX プロセスでは、デザイナーがベクターベースのモックアップを作成し、それをデベロッパーに渡していましたが、残念ながらこのプロセスでは、コンポーネントがどのように機能することになっているかと、そこにあるべきコンポーネントの間にギャップが生じてしまいます。

その結果、デザイナーとエンジニアの間で「デザインはどうあるべきか」、「プロトタイプはどうあるべきか」を明確にするために、何度もやり取りをすることになり、デベロッパーは、製品の見た目や機能だけを考えていたため、デザイナーに思いもよらない質問を重ねることになってしまいます。

UXPin Mergeの導入

製品チームが製品をデザインするには、このデザイナーとデベロッパーのギャップを最小限に抑え、連携を改善する必要がありました。

PayPal に入社する数年前、私には「デザインの効果的な拡張には、デベロッパーやプロダクトマネージャーを  デザインプロセス に関わらせないといけない」という持論がありましたが、それを行う方法は知りませんでした。何をするかは分かっていたのに、どのようにするかは分かっていなかったのです。

ですがMergeとUXPinに出会ったことで、デザインと開発のギャップを埋める方法を理解する道が開かれ、PayPal の デザインプロセス 改善のきっかけとなりました。

従来の DesignOps のプロセスは、スケーリングに関するものであり、通常はデベロッパー１０人に対してデザイナー１人という割合が一般的です。まずデザイナーを追加し、次に大規模なデザインチームを収容するためのサポートインフラを構築します。

社内組織として、従来のデザイナーとデベロッパーの比率である１対１０にスケールアップするためのリソースが得られないことは分かっていたので、デザイナーを増やすことなく、デザインの課題を解決するための革新的なソリューションを見つけなければいけませんでした。

UXPin Mergeの仕組み

PayPalの消費者向けアプリ、サービス、Venmo、その他の外部サービスは、すべて異なる技術が使われています。社内ツールの開発には、より企業向けに特化し、社内のユーザーインターフェースに適していることから、『Microsoft のフルーエントデザインシステム』と 『UIコントロール』を採用しました。

UXPin Mergeがあれば、Microsoft の フルーエントデザインシステムを Githubレポに入れ、コンポーネントを UXPinのデザインエディタにインポートすることができるようになります。そしてこのUXPin Merge のセットアップを使って、製品チームは、エンジニアが DevOps ツールの開発に使っているコンポーネントとUIコントロールを正確に活用したプロトタイプをデザインすることができます。

たとえば、UXPinのエディタでキャンバス上のボタンをレンダリングすると、ホバー/クリック効果、フォント スタイル、その他のメトリクスを含め、デベロッパーツールでレンダリングしたものとまったく同じになります。UXPin Mergeでデザインすると、PayPal のときよりもはるかに忠実なプロトタイプを作成できるのです。

Mergeを使った感想

最初の展開で、UXPin Mergeを使うことでデザインにかかる時間を大幅に短縮できることが分かっていました。

すると PayPalの上級管理職から、「UXPin Mergeを使った場合」と「従来のデザインモデルを使った場合」の時間短縮の比較をしてほしいという依頼がありました。

そこで、あるデザイナーに単一ページの比較テストを選んでもらいました。PayPal で使っている別のデザインツールで、ベクターベースのデザインを１ページ行い、UXPinで当社のMergeコンポーネントライブラリを使って、まったく同じプロトタイプを作成しました。この２つのツールは、時間面でどのように比較されるでしょうか？

結果：Mergeを使った場合、デザイナーは約８分かかりましたが、他のデザインツールを使用した場合は、同じプロトタイプに 1 時間以上かかったのです! これは、私たちが比較対象として選んだツールを使い慣れている、能力を持った経験豊富なデザイナーによるものであることに留意してください。

ベクターベースのデザインツールを製品チームに提供するのは気が進みませんでした。彼らはデザインを始める前に、ドキュメントを整備し、ツールの使い方を学ばないといけませんでしたから。たとえトレーニングに時間がかかったとしても、経験豊富なデザイナーの能力に達することはできなかったでしょうし、同じプロトタイプを１時間でデザインすることもできなかったでしょう。

UXPin Mergeを使えば、プロダクトマネージャーの一部は、同じようなプロトタイプ１ページを８～１０分で作れます – UXPinの経験豊富なデザイナーにかかる時間と同じです！

以前は、限られたリソースとデザイナーで、１ページの製品を作るのに、モックアップのデザインだけで２〜３カ月かかっていましたが、今は、プロダクトチームが同じ時間内に製品をデザインし、提供することができます。

UXPin Mergeが与える大きな影響

UXPin Merge の大きな影響の１つは、より忠実度の高いプロトタイプを作成できるようになった点です。デザイナー、経営陣、ディレクター、デベロッパーなど、すべての人が最終製品の外観、UX、インタラクティブ性についてより確信が持てるようになり、それによってステークホルダーからより質の高いフィードバックを得ることができるようになりました。

経営幹部やディレクターは、こういったプロトタイプの機能と目標を実際に体験することから、最終的な方向性について、たとえば「このようなボックスがどのようにテキストフィールドのように見えないか」について単にコメントするのではなく、より強力なフィードバックをしてくれるようになりました。

Merge で UXPin を使うようになってから、私のデザイン哲学と生産性は格段に上がりました。３０分以内にプロトタイプを実装できる自信があります。ちなみに、以前使っていたツールでは半日かかっていましたからね。

フィードバック：UXPinを使うことで、ステークホルダーはかなり迅速なフィードバックの提供ができます。彼らにプロトタイプのリンクを送ると、好きな時間にプロトタイプで遊んでもらい、UXPinでプロトタイプに直接コメントを記入してもらうことができます。UXPinのコメント機能は、私たちの対応後に、コメントを【解決済み】としてマークする点が素晴らしいですね。

製品の質：この新しい UXPinのアプローチでは、より協力的で統合的なデザインプロセスが実現されます。デザイン、プロトタイプ、開発を別々にするのではなく、UXPinによって、プロセス全体を通してエンジニアリングと製品チームが関与する統合的なフローを作り出すことができ、その結果、製品の最終的な品質が劇的に上がりました。

ユーザーテスト：UXPinで作成した忠実度の高いプロトタイプは、私たちにはとても便利です。忠実度の高いプロトタイプをより早く作成でき、セッション後にすぐにフィードバックが得られます。そしてすぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。

UXPinは、コンセプトから忠実度の高いプロトタイピングまで、即座に対応できるツールを提供します。UXPin Merge を使って、高度なプロトタイピングとテストがデザイン プロセスをどのように変えるかをぜひご覧ください。

 PayPalが再定義したデザインプロセス

 PayPalのDesignOpsは、エンド・ツー・エンドのプロセスです。

1. 製品チームはユーザーを十分に理解するのが必須である
2. ユーザーのニーズに基づいた製品をデザインする
3. ドメインエキスパートが、彼らの知識とテストに基づいてデザインを完成できるようにする
4. デザインの成功を検証する

社内の共通の課題として、製品チームが UX デザインをボトルネックとして捉えていることがよくあります。そこで私たちの戦略は、まずそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにすることから始めました。

そこで私たちは、このような「スナップ・トゥギャザー」型のデザインを実現できるUXPin Mergeを使うことでそれを実現しました。ドラッグ＆ドロップでユーザーインターフェイスを構築できるコンポーネントが製品チームに提供されます。

製品チームは、余白や構成要素を固定したレイアウトを作成することができ、すべてが想定通りに表示され、機能するようになりました。デザイナーは、何も取り締まる必要も、製品デザインのために介入する必要もありませんでした。

製品チームが標準的なデザイン原則に従っていないときや、大変な問題で行き詰まったときは、デザイナーは今でも製品チームを手伝っていますが、製品チームは作業の９０％を自分たちで行うことができるため、デザイナーはより大局的なデザインの問題に集中することができます。

成果

顧客中心

私自身、顧客中心やデザイン主導というのは、デザイナーが常にリードしているという風には考えていませんし、組織の誰もが、デザイン主導とはどういう意味なのかを理解しています。

私達は PayPal でデザインをするとき、あっちこっちの小さな問題に焦点を当てるのではなく、グローバルレベル、組織全体、製品ライン全体で問題を解決することに重点を置いています。

小さなコーナーケースだけでなく、PayPal の製品すべてで一貫性のある体験がユーザーに提供されないといけないのです。

PayPal のプロダクトチームとドメインの専門家がデザインをしている間、我が UX チームはメンターやコーチとして動きます。以前は UX デザイナーが１製品、あるいは１ドメインを担当していましたが、Design Ops 2.0では、製品デザイナーが一度に１０～１５種類の製品を担当するようになりました。

企業における教育 

UX デザイナーがプロダクトチームを指導する場合、より良いレイアウトやプロダクトをデザインするためのガイダンスを配るだけでなく、デザイン思考を教えることもあります。

デザイン思考は UIデザインだけでなく、完全な UX を考えることです。API のレスポンスタイムは UX にどのような影響を与えるでしょうか？レイテンシーは UX にどのような影響を与えるのでしょうかか？

私たちは、UIのトップレベルからのデザイン思考を求めており、製品チームがエンドユーザーのために適切な判断を下せるように、全員に UX の影響を理解してほしいと思っています。

重要なことに集中する

我がデザインチームは、さまざまな製品チームのサポートに５０％の時間を費やし、残りの５０％は、グローバルな組織に影響を与える大きなUXイニシアチブに費やしています。

こうした UXの取り組みには、以下のようなものがあります：

• 「プラットフォーム上でのユーザー間の信頼関係の構築法」といったことに重点を置くか。
• プラットフォーム上でいかにしてユーザー間の本質的な繋がりを築くか。
• どのようにすれば、すべての製品にユーザー調査を組み込むことができるか。- 調査ではなく、ユーザーがどのように製品を使い、どこにギャップがあり、それをどのように修正し、そのデータを製品チームに提供するにはどうすればいいかのの理解である。

将来への投資

デザインプロセスの拡張は、長い目で見れば投資となります。デザインと開発のライフサイクル全体を俯瞰し、それが現在どのような状態になっているかを把握し、「このステップは長すぎる」ではなく、「どうすれば短縮できるか」を考えるには、経験豊かなチームが必要です。

すべての技術を構築する最初のプロセスは長い時間のように思えますが、実は長い目で見れば、開発、デザイン、開発プロセスの全てにおいて、かなりの時間を節約することができるのです。

UXPin Mergeとデザインプロセス 

もし UXPin Mergeが世界最大のデジタル金融プラットフォームの複雑なデザイン問題を解決できたとしたら、これがあなたのビジネスだとどうなるかを想像してみてください。

PayPal はMergeを使って Git レポジトリから UXPinとReactコンポーネントを同期しましたが、MergeはStorybookとの統合も可能であり、Vue や Angular など、さらに多くのフレームワークにアクセスすることができます。

  デザインプロセスの速度を上げる準備はいいですか？

The post PayPalがUXPin Mergeで デザインプロセス を拡張した方法 appeared first on Studio by UXPin.

本記事は、UXPin Mergeを使ってコードコンポーネントを使ったデザインを始めた、シンプルで使いやすいパスワード管理ツールのTeamPasswordとのコラボレーションで書かれています。

__________________________________________________________________

デザインシステムの代表的なものを見ると、それを構築する時間とリソースがあるビッグブランドだけのものだという印象を受けるかもしれませんが、そんなことはありません。今日のソリューションでは、どのような規模のチームでもデザインシステムの構築、維持、サポートができます。

TeamPasswordもそういった企業の一つです。私たちがTeamPasswordと出会ったとき、開発スタッフは2人で、デザイナーは一人もいませんでしたが、 UXPin Mergeさえあれば、これからも彼らはデザイナーなしでやっていけるようです。

TeamPasswordについて

TeamPasswordは、ログイン名とパスワードをすべて一箇所にまとめて管理する、チーム向けのパスワード管理ツールです。メールやチャットアプリなどの安全性の低い通信経路でパスワードを伝える代わりに、チームは、簡単に共有ができるクリーンなインターフェースを介して、いつでもログイン情報にアクセスできます。このツールは使いやすく、非常にわかりやすいので、アクセスセキュリティのケアが本当に身近になります。

課題

マシュー・チギラ氏は、チームのデベロッパー2名のうちの1人として、フルスタックデベロッパーとしてTeamPasswordに参加しました。彼は古いフレームワークと比較して、維持が簡単なReactにツールを切り替えることを提案しました。

また、インターフェースの構成要素を保存・記録するデザインシステムでアプリを作成することが、いかに便利であるかということも知っていました。スタイルガイドや複数のライブラリから取得したコンポーネントでインターフェースを構築せずに、最初からデザインシステムを使用するブランドには、他にも多くの利点があります。デザインシステムの早期構築の利点としては、作業の迅速化、ハンドオフの改善、そしてもちろん一貫したUIが挙げられます。

MVP（Minimum Viable Product）の構築だとしても、デザインシステムに従うことを頭に入れておきましょう。デザインプロセスがスムーズになり、チームの規模が大きくなったときにUIのスケーリングに関する問題を回避できます。さらに、ルック＆フィールに一貫性がないと、潜在顧客のアプリに対する印象に影響を与える可能性があります。

ブランドはこの市場において不可欠であると主張する、TeamPassword のオペレーションディレクターであるトニー・カッチョボ氏 は、「お客様は我々に、ログイン記録にある機密情報を託しますので、一貫性のない或いは時代遅れのデザインだと、情報の安全性を保つのに十分な最新の技術があるのか、一部のお客様に疑問を抱かせる可能性があります。

フロントエンドの開発は、バックエンドのパフォーマンスの中に信頼と信用を築くのです。」と述べています。 機能の出荷も同様です。もしチームが迅速に行動しなければ、誰かに先を越されてしまいます。とはいえ、デザイナー不在の製品開発では、わかりやすく一貫性のあるユーザーインターフェースを実現できません。 多くのチームが同じような問題に直面しています。優秀なエンジニアが在籍しているにもかかわらず、開発をどんどん進めないといけないので、UIの一貫性やわかりやすさに影響が出てしまうのです。これでは、競合に差をつける強力なブランドを簡単に作れません。

したがって、デザインシステムはTeamPasswordにとって必須のものでしたが、ただデザインの決定に役立っただけで、それですべての問題が解決されるわけではありませんでした。その上、シンプルで効果的なフロントエンドデザインを作成できるツールも必要だったのですが、そこで登場したのがUXPin Mergeです。

小さなチームで大きな成果

TeamPasswordはUXPin Mergeとそのコードコンポーネントライブラリ、特にオープンソースのMUIとの統合については知っていました。初日から自分たちのブランドに基づいたテーマバージョンのMUIを得られるのは大きなセールスポイントであり、彼らには、MUIコンポーネントをインポートし、UIコンポーネントをキャンバス上にドラッグ＆ドロップするだけでプロトタイプを作成できるデザインツールが必要でした。

UXPin Mergeは、何通りかの方法で、Reactコンポーネントで埋め尽くされたMUIライブラリをUXPinエディタに取り込むことができます。TeamPasswordはGitレポジトリからインポートするか、Storybookの統合を使えます。UIコンポーネントのコードレスインポートにより、コード化されたコンポーネントのインポートも可能です。（Merge Component Managerへのアクセスは、こちらからリクエストしてください。）

Mergeの顧客の皆さんと同じように、UXPinはTeamPasswordとワークショップを計画し、コードコンポーネントを使用したデザイン方法を紹介しました。マシュー 「ジャックとのトレーニングセッションは本当に貴重でした。また、ツールのセットアップやエディタの使い方を学びました。また、コンポーネントを調整する方法も教えてもらいました。」と言っています。

UXPin Mergeを使用すれば、TeamPassword は現実的なプロトタイプを組み立てるためのデザイナーは要りません。さらに重要なのは、Merge は実際の React コンポーネントを使用しているため、UI デザインは、まだコーディングする必要がある前述のコンポーネントの画像表現というよりは、プロフェッショナルに見えるだけでなく、開発された製品のように動きます。

TeamPassword は、開発とデザインの両方において、信頼できる唯一の情報源（Single source of truth）の恩恵を受けることになります。

完成したデザインを製品にするまでのプロセスも、ずっと速くなりました。プロトタイプの仕様と製品化可能なコードを書き出しがとても速くできます。これで、フロントエンドのコードを書くのにチームに通常かかっていた時間が節約されるのです。

今後の展望

TeamPasswordには、UXPin Mergeをどのように使用したいのか、完全な戦略が用意されています：

• 選択したデザインシステムに基づいたウェブサイトの再デザインから始動：現在のウェブサイトは少し古く見えるので、一部の潜在的な顧客の購入意思決定に影響を与える可能性がある上に、デザインに一貫性がありません。TeamPasswordは、このサイトを一新したいと考えています。
• MUIとUXPin Merge を使ったアプリのインターフェースの再構築：次のタスクは、アプリケーションのフロントエンドのデザインのやり直しです。Reactに切り替え、アプリのコンポーネントライブラリとしてMUIを使いたいと考えています。デザインと開発で同じビルディングブロック、つまりReactコンポーネントを使うので、タスク全体はそれほど長くはかからないはずです。
• 新機能の構築とTeamPasswordの成長：プロトタイピングの新しいアプローチは、統一されたユーザー体験を提供するアプリのデザインと開発をサポートし、市場投入までの時間を短縮します。

まとめ

UXPin Merge を使用することで、TeamPassword は UI デザインを作成し、その背後にあるコードを短時間でエクスポートすることができます。デザイン会社を雇うことなく、デザインの拡張、ワークフローの整理、一貫したインターフェイスの作成が可能になります。小規模なチームは、適切な場所でスケーリングできるデザインベロシティを手に入れることができます。これは、新しいレベルの仕事です。

UXPin Mergeの技術で、Git、Storybook、またはNPM（Node Package Manager）パッケージ経由で保存されたライブラリから、誰でもUIコードコンポーネントをインポートすることができます。チームは、製品やチームを拡張する準備が整う前から、デザインと開発のための信頼できる唯一の情報源（Single source of truth）を得ることができます。

UXPin Merge へのアクセス権をリクエストして、プロトタイプ作成がどれほど速くなるかを体験してみてください。プロトタイプとコード化された製品に違いはありません。どのような規模のチームでも、時間を大幅に節約することができます。コードコンポーネントをデザインツールに取り込み、デザインと開発のワークフローを接続します。

The post ケーススタディ：UXPin MergeとTeamPassword appeared first on Studio by UXPin.

Storybook統合（有料プランでは完全に、トライアルでは公開ライブラリーへのアクセスが可能になりました）のリリース前に、筆者はこのMergeの新機能を試す機会がありました。私たちのチームにおけるデザイナーとデベロッパーのコラボレーションにどのような影響を与えたか、筆者の感想をシェアすることにしました。

参考までに、UXPinはデザインやプロトタイプの作成ができる、すでに広く使われているデザインツールです。他のデザインツールと違うのは、コードベースなのでより柔軟性があり、プロトタイピングのための高度なインタラクションを多く提供している点です。それによりUIをより開発に近づけることができるのです。

MergeはUXPinの一部であり、GitとStorybookという2つのデベロッパーのツールとの統合を提供する技術です。Git との統合では React ベースの、Storybook との統合では任意のフレームワーク ベースの UI コード コンポーネントを使用して、プロトタイプがサッと作成されます。そこで我々は、最新のMergeとStorybookの統合をテストしてみました。

このレビューは、CEOのロイ・S.・キム氏と、デザインシステムに特化した日本のUX/UIデザインコンサルティング会社、株式会社フィクセルのフロントエンドエンジニア＆デジタルコンテンツデザイナーであるハコボ・モレノ・キロガ氏によって書かれたものです。

UXPinのMergeとStorybookの統合をやってみた

筆者にはエンジニアとデザインの両方のバックグラウンドがあり、アプリケーション内部の処理について解決策を見出し、それをコードで記述する作業を日々行っています。その中で、ユーザーの視点に立った改善策を考える際には、デザイナーとしての経験が役立っています。視覚的な美しさを決めるだけでなく、そのためには、アプリケーションでの作業に集中できるよう、アプリケーションのインターフェースをいかに気付かれないようにするかを考えなければいけません。

筆者は普段、ユーザーエクスペリエンスの向上を目指したコーディングのイテレーションを行ったり来たりするのが大変です。

そういう改良は、何かがうまくいかないから製品を直すというのとは違います。むしろ、ユーザーから「何か違和感がある」と言われたときの直感的な作業です。デザインやUXのグッドプラクティスをすべて適用したとしても、ユーザーから不満が出る可能性があり、その不満は100％正しいでしょう。そこで、コード化されたデザインシステムや、整理されたUIコンポーネントライブラリーの出番です。デザインシステムで承認されたコンポーネントをテストして磨き上げれば、新しいアプリケーションのための構成要素として、あまり時間をかけて考えたり調整したりすることなく、すぐに扱えるようになります。

UXPinのMergeテクノロジーでは、GitまたはStorybookに保存されているDesign Systemコンポーネントをすべてデザインエディターにインポートして、すぐにプロトタイプを作成することができます。これにより、デザイナーは実際にコード化された要素を使用して、プロトタイピングのスピードを上げることができます。プロトタイプで見るものは、デベロッパーが同様に使用する実際のワーキングコードとデザインを組み合わせたものであることから、UXPin Mergeのモットーは「信頼できる唯一の情報源（ single source of truth）」です。

UXPin- デザインからコーディングへ

まずは、UXPinだけを見てみましょう。基本的に、UXPinはSketch、AdobeXD、Figmaに似たUI/UXデザインツールです。他の競合製品と似ているので、すぐに使いこなすことができ、ワイヤーフレームから高度なプロトタイピングまで、この1つのツールで行うことができます。

多くの類似ツールでは、デザイナーがデザインツールで作成したものと、実際に動作する製品がコーディングされる開発環境で起こることの間に大きな違いがあります。Figmaのinspectタブなどの機能により、あるオブジェクトの背後にあるCSSがどのようなものであるかを大まかに確認することができますが、これは必ずしも、デザインされたものととコーディングされたものが正確に描写されているとは限りません。

デザイナーとデベロッパーは、通常業務で使用するツールに関して、基本的に2つの別々の世界から来ています。両者の間で共通言語を見つけようとすると、多くのミーティングややり取りが発生することになります。そこで UXPin Merge は、チーム全体が正しいコンポーネントとドキュメントの究極の場所として扱える「信頼できる唯一の情報源（Single source of truth」を持つことで、まさにこの問題を解決しようとしているのでしょう。

UXPin Mergeのアプローチ

Merge は UXPin の技術ですが、基本的に、GitレポジトリやStorybooksに保存されているコーディングされたデザインシステムをUXPinに取り込むことができます。したがって、デザイナーはモックアップやプロトタイプに実際のコンポーネントを使用することができます。これらのコンポーネントはすでにレポジトリでコード化されており、デザイナーは必要に応じてUXPin内でその異なるバージョンにアクセスすることができます。

こうすることで、各パーツの整合性が損なわれることはなくなり、デザイナーがミスをしたり、会社の基準に合わない要素を使ったりする可能性を最小限に抑えることができます。

デザインシステムとレポジトリの準備ができてしまえば、製品開発プロセスのスピードアップとガバナンスの確立のために、可能な限りすべてのバージョンの要素を保存・統一することが目的なので、頻繁に修正することはないでしょう。

となると、要素があらかじめ決まっているので、UXPin Mergeとインポートされたコンポーネントでデザインプロセスを制御することができます。この変更は問題なく行えますが、デベロッパーがしなければいけないため、カジュアルなミスが起こる可能性はかなり低くなります。

このような制限は、実はデザイナーの仕事をシンプルにしてくれます。デザイナーは、完全にインタラクティブで用意された要素を使うことで、最も重要な部分であるユーザーエクスペリエンスに集中することができます。確かに、色、パディング、フォント、その他の視覚的要素はエクスペリエンスの重要な部分ですが、細かい部分をひとつひとつ選んでいては、プロセスが遅くなってしまいます。もし、こういったものがすでにデザインシステムとレポジトリで全部整理されていれば、実際のコードコンポーネントを使ったプロトタイプの構築はより簡単で速くなります。

また、インポートされたUIはデベロッパーのライブラリに格納されているコンポーネントと同期しているため、コード内でコンポーネントが更新されても一貫性を保つことができます。つまり、要素が古くなって、デザイナーがプロジェクトをまたデザインしなければならなくなるといった心配がありません。

Storybookにつなぐ

UXPin Mergeの統合のひとつにStorybookがありますが、Storybookはデベロッパーのデザインシステムのようなもので、コーディングされたUIをすべて保存しておくことができます。多くの企業で利用されており、約15のフレームワークに対応しているため、フレームワーク的にも非常に柔軟性があります。デベロッパーのサポートがないチームにとって、Storybookプロジェクトを立ち上げ、そこにすべてのコンポーネントを配置するのは大変なことかもしれませんが、一旦準備が整えば、デザインシステムにあるすべてのコンポーネントはきちんと保持され、表示されます。

UXPin Mergeは、 どのフレームワークで作られたコンポーネントでも、プロトタイピングに使用することができるように、Storybookに保存・決定されているものをUXPinに取り込むことを目的としています。統合部分はとてもシンプルで、公開されているStorybookプロジェクトのURLを取得し、UXPinライブラリにコンポーネントをインポートしてデザインするだけです。筆者がテストしてみたところ、Reactのコンポーネントでデザインエディター上ですべての要素が正しく動作するようになり、完璧に機能するようです。

今後の展望

UXPin Mergeを含めたデザインプロセスは、このように可視化することができます。

UXPin Merge は、プロトタイプを作成するときに、より速く反復するために使用できる、生産準備完了のUIコード化されたコンポーネントをもたらすので、ステップBで大きな役割を果たします。確定されたデザインシステムまたはコンポーネントレポジトリがあれば、おそらくすでに整理されたコンポーネントがあるため、ステップAについて心配する必要はありませんが、特に独自のデザインシステムを作成している最中であれば、コード化されたコンポーネントの中で何らかの調整が必要になる可能性があります。

アプリケーションの構築ステップであるステップ C では、デベロッパーは Merge プロトタイプを見て、コードのコンポーネントがどのように組み合わされているか、またどのコードがデザインのどの部分に対応しているかを確認します。ただ、コード全体をコピー＆ペーストしてすぐに製品を作るのではなく、プロトタイプが製品になるように調整しなければいけません。

UXPin Merge は、迅速なプロトタイピングとデザインシステムを最大限に活用することによる、一貫性の維持のための素晴らしいソリューションであるように思われますが、まだカバーされてないステップもいくつかあるようです。

あらかじめ用意された部品を使うことがほとんどなので、デザイナーの仕事はある程度制限されますが、時間の節約になりますし、コード部品を使ったプロトタイピングは、デザインと開発の世界をひとつにします。

統合を試してみませんか？14日間のトライアルにぜひサインアップを！

The post Storybook-UXPin : 新Merge統合 のレビュー appeared first on Studio by UXPin.

今回は現在UXPinをお使いいただいている株式会社X-PERIENCE取締役の新山様へミニインタビューをさせて頂きました。

株式会社X-PERIENCE様のご紹介

BtoB向けデジタル・WEB領域での運用アドバイスを中心としたコンサルティングファーム。企業WEBサイトの設計整理などを中心に「三方良し」の精神でクライアントに伴走、課題解決を推し進める精鋭の方々です。

どういった場面でUXPinを使っているのか

一番活躍するのは、クライアント企業様へのプレゼンテーションです。完成形を実際に体験していただくことができるので、非常に助かっています。

UXPinを導入した経緯

私自身はExcelで大量の情報整理をすることが多いのですが、それをそのままお出ししても伝わらないので、最終イメージをPowerpointで作成していました。クライアントへの提案をどうしたらもっと「わかりやすく」伝えることができるのかを考え、デザインツールを検討したことがきっかけです。導入する1年前後、実際に使い比較検討しUXPinにいたしました。

UXPinを選んだ決め手

作業のスピード感、実際に動きがつけられる点です。

UXPinをオススメするとしたら

インハウス制作されている方、大手企業から受託制作されている方。

クライアントにUXPinの画面を見せながらフィードバックをもらい、その場で直す、ということもよくやっており、対応の早さが弊社の評価にも繋がっています。

というお話しを伺えたことは、光栄であり嬉しい限りでした！

お忙しい中お時間を頂きました新山様、誠にありがとうございました。

The post UXPinを使ってみた感想 – 株式会社X-PERIENCE様 appeared first on Studio by UXPin.