ハイテクなデジタル製品におけるUXデザインの世界でも、ペンと紙は、Lo-Fi（低忠実度）のプロトタイプをサクッと作る選択肢として今でも好まれています。皆さんの思い込みとは裏腹に、UXチームはコンピューターから離れ、付箋やホワイトボード、メモ帳に書き込んだり、紙のプロトタイプに注釈を加えたりすることに多くの時間を費やしています。

デザイナーがコンピュータに向かう前に計画や準備をすればするほど、ワイヤーフレーム、モックアップ、プロトタイプをサッとデザインすることができます。そしてペーパープロトタイプは連携を促すことから、初期の UX デザイン思考プロセスの重要な部分であり、それでデザイナーは最小限のコストで多くのアイデアを検討できるようになるのです。

UXPin を使うことで、デザインチームと開発チームは、ペーパープロトタイプから忠実度の高いプロトタイプ作成にすぐに移行でき、それでデザインプロセスは大幅に加速されます。一貫性のある高品質なデジタル体験を構築しませんか。無料トライアルにサインアップして、UXPin のプロトタイピング機能をぜひお試しください！

ペーパープロトタイプとは

ペーパープロトタイプとは、デジタル製品を表す手描きの「スクリーン」を使ってアイデアを開発し、ユーザーフローをデザインするプロセスであり、ここではインタラクションデザインよりも、ハイレベルな UX（ユーザーエクスペリエンス）のテストを行います。

ペーパープロトタイプには機能がないことから、忠実度が低いため、ペーパープロトタイプのデザイナーがペーパープロトタイプを部門外で共有することはほとんどありません。

ペーパープロトタイプは、情報アーキテクチャをマッピングしてユーザーフローを可視化することを主な目的としています。

デザインチームは、よく机の上やフローの上に紙画面を並べて、実際のユーザーがどのようにナビゲートして最終的なゴールに到達するかを想像します。そのデザインは初歩的なもので、たいていは白黒でスケッチされ、コンテンツは見出しと行動喚起のリンクだけが読みやすいテキストで表示された限定的なものです。

また、スワイプやスクロールなどの基本的な機能をシミュレートするために、チームが厚紙を使って iPhone や Android のモックデバイスを作ることもあります。このようなモックデバイスを使うことで、デザイナーは自分のデザインが携帯電話の枠内でどのように見えるかを確認することもできます。‐ これはモバイルアプリのデザインの際には特に便利です。

紙のプロトタイプの主な利点はスピードですが、UI Stencils などのツールを使って、正確で見た目に美しい画面レイアウトをデザインするデザイナーもいます。これは、紙のプロトタイプをステークホルダーやテスト参加者に提示する予定がある場合に極めて重要です。

UXPinの旅は、Web Kitという同様のペーパープロトタイピング製品から始まりました。ペーパープロトタイプを自動的にワイヤーフレームに変換するデザインツールとペアになったペーパーパッドです。そして UXPin は、エンドツーエンドのプロトタイピングソリューションへと進化し、最初から制作可能なプロトタイプを作成できるようになりました。UXPinをぜひ無料でお試しください。

ペーパープロトタイプのデジタル化

reMarkable や Apple Pencil のようなツールを使えば、チームはアナログな紙の体験のようなスピードと多様性を楽しみながら、リモートで共同作業を行うことができます。

デジタルスケッチツールを使うことで、ペーパープロトタイプのプロセスは加速されます。デザイナーは、（画面を再描画することなく）より速やかに変更を加え、詳細なメモを添付し、完成したプロトタイプを UXPin のようなデザインツールにすぐにアップロードして、忠実度の高いプロトタイプを作成したり、ワイヤーフレームを作成したりすることができます。

ペーパープロトタイプがデジタル化されることで、紙やプラスチックのゴミも減って環境にも優しいですよね 。

ペーパープロトタイプのメリット・デメリット

スピードと柔軟性は別として、ペーパープロトタイプにはメリットもデメリットもあります。

以下の無料のeBook に載っているメリット・デメリットからいくつか挙げてみましょう（英語）

メリット：

• 速やかなイテレーション：１時間以上かけて完成させたデジタルモックアップよりも、５分で完成した紙のデザインを破棄する方が簡単。
• 低コスト：紙は安く、ツールやキットが追加されても破綻しない。
• 創造性の向上：鉛筆と紙の自由さで、実験と新しいアイデアが育まれる。デザインツールはデザインプロセスにおいて重要な役割を果たすが、デザインの初期段階では創造性を阻害する可能性がある。
• チーム構築：ペーパープロトプは、クリエイティブな環境でチームが一丸となれる貴重な機会となる。ペンと紙を使って作業することで、子供のようなエネルギーが引き出され、そこから絆が生まれ、同僚との関係が強くなる。
• 習得が一番ラク：誰もがアイデアをスケッチできるため、ペーパープロトタイプはマーケティング、開発、ステークホルダーなどの他部門を巻き込むのに最適な方法となる。
• ドキュメンテーション ：ペーパープロトタイプは優秀なドキュメンテーションとなる。例えばデザイナーは、プロジェクト全体を通して参照できるように、メモやアイデアのアウトラインを作ることができる。ペーパープロトタイプは優れた UX成果物である。

デメリット：

• ユーザーの反応がない：ユーザーからのフィードバックがないため、アイデアがうまくいくかどうかを知るのは難しく、ペーパープロトタイプを参加者とテストしたとしても、フィードバックは限られたものになると思われる。
• 不正確なフィードバック：UXチーム以外では、ペーパープロトタイプの解釈が大変である可能性があり、それで正確で意味のあるフィードバックが制限されてしまう。
• 潜在的に不要：UXPinのようなラピッドプロトタイピングツールでは、ペーパープロトタイプでデザインプロセスに不必要なステップが追加される可能性がある。UXPin にはあらかじめデザインシステムが用意されているため、デザイナーは忠実度の高い要素をドラッグ＆ドロップでサッとデザインして、作業用のプロトタイプを編集することができる。

１４日間のトライアルにサインアップして、UXPin を使って紙のデザインコンセプトを最終製品のように機能する高忠実度のプロトタイプにどれだけ早く変換できるかをぜひご覧ください。

ペーパープロトタイプを作るタイミング

Google のジェイク・ナップ氏は「ペーパープロトタイプは時間の無駄だ」と言っていますが、初期段階のコンセプト作りにはペーパープロトタイプが有効だと認めています。

一度紙からデジタルに移行したら、戻る理由はありません。新機能や製品の再デザインのために、紙のプロトタイプに戻るデザイナーもいるかもしれませんが、その場合でも、紙のプロトタイプまで戻る必要はないかもしれません。

とはいえ、紙のプロトタイプは初期段階の概念化に最適です。そのスピード、簡単さ、シンプルさにより、デザイナー以外の人も含むすべてのチームが利用でき、実験と創造性を育むことができます。‐ これはデジタルキャンバスでは実現できないことですですね。

また、ペーパープロトタイプは以下には理想的です：

• ブレーンストーミングのミーティングとセッション
• 初期段階での基本的な社内ユーザーテスト

ペーパープロトタイプの作り方

ペーパープロトタイプは、製品デザインの楽しみどころです。チームメンバーがブレインストーミングを行い、アイデアをスケッチする機会ですからね。

スケッチの綺麗さを気にする必要はありません。最高の UX デザイナーでも、別に素晴らしいスケッチアーティストというわけではないですし、そもそもこれは、自身のアイデアを視覚化して創造力を引き出すことが目標です。

ペーパープロトタイプの作成には、主に以下の３ステップがあります：

１．材料を準備する

紙、ペン、マーカー、付箋、はさみなどの材料を集めます。UI（ユーザーインターフェース）のスケッチに、ホワイトボードや大きな紙を使うのもいいかもしれません。

２．インターフェースをスケッチする

基本的な画面、UI、デザインの主要な構成要素を別々の紙に描き、そのスケッチを順番に並べることで、ユーザーの流れを表現します。

３．インタラクションのシミュレーションをする

ユーザーとのインタラクションの順序でスケッチをレイアウトします。ユーザーのアクションに基づいてスケッチを手動で切り替えてユーザー体験をシミュレーションし、フィードバックを集めてデザインを直していきます。

詳しいガイドについては、UXPinのプロトタイプに関する記事をご覧ください。

ペーパープロトタイプを作るための６つのヒント

1. プリンター用紙と安い鉛筆やペンを使う。罫線やラインが引いてあるノートは、多くの場合はデザイナーがたくさんのアイデアを練るよりも、線の間に描くことに気を取られて創造性が抑制されてしまう。
2. ウォーミングアップから始める！リラックスして流れに乗るには、数枚のスケッチが必要なこともある。クレイジーエイトは、同じ画面の多くのバージョンを素早くデザインするための素晴らしいペーパープロトタイプの手法であり、これを２，３ラウンド行うと、さらに発展させるアイデアがたくさん出てくるだろう。
3. モバイル優先型またはプログレッシブエンハンスメントのプロトタイプを作成する。最小のスクリーンから始めて、ビューポートを拡大縮小しながらレイアウトを調整する（これはモバイルと Web デザインに当てはまる）。拡大は、コンテンツを優先して、モバイルに変換されない複雑なデスクトップ用のレイアウトになるのが回避されることから、縮小よりもはるかに簡単である。補足: UXPinのオートレイアウトを使うと、自動的にデザインのサイズ、フィット、塗りつぶしがされることからモバイル優先型のデザインに便利な機能である。
4. １画面（１枚の紙）につき１枚のスケッチにこだわる。ペーパープロトタイプでは、紙片を順番に配置してユーザーフローを作成する必要があり、その入れ替えや、新しい画面の追加をしたりすることから、１枚の紙の上に複数の画面があると、このスピードと柔軟性が失われてしまう。
5. アイデアが浮かんだら反復する。目標は質ではなく量であり、紙でプロトタイプのアイデアをたくさん作ると、多くの場合、最終結果を得るために各アイデアから少しずつ取り出すことになる。これは、紙を使ったレゴ セットのようなものである。
6. ペーパープロトタイプがうまくいくには、計画を立てることが重要。十分な数のペン（黒の細いマーカーが最適）、紙、はさみ、のり、付箋、インデックスカード、テープ、厚紙、その他にもプロジェクトに必要と思われるものを用意する。ホワイトボードとマーカーも、ユーザーフローの概要を共同で描くのに最適。プロのアドバイス：ペーパープロトタイプを準備する仕事は、アート＆クラフト愛好家に割り当てる。どのチームにも少なくとも１人はいて、必要なものを十分すぎるほど揃えてくれるはず。

ペーパープロトタイプのテストと発表

UX部門外でペーパープロトタイプをテストして発表することは、常に厄介です。ステークホルダーやユーザビリティの参加者は、何が起こるかを「想像」しなければならないため、訳がわからなくなったり、提示しようとしている内容から焦点がそれる可能性があります。とはいえ、Jakob Nielsen の調査によると、ユーザビリティの問題の７５%は、ペーパープロトタイプのようなシンプルで忠実度の低いプロトタイプで特定できることが分かっています。

ペーパープロトタイプを発表してテストするためのヒントを以下に挙げてみましょう：

• 発表者以外の１人を「人間コンピュータ」または製品シミュレータ役に指名する：人間コンピュータ役の人は、スクロール、スワイプ、さまざまな画面への移動、その他の機能のシミュレーションをする。
• リハーサル：プレゼンターとシミュレーターが同期できるように、リハーサルは非常に重要。発表者は、シミュレータがプレゼンテーションに追いつくための適切なリズムを考案するといいかもしれない。
• 標準的なユーザビリティテストのベストプラクティスに従う – 「最低５人のユーザーを使ってテストを記録する」などの標準は、現在も適用されている。ユーザビリティの標準と実践方法に関する詳細については、当社のユーザビリティ・テスト・ガイド（無料）をこちらからダウンロード可能（英語）。
• ユーザーに紙のプロトタイプを渡して検査させる場合は、どこに注目して何をテストすべきかがわかるように、ガイダンスと注釈を必ず提供する。

UXPin でのプロトタイプ

モバイル アプリケーションを構築する場合でも、新しい Web サイトを構築する場合でも、UXPin でデザイナーは高度なプロトタイプを構築するためのツールを得られます。‐ 大抵の主要なデザインツールではこれができません。

でも本記事を鵜呑みにせず、１４日間の無料トライアルにサインアップして、次のプロジェクトでは UXPin の強力なプロトタイピング機能をぜひ実際にお試しください。

The post ペーパープロトタイプ： １０分でわかる実践ガイド appeared first on Studio by UXPin.

開発フローで思い浮かぶのは、デザインからコードにするという形ではないでしょうか？デザイナーはデザインツールを使って、プロトタイプを作成し、デベロッパーはそれをコードに変換するという、標準的な製品開発プロセスでしょう。

UXPin Mergeでは、画期的な「Code-to-Design（コードからデザインへ）」ワークフローによって、このプロセスをひっくり返します。そこで本記事では、「Code-to-Design（コードからデザインへ）」と、それが製品開発プロセスをどのように強化するかを、４つのケーススタディとともに見ていきます。UXPin Merge の詳細はこちら。

「Code-to-Design（コードからデザイン）」とは

「Code-to-Design（コードからデザイン）」は、UXPinがMergeの技術を使って開発した UX ワークフローです。UXPin Mergeを使うと、コード化されたUIコンポーネントを使って完全にインタラクティブなインターフェースを構築し、デザインが完了したら製品コードをエクスポートできます。ちなみにコンポーネントはデザインからコードに変換されるのではなく、そもそもがコードです。

「Code-to-Design（コードからデザイン）」のワークフローで、デザイナーやステークホルダー、エンジニアは以下のようなメリットが得られます：

• デザイナーは完全にインタラクティブなプロトタイプを作成し、それでデザインプロセスにおけるテストの範囲が広がる。
• デザイナーはゼロからデザインしないため、市場投入までの時間が短縮される。
• プロトタイプが最終製品のように動作するため、ステークホルダーはデザインのビジョンを把握することができる。
• デザイナーとエンジニアが同じ「信頼できる情報源（Source of truth）」を使うため、デザインのハンドオフがスムーズになる。
• チームがデザインシステムを共有することで、その導入が問題にならなくなる。
• ドラッグ＆ドロップのワークフローにより、デザイナーでなくても製品デザインをより身近に感じられるようになり、デベロッパー、ステークホルダー、リサーチャーなどが自分ででプロトタイプを作成できるようになる。

「Design to Code（デザインからコード）」と「Code-to-Design（コードからデザイン）」

コードに合わせてデザインすると不整合が生じる

デザインからコードへの変換は、従来の UX ワークフローです。デザインチームは標準的な画像ベースのデザインツールを使ってモックアップやプロトタイプを作成し、それをデベロッパーがコードに変換します。

「デザインからコードへ」のワークフローは、デザイナーとエンジニアの間にギャップが生じるところに最大の課題があります。そしてデザイナーは、そのギャップを埋めるのに、外部ツールを使い、詳細なドキュメントを書き、デベロッパーと会ってプロトタイプやインタラクションがどのように機能しないといけないかを説明しないといけません。

このような余分な作業や説明をしても、最終製品がデザイナーの仕様や期待を満たさないことはよくあります。デザイナーとエンジニアはどちらに原因があるかをめぐって言い合いになりますが、本当の問題は「言葉の壁」です。デザイナーはベクターグラフィックツールで仕事をし、エンジニアはコードで仕事をしますからね。

「Code-to Design（コードからデザインへ）」で連携を促す

「Code-to Design（コードからデザインへ）」のワークフローによって、デザイナーとエンジニアの間のギャップを埋めることができます。両者は異なる言語を話しますが、Mergeのようなテクノロジーにより、デザインと開発の間のコミュニケーションがしやすくなります。

デザインチームは視覚的なUI要素を扱い、エンジニアはそれらを動かすコードを扱います。つまり、同じコンポーネントを２つの視点から扱うことになります。

そしてデザイン システムで作業するチームは、この「コードからデザイン」のワークフローから最大のメリットを得られます。

「デザインからコード」のワークフローでは、チームは以下の２つのバージョンのデザインシステムで作業します：

• デザインツール用画像ベースUIキット
• プログラミング用 UI コンポーネントライブラリ

「コードからデザイン」の場合では、デザインチームとエンジニアが同じレポジトリから同じコンポーネントライブラリを使うことができるので、この断絶がなくなり、「信頼できる唯一の情報源（Single source of truth）」ができます。

「Code-to Design（コードからデザインへ）」のユースケース

「”コードからデザイン” というのは聞こえはいいけど、実際の製品開発にはどう反映されるのか」と思っていることでしょう。ここでは、企業が製品開発に「コードからデザイン」を使っているユースケースを４つ見てみましょう。

１．PayPal

２０１９年、PayPal は UXPin Merge を使って社内の製品開発プロセスを完全にデザインし直しました。PayPal の社内 UX チームには、６０以上の製品を管理するエンジニアが１０００人以上いるのに対してデザイナーは５人という独特な課題がありました。そしてどの製品も同じようには見えず、それぞれにユーザビリティやデザインの一貫性の問題がありました。

PayPal の UXリード EPX であるエリカ・ライダー氏は、この問題の解決を任されました。さらに複雑なことに、彼女は PayPal の製品チームが製品をデザイン、テスト、提供できるようなワークフローも作らないといけませんでしたが、彼らにはデザインスキルがなく、デザインツールの経験もほとんどありませんでした。

そこで、従来の画像ベースのツールを使ってソリューションをいくつか試した後、エリカは Merge を発見しました。そして PayPal の UX チームは Merge を使って、カスタマイズされた Fluent UI デザインシステムを UXPin と同期させました。

PayPal のステークホルダーは、この新しい「コードからデザイン」への投資の効果をテストしたいと考えていました。そこでエリカは試し単一ページのプロトタイプを２バージョン作成しました。１つは画像ベースのツールを使い、もう１つは UXPin Merge を使ったところ、結果は予想以上のものでした：

• 画像ベースのツール：１時間以上
• UXPin Merge：８分

Merge のプロトタイプには、はるかに優れた忠実度と機能があり、Paypal の製品チームもコーチングを受けることで、同じ結果を得ることができました。

PayPal のケーススタディ全文はこちら。

２．Iress

ソフトウェア開発会社の Iress は、システムの成熟度をデザインするのに以下の４つプロセスを踏んでいました。

1. PDF スタイルガイド
2. CSS 付き HTML パターンライブラリ
3. UI キットとコンポーネントライブラリ
4. リリースにデザインやコードが要らない、完全に統合された「信頼できる唯一の情報源（Single source of truth）」

Iress は、チームが「コードからデザイン」のアプローチを発見する以前は、デザインと開発のギャップをどのように埋めて最終目標に到達すればいいか分からず、３番目で行き詰まっていました。

そしてこのワークフローは、その時点で Iress にとっての要件をすべて満たしていました：

• 製品の構築とリリースに必要なコンポーネントをデザイナーとエンジニアに提供する単一のレポジトリ。
• シームレスなデザインハンドオフにより、デザイナーとエンジニアの連携がよくなる。
• ゼロからのデザインやフロントエンドのプログラミングが不要。
• デザインの劣化や組織間の不整合が発生しない。
• リアルでインタラクティブなプロトタイプで、ユーザビリティテスト参加者やステークホルダーは最終製品の正確な表現を得られる。
• ダークモードやマルチブランドのデザインシステムで、テーマの切り替えを試すことができる。

Iress についての記事はこちら。

３．TeamPassword

先述の２つのユースケースは企業向け製品でしたが、「コードからデザイン」手法はスタートアップ企業や小規模チームにはどうでしょう？ TeamPassword は、競争の激しいパスワード管理市場で事業を展開していますが、このスタートアップは、UX デザイナーがいないことがの最大の課題です。

パスワードや機密データを預かるスタートアップ企業にとって、ユーザビリティの問題やデザインの不整合は信頼を損ない、それで TeamPassword の評判が落ち、チャーンにつながってしまいます。

そこで TeamPassword のエンジニアは、コードプロトタイプを使ってデザインとユーザーテストをすべて行いました。ただそのプロトタイプは、製品の機能と UX（ユーザーエクスペリエンス）を正確に表現していましたが、アイデアを構築して反復するのには時間がかかりました。

２０２２年、TeamPassword は MUI デザインシステムに切り替えて、Merge を使って UXPin と同期させました。その際、エンジニアはプロトタイプを開発するのではなく、UXPin でカスタム MUI React ライブラリを使いました。そしてこの「コードからデザイン」のワークフローで、ユーザビリティの問題やデザインの劣化がなくなり、市場投入までの時間が大幅に短縮されました。

TeamPassword のデザイナーがデザインシステムレポジトリを更新すると、変更が自動的に UXPin に同期されるため、常に最新バージョンを使うことができます。また、Merge のバージョン管理により、チームは変更を追跡し、テスト中にバージョンを切り替えることができます。

TeamPassword のケーススタディはこちら。

４．dotSource

dotSource は、ドイツを拠点とするデジタル製品のコンサルティングおよび開発エージェンシーであり、複数のデザインシステムを駆使して、クライアントに製品やソリューションを提供しています。

dotSource が製品を提供する上で最も大きな問題となったのは、デザイン用の UI キットと開発用のコンポーネントライブラリという２つのデザインシステムによる冗長なプロセスと重複作業でした。そこでデザインシステムのドキュメントにより、チームが維持する必要のある３番目の部分が作成されました。

dotSource の「信頼できる唯一の情報源（Single source of truth）」は、実際には ”唯一” ではなく３つでした。これは、多くの組織がデザインシステムで遭遇する問題です。

同社は、「信頼できる唯一の情報源（Single source of truth）」をコードベースにしないといけないのはわかっていましたが、従来の画像ベースのデザインツールを使ってこのワークフローを実現する方法がわかりませんでした。

dotSource は Merge の Storybook 統合を使ってデザインシステムを UXPin と同期しました。そして Storybook により、リリースごとにデザイン システムのレポジトリ、ドキュメント、UXPin のコンポーネントの更新ができます。

dotSource の記事はこちら（英語）。

UXPin での「Code-to Design（コードからデザインへ）」の仕組み

コードコンポーネントを UXPin にインポートする際、製品チームには以下の選択肢があります：

• 製品のデザインシステムを読み込む
• オープンソースの UI ライブラリを読み込む
• 無料トライアル版で利用可能な内臓のライブラリを使う

そのライブラリを UXPin に導入する方法は以下の３つがあります。

• Git 統合： React コンポーネントライブラリをレポジトリから UXPin に同期する。
• Storybook 統合：React、Vue、Angular、Web Components、Ember など、多くのフロントエンドフレームワークを同期できる（全リストは Storybook のドキュメントを参照）。
• npm 統合：デザイナーは、MCM（Merge コンポーネントマネージャ）を使って、npmレジストリからオープンソースライブラリからUIコンポーネントをインポートできる。

npm 統合およびコンポーネントマネージャーの使用に関するチュートリアルが 以下のように３つあります。

• React-Bootstrap
• Ant Design
• MUI

Git と Storybook の統合は少し複雑なので、UXPin のテクニカルサポートチームと協力してMerge のセットアップを完了するには、技術的なスキルが必要です。

「Code-to-Design（コードからデザイン）」を始めてみませんか？無料トライアルにサインアップして、製品開発プロセスのスピードを上げてチームが同じ方向を進める方法をぜひご覧ください。UXPin Merge の無料お試しはこちら。

The post Code-to-Design（コードからデザイン）２０２４年版完全ガイド appeared first on Studio by UXPin.

Figmaでつくるプロトタイプは最終製品がどのように見えるかを視覚化し、デザインについての説明や、ユーザーフローを計画するには最適ですが、プロトタイプテストには不向きかもしれません。そこでUXPinの出番です。デザイナーはUXPinを使うことで、質の高いテスト結果をもたらすインタラクティブなプロトタイプを作成することができます。本記事ではこれら２つのツールについて詳しくみてみましょう。

主なポイント：

• Figmaはベクターベースのデザイン環境でリアルタイムでの連携を提供し、UXPinはコードベースのアプローチで高度なインタラクティブなプロトタイプを提供する。
• UXPinで提供するMergeなどの高機能により、複雑なインターフェースをFigmaよりも大幅に速く構築できる。
• プロトタイピングにおいて２つを比較した結果、UXPinでのプロトタイプは、Figmaで作成したときよりも８倍速く、よりインタラクティブであることがわかった。
• Figmaは、静的なモックアップ、低忠実度プロトタイプ、共同デザインの作成に優れているが、インタラクティブなプロトタイプ機能が欠けている。

UXPinが提供するMergeテクノロジーによって、デザインチームでもコードベースのプロトタイプの作成を可能します。これによって、デザインから開発への移行を効率化し、コストと時間を大幅に節約することができます。

デザインと開発のギャップを解消させ、UXPinのMergeテクノロジーで高忠実でインタラクティブ性のあるプロトタイプを作成してみませんか？詳しくはこちらのページをご覧ください。

Figmaとは

Figmaは、リアルタイムの連携を実現するベクターベースのデザインツールです。ワイヤーフレーム、モックアップ、プロトタイプ、情報アーキテクチャまで、様々なデザインアセットを作成することができます。

２０１６年にブラウザベースのベクターグラフィックス編集ツールとして誕生し、当時デザインツールの市場を独占していたAdobe製品に代わる人気ツールとなりました。多くのUX/UIデザイナーはFigmaのその使いやすさに惚れ込み、UIデザイン業務においてもFigmaが使われ始めました。

Figmaのプロトタイプは、他のチームにデザインについて説明するのに最適です。また、クリエイティブなプロトタイプ、デザインの探求、パワフルなドローイングを作成するのに優れています。一方、Figmaのプロトタイプでは開発環境の制約沿った高度なインタラクティブ性が欠けていますが、そこはUXPinでかなえることができます。

UXPinとは

UXPinは、部門横断的な連携向けのコードベースのフルスタックデザインツールです。インタラクティブ性のあるプロトタイピング機能はUXPinを使う上で最大の魅力であり、デザイナーは、最終製品のようなビジュアルと完全な機能性を持つプロトタイプを作成することができます。ライブラリやフォームを使うことで、ワイヤーフレーム、モックアップ、ユーザーフローマップ、情報アーキテクチャの作成も簡単に行うことができます。

UXPinのプロトタイプは、デザイナーがプロトタイプにインタラクションを追加して動きを加えることができます。テスト中でもユーザーの入力情報の保存や、ライブデータも使うことができるため、まさに “実物” のような操作性があります。

これらによって、デザイナーは次のようなことが可能となります：

• 堅牢でインタラクティブ性のあるプロトタイプの構築
• ユーザーやステークホルダーから高品質で有意義なフィードバックの獲得
• デザインハンドオフの効率化

FigmaとUXPin – プロトタイピングでの違い

Figmaは、コラボレーション機能とコンポーネントベースのアプローチによって、プロトタイプのための信頼性の高いソリューションを提供します。一方、UXPinではさらに高度なインタラクション機能と、Mergeテクノロジーによるデザインから開発へのシームレスなハンドオフを実現します。

UXPinとFigmaのプロトタイピング機能を簡単に比較してみましょう。

Figma:

• 基本的なインタラクションとトランジション： Figmaでは、デザイナーはクリック可能な基本的なトランジションを追加し、モックアップをより魅力的なものにすることができる。
• コンポーネントの作成とデザインシステム： デザイナーは、共有・再利用可能なコンポーネントを作成し、UIの一貫性を保つことができる。
• 協働デザイン機能： 複数のデザイナーが同時に同じデザインに取り組むことができ、それによってデザインプロセスが効率化され、集団での創造性が促進される。

UXPin:

• 高度でインタラクティブなプロトタイプ： 洗練されたプロトタイピング機能でステート、インタラクション、変数、式などの機能により、実物に近いプロトタイプを作成できる。
• Mergeの「Code-to-Design」手法： デザイナーは Reactコンポーネントをインポートして、最終製品と区別できないほどの「リアルな」プロトタイプを作成できる。また、Mergeはデザインと開発のギャップを埋め、シームレスな製品開発フローを提供する。
• リアルタイムの連携とユーザーフィードバック： UXPinのコメント機能は、チームメンバーやステークホルダーとの部門横断的な連携を促進する。また、ユーザーからのフィードバックをプロトタイプに直接取り込み、実際のユーザーのインサイトやステークホルダーからのフィードバックに基づいて、繰り返しデザインを改良できる。

FigmaとUXPinの比較 – 実際の使用例

シニアUXデザイナーのAnthony Hand氏は、UXPinとFigmaのプロトタイピング機能についての比較記事をMediumに書きました。チームは、関連するブランドカラーとサードパーティのアイコンを含む、カスタムのMicrosoft FluentのWebライブラリを作成しました。

彼はFigmaのFluent UIキットを使い、React UIライブラリのGitHubレポジトリをMergeを使ってUXPinにインポートしました。Reactコンポーネントには、レポジトリで定義されたスタイリングとインタラクティブなプロパティ、必要なコントロールとAPIを含みます。

対するFigma UIキットではFluent Design Systemの静的バージョンであり、デザイナーは関連の変数とインタラクションの設定が必要です。UXPinのReactコンポーネントと比べると、忠実度も機能もかなり劣ります。

実験

Anthony氏は、UXPinとFigmaのプロトタイピングの効率性を比較するために、両方のプラットフォームで同じ単一ページのプロトタイプを作成しました。Figmaではページのデザインで１時間かかったところが、UXPinではわずか８分で作成できました。

「UXPinのプロトタイプには、ライブドロップダウン、カレンダーボタン、ソート可能なデータテーブル、そしてインタラクティブな Highchartsの円グラフまでありました。」 – シニアUXデザイナー, Anthony Hand

Anthony氏がUXPinで作成したプロトタイプは、高品質で、エラーが少なく、Microsoft Fluentのライブコントロールを使用したインタラクティブな要素を備えていました。一方、Figmaのプロトタイプは８倍以上の時間を掛けてつくったにも関わらず、そのようなインタラクティブ性がなく、リアルタイムのインタラクションを減らすラスタライズされた画像に頼っていました。

Anthony Hand氏の見解

Figmaは、馴染みのあるグラフィックデザインのプラットフォームをWeb ベースで進化させたものであり、旧来のツールよりも進歩していますが、まだ限界があります。UXPinでは、コードベースのデザインアプローチで 「インタラクティブなプロトタイプ 」に重点を置いているため、デザイナーはライブコード要素を使ったデザインを作成でき、インタラクティブ性とリアル感がでます。さらに、UXPinでは、最小限の学習要件で単一のページに複雑なインタラクションを実装することができる機能があります。

「Figmaはもちろんすごくいいツールですが、UXPinの便利なスクリプティング機能を活用し、エンジニアが完成品で使用するのと同じライブHTML UIコントロールを使ったインタラクティブなUIをデザインできる方法を学んだ今、Figmaに戻れなくなりました。」シニアUXデザイナー, Anthony Hand

Figmaはプロトタイプ向きか

Figmaは素晴らしいUIデザインツールですが、最終製品のイメージをするためのインタラクティブなプロトタイプを作成するためには必要な機能が欠けています。ここでは、デザインプロセスにおいてFigmaを上手く使うための用途とその理由をいくつか見てみましょう：

• 静的なUIモックアップ： Figmaの直感的なUIと機能で、モックアップのデザインが難なくできる。
• 低忠実度（Lo-Fi）プロトタイプ： Figma は、画面間の基本的な遷移のみが必要なため、低忠実度のワイヤーフレームのプロトタイプに最適。
• 情報アーキテクチャ： デザイナーは、単一のアートボード上に画面を整理して、製品のアーキテクチャとユーザーフローのマッピングや視覚化をできる。
• 協働デザイン： Figmaでリアルタイムの連携がしやすくなり、それによってチームはコメント投稿やデザイン批評の実行、バージョン履歴へのアクセスができる。

Figmaでのプロトタイプの限界

以下を見ると、UXPinを検討したくなるかもしれません：

• インタラクティブ性のあるプロトタイピング： Figmaは、シンプルなクリック/タップのインタラクションを提供するものであり、ユーザーデータの取得や、ドロップダウンメニュー、カルーセル、アコーディオン、日付ピッカーなどの複雑なコンポーネントの作成は、Figmaではできない。
• ライブデータとAPI： UXPinと違い、Figmaでは ライブデータの読み込みができず、そのような複雑な統合には、エンジニアリングの入力が必要。そうなると、時間とリソースが増大してしまい、ほとんどのプロジェクトでは実現不可能になる。
• コードからデザインへ： Figmaはデザインからコードへの手法で動作する。つまり、デベロッパーはデザインをコードに変換する必要があり、時間のかかる複雑な作業である。Mergeがあれば、UXPinのコードからデザインへのワークフローによって、デザイナーはデベロッパーが使うのと同じ構成要素を使ってコードベースのプロトタイプを構築でき、製品開発ワークフローがシームレスになることで開発時間が大幅に短縮される。

UXPinでのプロトタイプ作成がいい理由

本記事に共通するテーマは「インタラクティブ性」であり、デザイナーは、現代のデジタル製品をインタラクティブなプロトタイプを使ってアイデアをテストすることを求められます。なぜでしょうか？

• 開発には時間とコストがかかる。デザインプロセスで問題を解決することで、組織は膨大な時間とリソースを節約し、それによって無駄な支出が減る。
• UXは、製品の採用、エンゲージメント、リテンションにとって極めて重要。インタラクティブなプロトタイプにより、デザイナーはデザインプロセスでユーザビリティの問題を解決し、製品の UXを向上させることができる。

デザイナーはプロトタイプやユーザーテストにおいてイメージベースのツールを使うと、デザインプロセスでのユーザビリティの問題やビジネスチャンスを見逃してしまいます。これによって、製品が提供するUXとバックログに変更を加えなければならず、負債や、回避できるはずのコスト増加に繋がってしまいます。

インタラクティブなプロトタイプがUXの負債を減らすには

Merge は、より良いテストとスムーズなデザインオフにより、無駄で回避可能なユーザー体験と技術的負債を減らすことができます。デザインチームは、プロトタイプ構築のためにデザインシステムのレポジトリからインタラクティブコンポーネントをインポートし、Figmaのようなイメージベースのツールではつくることができない 最終製品の正確なレプリカを作成することができます。

また、ユーザーとステークホルダーは、Mergeのプロトタイプを最終製品と同じように操作することができ、デザインチームは反復と改善のための正確で有意義なインサイトを得ることができます。

さらに、デザイナーとエンジニアがまったく同じコンポーネントを使うため、デザインハンドオフに必要なドキュメントや説明が少なくて済みます。デベロッパーは、同じレポジトリから同じUIライブラリをインポートし、UXPinからJSXの変更を適用して、最終製品を納品できます。

「UXPin Mergeによって、当社のエンジニアリング時間は約５０%短縮されました。数十人のデザイナーと数百人のエンジニアを抱える企業レベルの組織全体で、これがどれだけのコスト削減になるか想像してみてください。」  – UXリードデザイナー, Larry Page

より速い プロトタイプとイテレーション

Mergeは、ノーコード、ドラッグ＆ドロップのプロトタイピング環境をデザイナーのために効果的に作成します。Anthony氏のケーススタディからわかるように、Mergeに切り替えることで、同じUIライブラリを使って、Figmaよりも 8 倍速くUXPinでプロトタイプを作成することができました。

UXPinのプロパティパネルを使って、コンポーネントやプロトタイプの変更は早く効率的になります。それでも、デザイナーは単一の UI 要素に対して複数のバリエーションやステートを作成し、それを UXPinのパターンに保存することで効率を上げることができます。そしてデザイナーは、プロパティパネルで調整する代わりにコンポーネントを入れ替えるだけで、テスト中に即座にフィードバックを得ることができます。

「UXPinを使って、忠実度の高いプロトタイプを作成することができ、とても助かっています。忠実度の高いプロトタイプをより速く作成し、セッション後にすぐにフィードバックを得ることができます。修正箇所があれば、次のユーザビリティテスト参加者にはその変更を適用させ、今までよりもずっと早くフィードバックを獲得することができます。」プロダクト、UX、DesignOpsソートリーダー,  Erica Rider

UXPinのMergeテクノロジーを使ったインタラクティブコンポーネントで、プロトタイプレベルアップしませんか。詳細およびアクセスリクエスト方法については、こちらのページをぜひご覧ください。

The post 【 プロトタイプ 】FigmaとUXPin – できること、できないこと appeared first on Studio by UXPin.

ReactアプリまたはWebサイトを構築しているなら、プロトタイプで実際のReactコンポーネントを使うことをおすすめします。

その方法などについて、こちらの記事で詳しくご紹介していきます。

主なツール

• UXPin Merge
• Framer
• Storybook
• React-Proto

Git、Storybook、またはnpmからインポートしたコンポーネントを使って、Reactのプロトタイプを構築しませんか。

UXPin Mergeを試して、魅力的で制作準備の整ったレイアウトを１０倍速く作成しましょう。UXPin Mergeをぜひご覧ください。

UXPin Merge

UXPin Merge技術では、レポジトリからコードコンポーネントをデザインプロセスにインポートします。

製品のデザインシステムやオープンソースのライブラリをインポートして、高忠実度で完全に機能するReactプロトタイプを構築できます。

Mergeを使うと、ネイティブ アプリケーション、Webアプリケーション、さらにはテレビまで、クロスプラットフォームアプリケーションのプロトタイプを作成できます。

その際プロトタイプはブラウザ、または iOS およびAndroidアプリケーション用のUXPin Mirrorを介して確認できます。

Mergeを使ってコードコンポーネントをUXPinにインポートするには、以下の３つの方法があります：

• Git統合では、Reactコンポーネントを Gitレポジトリから直接インポートでき、Mergeの機能をフルに利用することができる。
• Merge の Storybook統合で任意のStorybookを接続できることから、React、Vue、Angularなどのより多くのフロントエンドテクノロジーにアクセスすることができる。
• npm統合では、Mergeコンポーネントマネージャーを使って npmレジストリ上のオープンソースのデザインシステムから各UI要素をインポートできる。

主な機能

• バージョン管理（Git 統合のみ）：デザインシステムのレポジトリに変更があると、自動的に UXPin に同期され、デザイナーに最新リリースが通知される。
• パターン（Git 統合のみ）：デザインシステムのコンポーネントを使った新しいパターンの作成や、他のデザインシステムの要素の取り入れなどで、ライブラリを増やすことができる。
• ドラッグ＆ドロップのワークフロー：UXPin のデザインライブラリからコンポーネントをキャンバスにドラッグして UI（ユーザーインターフェース）を作成する。また、プロパティパネルで定義済みのプロパティを調整して、スタイルやインタラクションなどを変更できる。
• 連携：製品チームは、UXPinの有料アカウントを持っていなくても、UXPinのコメントを通じてステークホルダーと連携できる。
• スペック モードとドキュメント： Mergeを使うと、デベロッパーはすでに同じレポジトリにアクセスできるため、デザインハンドオフがよりスムーズになる。その際、デベロッパーはSpecモードを使って、プロパティの検査、距離の測定、本番環境のコンポーネント CSS および JSXのコピー（Git 統合のみ）、製品のスタイル ガイドおよびドキュメントの表示を行うことができる。

料金体系

年間払いの場合では、１ヶ月あたり１１９ドル〜（Companyプラン）

また、AI機能などの新機能を搭載したMerge AIの提供を開始しました。

長所と短所

長所：

• 信頼できる唯一の情報源（Single source of truth）：UXPin Merge を使うと、デベロッパーが最終製品に使うのと同じ React コンポーネントをデザインプロセスでインポートして使えるため、デザイナーとデベロッパーの間のギャップを効果的に埋めることができる。
• 実際のデータ：デザイナーは、JSON、Google Sheets、または CSV を使って実際の製品データを組み込むことができる。また、変数を使ってユーザーの入力をキャプチャし、そのデータを使ってプロファイルアカウントの入力や、動的でパ個別化された UX（ユーザー エクスペリエンス）の提供もできる。
• インタラクティブなプロトタイプ：Reactコンポーネントをプロトタイプに使うことで、デザイナーは最終製品と見分けがつかないインタラクティブなレプリカを作成できる。

短所：

• Javascript に限定される： UXPin Merge は Javascript ライブラリおよびフレームワークでしか動作しない。
• 技術的なセットアップ：製品チームは、コンポーネントライブラリのレポジトリを Merge と互換性のあるものにするのに技術的な支援が要る。ただし、UXPin には ボイラープレートがあり、この作業のお手伝いをすべくテクニカルサポートが提供される。そしてデザイナーは、設定不要な MUI、Material UI、Ant Design、Fluent UI などのビルトインライブラリを使うことができる。

Storybook

StorybookJS は、デベロッパーがコンポーネントを分離して構築できる UI 開発環境です。デベロッパー、デザイナー、ステークホルダーは、各 UI要素のさまざまな状態を可視化できることから、コンポーネント駆動型の開発環境を構築できます。また、React などの様々なフレームワークに対応しています。

Storybookは社内のプロトタイプやコンポーネント主導の開発には優れていますが、ユーザーテストのためのツールや機能はありません。

なので、MergeのStorybook統合を使って、UXPinでプロトタイプを行うために組織の Storybookプロジェクトをインポートするのがおすすめの回避策となります。

Storybook と UXPin Merge を組み合わせることで、デザイナーとデベロッパー間のギャップを効果的に埋めながら、組織全体で「信頼できる唯一の情報源（Single source of truth）」が作られるのです。

主な機能

• コンポーネントストーリー： コンポーネントのさまざまな状態を表示するストーリーを作成できる。
• アドオンエコシステム： 強固なプラグインのエコシステムで Storybook の機能を拡張できる。
• コンポーネント駆動型の開発： 一度に１つのUI要素を開発し、それによってプロパティ、インタラクション、バリアントがすべて表示される。
• ドキュメント： ストーリーとコンポーネントに基づいたドキュメントを自動生成できる。
• 自動テスト： リリース前に複数のテストを実行し、コンポーネントがコード構文、デザイン原則、アクセシビリティ、その他のカスタム要件を満たしていることを確認できる。

料金体系

StorybookJS はオープンソースで無料で利用できますが、アドオンや統合には費用がかかる場合があります。

長所と短所

長所：

• フレームワークにとらわれない：Reactコミュニティでは著名だが、さまざまなJavascript フレームワークに対応している。
• 豊富なエコシステム： 多種多様なアドオンや統合により、Storybook をニーズに合わせてカスタマイズできる。
• 連携： デザイナー、デベロッパー、ステークホルダーが連携できるため、一貫した UI/UX が実現する。

短所：

• 技術的な専門知識： Storybook はデベロッパー向けツールであり、使用にはプログラミングと Javascript のスキルが必要。
• 設定： プロジェクトの複雑さによっては、すべてを正しく設定するのに時間がかかる場合がある。
• 習得： コンポーネント構造と使っているフレームワークの理解が必要。

Framer

Framer は、React Web サイトと Web アプリのためのノーコードデザインツールです。

このプラットフォームの最新のAI機能により、ちょっとしたキーワードでレスポンシブなスターターテンプレートを作成することができます。

主な機能

• コードに裏打ちされたデザイン： React コンポーネントでデザインすることから、プロトタイプから開発への移行が効率化される。
• Figma のプラグイン： Framer で使うために、Figma デザインを HTML に変換する。‐ ただ、その HTML は React に変換されないといけない。
• コードのようなアニメーション：コードを書くことなく、Javascript のようなアニメーションやエフェクトを追加できる。
• プロダクション対応コード： デベロッパーは、ReactのWeb サイトや Webアプリケーションを構築するために、Framer からコードをエクスポートすることができる。

料金体系

年払いの場合、１サイト（プロジェクト）につき１ヶ月あたり５ドルから。

長所と短所

長所：

• インタラクティブなデザイン： 現実的なインタラクションを実現するためのコードコンポーネントを使ったデザイン。
• ノーコード開発： コードを一切記述することなく、制作可能な Web サイトを作成できる。
• スターターテンプレート：Framer には、すぐに始められる Web サイトおよびランディング ページ テンプレートの膨大なライブラリがある。‐ 平均２９〜９９ドルのサードパーティの有料テンプレートもある。

短所：

• コスト：小規模なプロジェクトでは費用対効果が高いが、複数のサイトを運営する場合には、サイトごとの価格モデルは高くつく。また、スターターテンプレートを購入する場合は、コストが上がる。
• Web 専用：FramerはノーコードのWebサイトデザインツールであるため、プロトタイプの範囲が制限される。
• コンポーネントをインポートできない： UXPin Mergeとは異なり、デザインシステムや UIライブラリのインポートはできない。

React-Proto

React-protoは、Reactのデベロッパーのために特別にデザインされた プロトタイピングツール であり、Reactコンポーネントとその関係を作成するための視覚的なインターフェースを提供します。

デベロッパーは UI要素をドラッグ＆ドロップすることで、コードを記述することなくコンポーネント間の親子関係を確立し、それによってステートの場所やプロップの関係を指定することができます。

主な機能

• コンポーネントツリーの可視化：アプリケーション全体の構造とコンポーネントの関係を視覚化する。
• インタラクティブ性：プロトタイプを操作して、ビジュアルツリーに反映された変更を確認する。
• ステート管理：ステートの場所を指定し、データの流れを把握する。
• コードのエクスポート：ビジュアル デザインを機能的なReactコードに変換して、フロントエンド開発を開始する。

料金体系

React-protoはオープンソースなので、無料で使えます。

長所と短所

長所：

• より速いプロトタイプ：React-protoのドラッグ＆ドロップ インターフェースにより、デベロッパーはコードを書くよりも早くコンポーネントとプロトタイプを編集できる。
• コスト効率が高い：オープンソースであるため、全デベロッパーおよびデザイナーにとってコストに優しいオプションとなる。
• コード生成：デザインのコードへの変換がしやすいことから、デザインと開発の間の壁が低くなる。

短所：

• 技術的なスキルが必要：React-protoはデザイナーにとって使いやすいツールではなく、効果的に使うには、React の深い経験などの技術スキルが必要。
• 機能が制限されている：React-protoにはオープンソースツールとしての機能があるが、ユーザー テストには不向き。
• サポートなし：React-protoには、Github のコミュニティ以外でのサポートやオンボーディングがない。

Reactを使用したWebサイトとアプリケーションのプロトタイプ

素晴らしいReactプロトタイピングツールはありますが、デザイナーにとって使いやすく、使い慣れた作業環境を提供しているプラットフォームは UXPinしかありません。

UXPinは、見た目も操作感も他のデザインツールと同じですが、UXPinでデザイナーが React、Vue、Angular などのコード コンポーネントを使ってプロトタイプを作成できるようになることで、プロトタイプの幅が広がります。

Git レポジトリ、Storybook、またはインポートされた npm パッケージからの React コンポーネントを使って、本番環境に対応したレイアウトを構築しませんか。

UIを作成して生産性を向上させましょう。 UXPin Mergeをぜひご覧ください。

The post React を使ったおすすめの プロトタイピングツール appeared first on Studio by UXPin.

完璧なWebサイトは、スムーズな制作と立ち上げ作業を１回やって作られるものではありません。

シームレスで完全な機能を備えたサイトは、入念なプロトタイピングの賜物なのです。

プロトタイプで、Webサイトから初期の不完全な部分を取り除くことができ、サイトの効果を最大化する機会がもたらされます。

多くの場合、企業の Webサイトは投資家や顧客に与える第一印象となります。

なので、プロトタイプを通じて Webサイトを完成させる方法を理解するのは、ビジネスの早期成功のために極めて重要です。

そこで本記事では、Webサイトプロトタイプについて詳しく見ていきましょう。

実際にユーザーとテストできるプロトタイプを作成してみませんか。UXPinはインタラクティブな プロトタイプを作成 し 、チーム全体が一体となるUIデザインツールです。こちらから UXPinをぜひ無料でお試しください。

Webサイト プロトタイプとは

出発点となるサイトの初期バージョンであり、プロトタイプの作成によって、探求、改良、完成の余地が効果的な方法で生まれます。

また、プロトタイプの最も優れた点の一つとして、サイトを公開する前に、開発のためのスペースを作ることが挙げられます。

プロトタイプは、低忠実度（Lo-Fi）フォーマットで始め、サイトのフォームと機能の簡単なアウトラインを含めるといいでしょう。

このアウトラインで、最終的な製品のために意図された詳細とインタラクティブなデザインが全て高忠実度（Hi-Fi）のプロトタイプへ発展できます。

Web サイトプロトタイプの柔軟性で、全ステークホルダーにメリットがもたらされます。

デザイナーと開発者は製品を完成させるためのスペースを確保でき、早い段階でステークホルダーの意見を取り入れてインターフェースの現実的なアイデアにつながります。

そして顧客でさえ、プロトタイプが開発に役立つ完璧な UI（ユーザーインターフェース）から恩恵を受けます。

Web サイトプロトタイプのメリット

ビジネスにどのようなメリットがあるかをイメージできるように、Web サイトプロトタイプがもたらす最も注目すべき影響に焦点を当ててみましょう。

視覚化

視覚的に魅力的なプラットフォームは、プロトタイプのような視覚的な情報をもとにしたプロセスを通じて作成するのが最適です。

そして強力なシステムでは、サイトの初期イメージが完全に機能するものに発展するまで、複数回のイテレーション（反復）が可能です。

サイト制作の各ステップをリアルタイムで視覚化できるため、制作ステップに関わってインスピレーションを得る機会が各関係者にもたらされます。

例えばデザイナーやデベロッパーは、サイトを完璧なものにするために、常に自分の作品を微調整したり、対話したりすることができます。

また、プロジェクトの方向性を積極的に評価できるため、インタラクティブなビジュアルがなければチームの進捗や目標を十分に把握できないことがあるかもしれないステークホルダーにもメリットがあります。

早期のフィードバック

プロジェクトを完成させたものの、ある時点でその方向性が間違っていることに気付いてプロジェクトをやり直さないといけなくなることほど、時間を食う上に不毛なことはありません。

プロトタイプは、このような開発後期での落とし穴を避けるための効果的な戦略です。

チームが構築の全段階でデザインと対話できるようになれば、フィードバックは生成も実行もしやすくなります。

つまり、いつでもプラットフォームの方向性をテストし、方向転換することができるため、完成品が目標を達成できていない可能性ははるかに低くなります。

UX テスト

最終製品はユーザーあってのものですから、デザインプロセスのできるだけ早い段階でユーザーの意見を取り入れてはどうでしょうか。

製品が完成する前に、UI とユーザーデザインをプロトタイプで実際のユーザーにテストすることができます。

これによって、完全にインタラクティブな体験ができるようになり、ユーザーはウェブサイトの機能を全てテストして、フィードバックを提供することができます。

リスク軽減

ウェブサイトの設計には、サイトが公開されて初めて明らかになる隠れた落とし穴が潜んでいることがあり得ます。

例えば、わかりにくいナビゲーションや一貫性のないデザイン スタイルなどのUIに関する問題で、サイトの影響力が下がる可能性があります。

インタラクティブなプロトタイプで、サイトのフォームや機能の問題が公開前にわかりやすく提示されることによって、こうしたリスクが軽減されます。

なので、プロトタイプがあれば、コストのかかる複雑な作業も、わずかな微調整で済みます。

また、プロトタイプを用いて、製品がステークホルダーのビジョンに合致していることを確認することで、機能性以外のリスクも減らすことができます。

サイト制作中に社内の誰もが簡単にレビューできるようになれば、会社の目標との整合性をずっとチェックしやすくなります。

明瞭なコミュニケーション

まとまりがあり、スムーズに機能するプラットフォームは、つながりの強いチームを生み出します。

一般的なチームワークを育む方法はいくらでもありますが、単一の製品に関するコミュニケーションは、情報源を共有することで一番うまくいきます。

その際プロトタイプは、ウェブサイトデザインチームのコミュニケーションのために完璧な情報の中心になってくれます。

このフォーマットでは、メンバー全員からの投稿の閲覧や対話ができるため、メンバー全員の足並みが揃い、さまざまな改善点について話し合うことができます。

効率的なイテレーション

完全に公開されたウェブサイトを編集するのは非常に複雑なプロセスですが、適切なツールを使えばそれを回避することができます。

プロジェクトの新しいイテレーションを簡単に繰り返し作成できる機能で、最高の製品を構築することができるようになります。

プロジェクトの新しいイテレーションを作成するための効果的かつ効率的なプロセスにより、チームは公開前に多くの編集を行い、より創造的なコンセプトを追求することができます。

そしてその結果、出来上がったサイトはスムーズに運営され、型にはまった競合他社のサイトとは一線を画すものになるのです。

ユーザー中心のデザイン

ユーザーリサーチはここまでしかできません。このような形のユーザー統合はコンセプト作りには有効かもしれませんが、プラットフォームが開発されるにつれて、より具体的なユーザーインプットが必要になってきます。

そこでプロトタイプだと、サイト独自の方法でユーザーのインタラクションを探求する機会が得られます。

サイトのプロトタイプを操作してレビューする機会をテストユーザーに与えることで、チームはどのような改善ができるかをより深く理解することができます。

多忙なデザインチームでは見逃してしまうような問題も、ユーザーによって明るみになり、その情報でインパクトのある改善が促されることもあります。

スコープの確定

スコープを明確にしてそれを維持するのは、どんなプロジェクトにおいても重要なことであり、Webサイトも例外ではありません。

 Webサイト制作 には複数の人が関わるため、スコープが定まらないままでは、不要なプロジェクトに多くの開発時間とリソースが割かれることになりかねません。

プロトタイプはアウトラインのような役割を果たすことから、チームは早い段階で作業範囲を決めることができます。

どのような機能が必要かを特定することで、どこにフォーカスするかの基盤ができ、プロジェクトのスコープから外れた余計な部分がすぐにとわかるので軌道修正することができます。

ステークホルダーの承認

ステークホルダーはサイトのデザインについて深く理解していない場合があり、それで製品を説明して承認を得ることが難しくなりますが、プロトタイプは、ステークホルダーがプロジェクトを理解してそれを承認しやすいように、正確な視覚的資料を提供してくれます。

コスト削減

ミスの発見が遅れれば遅れるほど、そのミスは大きくなり、費用もかさむ傾向にあります。

デザインミスやプロトタイプの欠陥を早期に解決することで、ミスがサイトの最終バージョンで金銭的な負担に発展するのを防ぐことができます。

デザインの探求

探求は、簡単でリスクのないときに最も魅力的で効果的なものになる傾向があります。

プロトタイプで、デザイナーは創造的でリスクのない空間を得ることができ、最高のプロトタイピングツールを活用して、さまざまなデザインツールと簡単にアクセスできます。

この形式の探索により、サイトを目立たせ、閲覧者に印象を与えることができるような新しいデザインスタイルの機会が開かれます。

Webサイトプロトタイプの作り方

プロトタイプの可能性を最大限に引き出すために、始める前に考慮すべき重要な点を以下で見てみましょう。

予備作業を行う

よくできたアイデアに共通するのは「リサーチ」であり、「なぜ」、「誰のために」「どのように」サイトをデザインするのかを理解するのは、何よりも優先すべきことです。

なので時間をかけてユーザーリサーチを行い、ターゲットとするユーザーを特定しましょう。

ユーザーが何を求めているかを理解し、そのコンセプトと目的を一致させることで、成功の土台を築くことができるのです。

このような初期の段階で答えが全て得られるとは思えませんが、将来のウェブサイトに関して考えられる核心的な質問にはそれぞれ以下のように答えを考えてみるものいいかもしれません：

• ウェブサイトの目的は何か？

• ウェブサイトはブログ、販売プラットフォーム、またはその他の何かに分類されるか？

• どのような読者が想定されるか？

• 閲覧者はウェブサイトとどのように接触するか？

• サイトの成功にどんな機能が必要か？

• ウェブサイトは、同カテゴリーの他のサイトとどのように似ているか？

• また、どのように違うのか？

事前準備があるほど、次のデザインステップがより簡単で正確になります。

準備の詳細については、製品開発ガイドの記事をご覧ください。

最初のビジュアルをスケッチする

重要な要素と目標をすべて頭に入れたら、いよいよプロトタイプの前段階を作成します。

このアウトラインは「ワイヤーフレーム」と呼ばれることが多く、サイトの主要機能の概要を示すことを目標としています。

このラフ案では、サイトの情報アーキテクチャ、インタラクティブ要素、基本的なデザインアイデアなどが詳しく説明されるべきです。

ただこの段階では、詳細や正確さは主な目標ではないので、ワイヤーフレームはモックアップツールや手描きのスケッチで作成することができ、ペーパープロトタイプのノウハウがあれば、この段階でそれが大いに役立ちます。

UXPinでプロトタイプを作成する

ここでメインベントである、柔軟性、インタラクティブ性があり、完成した製品を表現できるプロトタイプです。

ワイヤーフレームが、デザインの重要な側面に焦点を当てることでこのプロセスの先陣を切り、プロトタイプで、新しいディテールを追加することができます。

従来のプロトタイプのプロセスは長く複雑になることがありますが、テクノロジーの進歩によってプロトタイプはシンプルになりました。

UXPin はおすすめツールの１つであり、Web サイトデザインにおけるプロトタイプの効率と効果を上げるために特別に設計されています。

UXPin のプロトタイプは、チームが簡単に不完全な部分をチェックしてフィードバックを得ることができるように、プレビューが簡単にできるように設計されています。

プレビューは、複数のブラウザでテストしたり、モバイルデバイスで表示したりすることもでき、あらゆるフォーマットで基準を満たしていることを確認できます。

また、UXPin Mirror を使えば、モバイルデバイス上でリアルタイムにアップデートの違いを確認することもできます。

また、高度な機能のライブラリにより、完成したサイトの細部まで正確に表現できます。

インタラクティブなコンポーネントのさまざまな状態を作成したり、スムーズなナビゲーションに対応するドロップダウンメニューをデザインしたり、タブメニュー、ナビゲーションドロワー、その他多くのオプションを使って整理したりできます。

プロトタイプの段階でのカスタマイズはこれだけに留まりません。ユーザー体験を個別化するために変数を追加し、バーチャルショッピングカートのようにさまざまな値を計算するために式を使うことができます。

また、ユーザーのインタラクションをもとに、サイトがさまざまな反応をするように、条件付きのインタラクションを生成することもできます。

UXPinのプロフェッショナルなデザインのプロトタイピングツールでは、プロフェッショナルな Webサイトに必須の複雑な機能はすべて、コードを学ぶ必要のないシンプルなシステムで作成することができます。

コンセプトを検証し、Web サイトプロトタイプを改良する

目標に合ったプロトタイプを作成したら、いよいよテストです。

インタラクティブで完全に機能するプロトタイプを用いて、ユーザーが Web サイトをどの程度ナビゲートできるかをテストすることができます。

ユーザーが特定の機能を発見してそれを使うのにかかる時間を記録して課題を特定し、デザインがどのように受け入れられるかを観察します。

フレキシブルなプロトタイプを使えば、ユーザーの反応に基づいて簡単に修正を行うことができ、その修正を再テストして Web サイトの試作品を磨き上げることができます。

UXPinにおける Web サイトプロトタイプの実例

ユーザー向けにデザインする場合、「最終的な目標」と「その途中の行動」を知る必要があります。

両者はそれぞれ「コンテンツ」と「ユーザーフロー」と呼ばれ、共に優れた Web サイトの中心を形付けます。

でも、情報のアウトラインからインタラクティブなデザインにするにはどうすればいいのでしょうか？

以下で、コンテンツ一式をプロトタイプに速やかに変える方法を見てみましょう。

ステップ１：コンテンツインベントリーの作成

何をデザインするのか？多くのデザイナーは、ユーザーがより多くの時間を費やす情報を調べる前に、外側から始めて内側に向かって作業し、内容とフレームワークを作成します。

内側からデザインを始めると、ユーザーを念頭に置いてデザインすることになります。

すぐに見てもらいたいものは、次に注目してもらいたいものよりも優先されます。

例えば、ナビゲーションバーは CTA（行動喚起）ほど注目に値しません。

同様に、コンテンツ優先型のアプローチは、当然ながらモバイル優先型のアプローチでもあるということも重要です。

モバイルデバイスには、画面サイズ、帯域幅など、より多くの制限があるため、このようなパラメーターの範囲内でデザインすると、容赦なくコンテンツを優先せざるを得なくなります。

コンテンツインベントリとは、エンドユーザーに関連する要素をすべて含む、整理されたリスト、スプレッドシート、または同等の文書のことであり、よくできたインベントリだと、セクションに分けられた情報の階層として機能します。

完成したコンテンツインベントリーには、ユーザーフローの可能性が全て示されます。

ステップ２：十分な情報を得た上でコアフローを計画する

銀行の Web サイトのような複雑なプロジェクトでは、次のような多くのフローが必要になります：

• パスワードの変更
• 投資オプションの確認
• 401k（米国の確定拠出年金）の確認
• 小切手の注文
• 新規口座開設・解約
• 他行への送金、他行からの送金
• クレジットカード残高の支払い

各フローでは、ユーザーが複数のコンテンツ ページを通過する必要がありまが、このチュートリアルでは、最も重要なフローの１つであるクレジットカードの支払いプロセスだけに焦点を当てます。

プロトタイプを作成するときは、まず最もリスクの高い、あるいは最も基本的なユーザーフローに焦点を当てましょう。

このユーザーフローを書き出してみましょう：

• ホームページにアクセスする。
• ログイン情報を入力し、ダッシュボードにリダイレクトする。
• クレジットカードの残高をクリックする。
• 残高を支払う口座を選択する。その後、リクエストを送信し、残高が完済されたことを確認する。

ステップが多くあるように思えますが、必要な決定は、「支払うかどうかの決定」、「支払い元のアカウントの選択」、「トランザクションの確認」の３つです。

プロトタイプでは、各ステップが明確かつ簡単でないといけません。

ステップ３：プロトタイプを作る

今回は、架空の銀行でクレジットカードの残高を返済させるユーザーフローを構築しましょう。

実際のコンテンツがあれば、この目標はミッドファイ（Mid-fi）を作ることです。

箱型のワイヤーフレームのような Lo-fi プロトタイプや、ブランディングをそのまま見せる Hi-fi プロトタイプと違い、Mid-fi プロトタイプは、ユーザーがタスクを達成するために取る意思決定の流れを示します。

イテレーションの回数が限られている場合、視覚的なデザインに時間を浪費することなく、ユーザーテストに十分な詳細を提供できる Mid-fi プロトタイプが最適です。

Mid-fi では、機能的なプロトタイプは、以下が示されます：

• UI 要素の正しいレイアウト（ナビゲーション、主要コンテンツなど）
• 基本的な色
• 基本的なインタラクション（高度なアニメーションやステートはまだない）
• 正しいタイポグラフィ
• 正しい寸法の画像

以下で、銀行の Web サイトで機能させる方法を見てみましょう。

ログインページ

ログインは簡単です。ユーザーは、銀行のホームページにあるシンプルなフォームで自分の口座を安全に入れますが、ユーザーにとって銀行やそのブランドとの最初の接点であるこの必須のステップをおろそかにはしません。

カラースキームからマイクロコピーに至るまで、すべてが親しみやすく、かつプロフェッショナルなトーンに合っていないないといけません。

口座の概要

ユーザー名とパスワードを入力すると、アカウント情報を含むダッシュボードが表示されます。この画面は、その人にアカウントの概要を伝えることが目的であり、広告もアップセルもなく、二次的な情報は片側に押しやられています。画面はすべて彼らのお金に関するものです。

また、支払い時かどうかの判断のために、この画面にクレジットカードの残高を表示します。

支払いプロセス

ユーザーフローによると、その人が次に取る行動は、カード残高の支払いの選択です。

これは簡単なクリックであり、この時点で、お金を引き出す口座を選択しないといけません。

決断には時間と認知力が必要なので、口座選びはシンプルにすべきであり、各口座は、口座名と残高などの必要最小限の情報が挙げられているだけです。

次に、その人は３つ目の決定、つまり取引の決定に辿り着きます。この時点で必要なのは、トランザクションの内容だけであり、つまり、前の決断の選択肢を排除することができます。

そして新しい画面、あるいはシンプルなモーダルウィンドウに、その決定に必要な情報が提示されます。具体的には、口座名、支払い金額、承認と不承認のボタンなどになります。

できました！右のボタンをクリックすると、残高がクリアされたことが確認できます。

実物に近づくことでうまくいく

このデザインの各画面には、実際のマイクロコピーに加えて、実際の色、タイポグラフィ、レイアウトが使われていることに注目してください。完全には洗練されていませんが、テストを始めるには十分です。

この時点では、基本的なインタラクションをいくつか追加して、ユーザーが画面をクリックできるようにするだけです。

それが終わったら、フィードバックを集めて、必要に応じてイテレーションを行い、ユーザーとテストを行います。

そしてプロトタイプを完成させるには、各ユーザーフローで上記のステップをすべて繰り返すだけです。

UXPinで自分のプロトタイプを作ろう

人がインタラクティブな Web サイトを訪れるのは、タスクを達成するためであり、ウィジェットを使ったり、グラフィックを鑑賞するためではありません。

なので、実際のコンテンツに沿った流れは、プロトタイプのUIを開発するのと同じくらい重要になります。

コンテンツ中心のデザインで、その道に沿って進むべき道が見つかります。

このガイドで学んだことを試してみたい方は、UXPinの無料トライアルをぜひお試しください。

The post Webサイト制作 のためのプロトタイプ【 実践ガイド】 appeared first on Studio by UXPin.

デザイン ワークフローを次のレベルに引き上げてみませんか？このチュートリアルでは、UXPin Merge の世界を総合的に掘り下げていくことから、React アプリのコンポーネントを UXPin エディタにシームレスに統合して、忠実度の高いプロトタイプを作成できるようになります。

静的なデザインの時代は終わりました。UXPin Merge だと、React コンポーネントを動的にリンクすることができ、それによってプロトタイプが常にコードベースの最新開発と同期していることが保証されます。

本記事で、UXPin Merge の可能性を最大限に引き出す準備をしましょう！

UXPin Merge とは

UXPin Merge は、本番環境に対応したコードで裏付けられたコード化された UI コンポーネントでデザインするためのテクノロジーです。これは、非常に現実的で正確なプロトタイプのためのコードベースのデザインツールである UXPin の一部であり、この技術により、仕様書、JSXコード、その他のアセットをすべて取得してデベロッパーに渡すことができ、製品開発ワークフロー全体を８.６倍速くすることができます。

UXPin Merge のチュートリアル – この技術の使い方

UXPin Merge のテクノロジーはドラッグ＆ドロップの UI ビルダーのように機能します。

UXPin のデザインライブラリからコンポーネントを取り出してキャンバスに配置し、そしてレイアウトの配置とコンポーネントのプロップ設定が終わったら、 リリース可能なReact コード（Tailwindライブラリの場合はCSSコード）を開発環境にコピーする、またはStackBlitzで開きます。

また、UXPinではテンプレートとパターンをいくつか提供しているので、チームのオペレーションを自動化するシンプルなダッシュボードから、フロントエンドをバックエンドから切り離した複雑なEC ストアまで、自由に何でも作ることができます。

Webデベロッパーの RachelによるUXPin Merge の使用方法のビデオ チュートリアルをぜひご覧ください。

Youtube でご覧ください。UXPin Mergeチュートリアルのフル再生リストはこちら。

独自のコンポーネントを統合する方法 ‐ ステップ・バイ・ステップ

UXPin Merge は、MUI、Ant design、Bootstrap などのオープンソースライブラリの Storybook コンポーネントと React コンポーネントに対応しています。

本記事でさらに詳しく見ていき、React ベースのライブラリを Mergeに統合して、日常的にコードを使ってデザインするのがいかに簡単であるかを示したいと思います。

コーディングの仕方を学ばなくても、すべてできます！

UXPin Merge で、ユーザーは既存のカスタム React コンポーネントをシームレスにインポートし、実際のコードを使ってインタラクティブなプロトタイプを作成することができます。そしてこれは、従来のデザインツールにはないものです。

これにより、デザイナーはデザインツール内で 「第２の 」デザインシステムを手動で管理する必要がなくなり、代わりにチーム全体に「信頼できる唯一の情報源（Single source of truth）」を提供することができます。

そしてその結果、デジタル製品を構築する際のデザイナーとデベロッパー間の連携が絶たれることがなくなりました。

このチュートリアルでは、時間の節約のために Mozilla の React Todo App にある例を Merge と統合することにしました。

これで、統合後はアプリのコンポーネントを使って UXPin 内でインタラクティブな Todo リストのプロトタイプをデザインできるようになるでしょう！

あと、Merge へのアクセスをリクエストすることから始めることを忘れないでください（こちらでできます）。認証プロセスとセットアップが完了したら、コードでデザインする準備は完了です！また、GitHub との統合について心配する必要はありません – コードベースがどこにあるべきかという要件はありませんので、お好きなものをお使いください！

コンポーネント

Todoアプリには以下の React コンポーネントがあります：

• フォーム – ToDo の項目を作成する。
• FilterButton – 現在の状態で Todoをフィルタする。
• Todo – ToDo リストの項目。

これらのコンポーネントは `src/components` ディレクトリにあり、以下のスクリーンショットに概略が示されています：

このチュートリアルが完了すると、デザイナーはそのコンポーネントでプロトタイプを作成できるようになります。実際の カスタムDS（デザインシステム） には、おそらくコンポーネントが３つ以上含まれていますが、このチュートリアルで説明するコンセプトは 皆さんの DS にも適用できるはずです。

UXPin Mergeのセットアップ

まず、フォークして次のリンク https://github.com/mdn/todo-react を複製します。 次に、CLI（コマンドラインインターフェース）を含む UXPin Merge NodeJS パッケージをインストールします。

• プロジェクトフォルダの cd todo-react に移動する。
• UXPin Merge とその CLI NodeJS バンドルを次のようにインストールする： yarn add @uxpin/merge-cli–dev
• UXPin Merge のビルド ディレクトリを無視する：echo ‘/.uxpin-merge’ >> .gitignore

カスタムデザインシステムには、さらに以下の設定ファイルが必要です：

1. uxpin.webpack.config.js
2. uxpin.config.js

UXPin は通常、既存の Webpack ビルドプロセス全体を使う必要はなく、UXPin のビルドには、より最小限のデフォルトのビルドが使われます。そして uxpin.webpack.config.js ファイルを作成し、それに以下のコードを貼り付けます：

</p>
const path = require("path");
const webpack = require("webpack");
 
module.exports = {
    output: {
      path: path.resolve(__dirname, "build"),
      filename: "bundle.js",
      publicPath: "/"
    },
    resolve: {
      modules: [__dirname, "node_modules"],
      extensions: ["*", ".js", ".jsx"]
    },
    devtool: "source-map",
    module: {
      rules: [
        {
          test: /\.(s*)css$/,
          use: [
            {
              loader: 'style-loader'
            },
            {
              loader: 'css-loader',
              options: {
                importLoaders: 2
              }
            },
          ]
        },
        {
          loader: "babel-loader",
          test: /\.js?$/,
          exclude: /node_modules/,
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react'],
          }
        },
      ]
    }
}
<p>

UXPin Merge で使うコンポーネントは、レポジトリのディレクトリの一番上にある uxpin.config.js ファイルでファイルディレクトリを指定しないといけません。以下のコード スニペットでわかるように、現時点では「Form」コンポーネントの src/components/Form.js のみを追加しており、他のコンポーネントはチュートリアルの後半で追加します。

uxpin.config.js を作成し、以下の内容をファイルに貼り付けます。あとは、 Webpack が Babel-loader が使ってアプリバンドルを作成します。babel をインストールするには、次のコマンドを使います： yarn add babel-loader –dev からの yarn install

module.exports = {
  components: {
    categories: [
      {
        name: 'General',
        include: [
          'src/components/Form.js',
        ]
      }
    ],
    webpackConfig: 'uxpin.webpack.config.js',
  },
  name: 'Learn UXPin Merge - React Todo list tutorial'
};

おめでとうございます👏 これで、Form コンポーネントを表示するのに必要な最小限の設定は完了です。

Experimental モード

uxpin.webpack.config.js` で提供される設定を使って、Experimental モードではコンポーネントがバンドルされてブラウザウィンドウが開きます。その際、UXPin エディタと同様の方法でコンポーネントをレイアウトできます。そして Experimental モードが読み込まれたら、フォームコンポーネントをサイドバーからプロジェクトキャンバスにドラッグ＆ドロップします：

フォームコンポーネントはありますが、スタイリングがありません。なので、Global Wrapper Component を作ります。

Global Wrapper Component を使って CSS スタイルを適用する

カスタムデザインシステムと同様に、この Todo アプリにもグローバルスタイルが含まれています。それらは `src/index.css` ファイルで指定され、コンポーネントには全てこのファイルで指定されたスタイルが必要です。また、このファイルは Global Wrapper Component で読み込むことができ、このコンポーネントは、UXPin キャンバスにドラッグしたコンポーネントを全て包み込みます。

ラッパーファイルを作成してみましょう：

以下をコピーして `UXPinWrapper.js` に貼り付けます

import React from "react";
import '../index.css';

export default function UXPinWrapper({ children }) {
  return children;
}

i

この `import ‘../index.css’;` の行で、各コンポーネントをレンダリングする前に CSS スタイルが読み込まれることが保証されます。

UXPin に、このラッパーファイルを使うように指示する必要があります。そして uxpin.config.js に以下を追加します：

wrapper: 'src/wrapper/UXPinWrapper.js',

Experimental モードでは、スタイル付きの Form コンポーネントで新しいブラウザウィンドウが開くはずです：

カスタマイズ可能な名前を持つ FilterButton の追加

では、UXPin Merge に FilterButton を追加してみましょう。このボタンは Form コンポーネントの下に表示されます：

このコンポーネントの追加は Form コンポーネントと同様ですが、ボタン内に表示されるテキストを指定する機能もデザイナーが使えるようにしたいと思います。これは `prop-types` パッケージを使ってやってみましょう。

コンポーネントの propTypes はコンポーネントを編集するときに UXPin のプロパティパネルにマッピングされます。既存の FilterButton コンポーネントは prop-types を使っていないので、これを`FilterButton.js`に追加しましょう：

import React from "react";
+ import PropTypes from 'prop-types';

function FilterButton(props) {
  return (
@@ -15,4 +16,9 @@ function FilterButton(props) {
  );
}

+ FilterButton.propTypes = {
+   name: PropTypes.string
+ }

+FilterButton.defaultProps = {
+  name: 'Button Name'
+};

export default FilterButton;

src/components/FilterButton.js’`を `uxpin.config.js` に追加し、./node_modules/@xpin/merge-cli/bin/xpin-merge -disable-tunneling で再起動してください。コンフィグファイルを更新したため、再起動が必要です。Experimental Modeが起動すると、サイドバーに新しい「FilterButton」コンポーネントがパネル上に表示されているはずです。これをクリックしてキャンバスにドラッグします。

３つのコンポーネントのうち２つが UXPin Mergeで動作するようになりました。残る１つは Todoコンポーネントです。

ラッパーでTodoコンポーネントを追加する

最後のコンポーネントである「Todo」に進みます。これは、UIで Todoアイテムのリスト内に表示されます。

FilterButton を追加するときに、propTypes を追加するために FilterButton.js ファイルを編集しました。では、Merge 固有の変更は分離して、コンポーネントのソースコードは変更したくない場合はどうすればよいでしょうか？その場合は Todo コンポーネント専用のラッパーを作成するといいでしょう。これは、CSS スタイルを適用するために使った Global wrapper component と似たコンセプトですが、Todo コンポーネント専用になります。

次のように入力します：

mkdir -p src/components/merge/todo 

touch src/components/merge/todo/Todo.js

以下のコードをコピーして Todo.js に貼り付けます。

</pre>
import React from 'react';
import PropTypes from 'prop-types';

// Import the original component
import TodoM from '../../Todo';

function Todo(props) {
  return <TodoM {...props}/>
}

Todo.propTypes = {
  /**
   * If `true`, the todo will be marked as completed.
   */
  completed: PropTypes.bool,

  /**
   * The name of the todo.
   */
   name: PropTypes.string,

  toggleTaskCompleted: PropTypes.func,
}

Todo.defaultProps = {
  name: 'Do Laundry'
};

export default Todo;


<pre class="wp-block-syntaxhighlighter-code">

大元の Todo コンポーネントを `TodoM` としてインポートし、新しく定めた `Todo` 関数でこのコンポーネントを返します。そして、新しく定めた `Todo` ラッパー関数で FilterButton コンポーネントと同じように propTypes を指定します。

uxpin.config.js に「src/components/merge/todo/Todo.js」を追加し、./node_modules/@uxpin/merge-cli/bin/uxpin-merge -disable-tunneling を使って再起動します。そして Experimental が新しいウィンドウを起動したら、Todo コンポーネントをクリックしてキャンバスにドラッグします：

Todo コンポーネントとデフォルトの「Do Laundry」Todo 名が表示され、このデフォルト名は Merge を使う時のみ適用されます。

UXPinにプッシュする

デザインシステムを UXPin にプッシュするまでは、コンポーネントは自分にしか見えません。なので、デザインチームがそのコンポーネントを使えるようにするには、コンポーネントバンドルを UXPin にプッシュする必要があります。Merge のデザインライブラリの作成とプッシュには次の２つのステップが必要です：

１．UXPin UI 内でライブラリを作成する

1. UXPin アカウントにアクセスする。
2. UXPin エディタに入る。
3. 新しいライブラリを作成する。
4. React コンポーネントをインポートするオプションを選択する。
5. Auth トークンをコピーする（このトークンは誰とも共有せず、git レポジトリにチェックインしたファイルにも配置しない。このトークンによって、自分のアカウントでライブラリに直接アクセスできるようになる)。プロセスは以下ようになる：

２．uxpin-merge CLI でライブラリをプッシュする。

前の停止で作成したトークンを使って、プロジェクトのレポジトリ内から以下を実行します：

./node_modules/@uxpin/merge-cli/bin/uxpin-merge push –token YOUR TOKEN 

これでデザインチームは Merge ライブラリにアクセスできるようになりました。

UXPin で Mergeライブラリを使う

Merge のデザインライブラリがプッシュされたので、UXPin エディタで以下のようにテストしてみましょう：

• ブラウザで UXPin エディタを再読み込みする。
• エディタの左下にある「Learn UXPin Merge（UXPin Merge を学ぶ）」のデザインシステムを選択する。
• サイドバーのコンポーネントをクリックしてキャンバスにドラッグする。

これでしっかりとしたプロトタイプができるはずです：

それで、デザイナーはどのようにしてプロトタイプをデベロッパーに引き渡すのでしょうか？

プレビューとエクスポート

UXPin で簡単なプロトタイプを作ったので、それをアプリにエクスポートする準備ができました。出力をプレビューし、Spec モードを使ってコンポーネントの JSXコードをコピー＆ペーストします。

エディタの右上の再生ボタンをクリックします。プレビューが読み込まれたら、上部の 「Spec 」のリンクをクリックしてください。コンポーネントをクリックして、右側のパネルでそれを生成する JSX コードを見ることができます：

ちなみに、デザインシステムの初期バージョンをプッシュするのは素晴らしいことですが、時間をかけてかなりの数のアップデートをプッシュする必要があるでしょう。

アップデートのプッシュ

FilterButton には、現在アクティブなフィルターを示す「押された」状態があります。ライブの React アプリを見ると、「押された」状態と「押されていない」状態の違いは以下のようになります：

この状態のサポートを追加しましょう。src/components/FilterButton.js`を以下のように変更します：

FilterButton.propTypes = {
-   name: PropTypes.string
+   name: PropTypes.string,
+   isPressed: PropTypes.bool
}

その変更を git にコミットし、UXPin にプッシュします：

Merge のコンポーネントは、直近でプッシュされたコードに自動的に同期されます。最新のものを表示するには、UXPin エディタを表示しているタブを再読み込みします。そして FilterButton を選択したら、エディタの右パネルに、新しい “isPressed” のプロパティが表示されます。

この状態を有効にするにはこれを選択します：

今後変更を加える場合も、同じ流れ（git commit + uxpin-push）に従います。その際プロトタイプは、プッシュされた最新バージョンのコンポーネントを自動的に使います。

製品開発を８.６倍スピードアップ

React アプリを作成し、そのコンポーネントを UXPin Merge にプッシュしました。また、コンポーネントを変更したり、新しいコンポーネントを追加したときに更新をプッシュする方法も学びました。これで、デザインチームはこのコンポーネントを使って、UXPin エディター内で忠実度の高いプロトタイプを作成できます。

このプロジェクトのソースコードは GitHub で閲覧することができます。より高度な Merge テクニックについては、Merge のドキュメントを参照するか、salesjp@uxpin.com までお問い合わせください。

UXPin Merge をまだお持ちでない方は、コードによるデザインを最大限に活用するために、まずは忘れずにアクセスリクエストの手続きを行ってください！そして UXPin Merge をぜひ無料でお試しください。

The post コードによるデザイン – UXPin Merge のチュートリアル appeared first on Studio by UXPin.

現代のWeb サイトやアプリは、UI（ユーザーインターフェース）の開発、保全、拡張のためにフロントエンドフレームワークに依存しています。

ReactのJavascriptライブラリは、デジタル製品を構築するための多くのコンポーネントライブラリを備えた、間違いなく最もよく使われているフロントエンドフレームワークです。

そこで本記事では、Reactのおすすめライブラリと、次のプロジェクトに適したライブラリの選び方を見ていきます。

UXPin Mergeで Reactコンポーネントライブラリ を同期できるので、すぐにリリース可能なレイアウトを超高速で構築することができます。こちらからUXPin Mergeをぜひご覧ください。

 Reactコンポーネントライブラリ を選ぶ際に考慮すべき６点

以下は、次のプロジェクトで Reactコンポーネントライブラリ を選択する際に考慮すべきポイント６つです。

※これらは完全版のリストではないので、この中には皆さんが構築中の製品に当てはまらない場合もあります。

１．人気

GitHubの星評価では各Reactライブラリの人気をサクッと比較でき、npmの週間ダウンロード数でも、そのコンポーネントライブラリの利用者数を見ることができます。

一般的に言うと、Reactライブラリの人気は、「React」というものの存在が十分に確立され、その目的を果たしているということになります。

２．問題

星評価と同じように、GitHubにあるライブラリの問題を見れば、そのライブラリの人気やメンテナンスの程度がわかります。

そのライブラリに最小限の問題が見つかったとして、それが今作ろうとしている製品に影響を与えるでしょうか？

３．ドキュメントおよびサポート

Reactライブラリを選択する際、ドキュメントは重要な検討事項となります。トラブルに遭遇したり、特定のコンポーネントの使い方を知りたくなったりするたびに Stack Overflowに走るのは避けたいですからね。

そしていいドキュメントというのは定期的に更新されており、ライブラリを包括的に理解することができるものです。

また、Reactライブラリがクリエイターから直接サポートを受けられるのか、専用のコミュニティフォーラムを経由してサポートが受けられるのかも知っておきたいところです。

課題を克服するために専門家のアドバイスが必要な場合もありますからね。

問題を速やかに解決してプロジェクトを進めるには、（たとえお金を払うことになっても）助けを求めることができるのが極めて重要です。

４．カスタマイズ

コンポーネントライブラリを使うことの欠点の１つに、その制約とカスタマイズの欠如があります。

プロジェクトによってはカスタマイズは関係ありませんが、ユニークなUIを開発したいのであれば、独自のデザインシステムを構築できるというのは不可欠です。

ライブラリのドキュメントを調べて、コンポーネントをカスタマイズする手順や、希望する結果を簡単に実現できるかどうかを確認しましょう。

５．ブラウザやデバイスの互換性

デザインするアプリによっては、コンポーネントライブラリのブラウザとモバイルの互換性を知りたいでしょう。ブラウザやデバイスの互換性を調べるには、GitHub の 「issues」 や Stack Overflowで検索するのが一番手っ取り早いです。

６．アクセシビリティ

アクセシビリティは、時間がかかりますがデジタル製品のデザインに欠かせない考慮事項です。

Reactライブラリがコンポーネントのデザインの際にアクセシビリティを考慮していない場合は、それを自分で行う必要があり、ポイント３番目と４番目、つまり「ドキュメント」と「カスタマイズ」に戻ります。

結局、どの Reactコンポーネントライブラリ が一番いいのか

プロジェクトに最適な Reactコンポーネントライブラリ は、特定のニーズや好みによって異なりますので、決定する前に、ドキュメントの質、コミュニティのサポート、活発な開発、プロジェクトの要件との整合性などの要素に基づいて各ライブラリを評価することをお勧めします。

ライブラリを比較するには、デザイン思想、提供されるコンポーネント、テーマ設定機能、ドキュメント、コミュニティサポート、エコシステムなど、さまざまな面の評価が含まれます。

Material-UI (MUI) と Ant Designを例にとってみましょう。

Material-UIは、Material Designのシステムに従った Reactコンポーネントの包括的なセットを提供します。これには、ボタン、カード、フォーム、ナビゲーションなどのコンポーネントと、幅広いカスタマイズ オプションががあります。

Ant Designには、レイアウト、フォーム、ナビゲーション、データ表示など、エンタープライズアプリケーション用に調整された豊富なコンポーネントコレクションがあり、データの可視化やビジネスロジックに特化したコンポーネントを提供します。

 Reactコンポーネントライブラリ ５選

２０２４年の React ライブラリ５選を以下で見てみましょう。

注：GitHub の星評価とNPMのダウンロードに関する情報は、２０２４年３月時点のものです。

１．MUI (Material-UI)

• GitHub のスター数：９１３,０００
• 週間 NPM ダウンロード数：３４０万
• 公式サイト：mui.com

MUI は、最も包括的で広く使用されている Reactコンポーネントライブラリ の１つであり、世界で最も広範なUIキットの１つである GoogleのマテリアルデザインUIに基づいて構築されています。

コンポーネント

MUIには、モバイルや Web アプリケーション、Web サイト、ウェアラブルアプリまで、あらゆるものを構築するデザイナーのための膨大なコンポーネントライブラリがあります。

また MUI Core は、日々のデジタル製品で目にする基本的なUIコンポーネントを提供します。

MUI X には、データテーブル、データピッカー、チャートなどの複雑なUI を構築するための高度な Reactコンポーネントのリストがあります。

MUI コードコンポーネントを使ったデザインを試してみたい方は、UXPin のトライアルに申し込むと１４日間UXPinにアクセスできます。UXPinのMUI 5 キットについてさらに読む。

テーマ設定とカスタマイズ

MUI の最大の魅力の１つに、コンポーネントをテーマ設定してカスタマイズできる点があります。デザイナーは、MUI を基盤としてデザインを速やかに拡張することができますが、ライブラリを適応させて、製品や組織のためのカスタムデザインシステムを構築することもできます。

また、デザイナーは、コンポーネントをカスタマイズする際にユーザビリティの問題を回避するために、Material DesignとMUIの包括的なガイドラインを活用することもできます。

さらに、MUI には、ダッシュボード、EC サイト、ランディングページなどの React のテーマテンプレートを購入できるテンプレートのマーケットプレイスもあります。

ドキュメント

MUIのドキュメントは、コンポーネントライブラリと同様に詳細かつ包括的だと言えるでしょう。

MUI のキュレーターは、インストール、使用方法、カスタマイズ、アクセシビリティなど、デザイナーやデベロッパーにステップバイステップの手順やガイドラインを提供すべく、細心の注意を払っています。

また YouTubeには、MUIのユーザーやコントリビューターの大規模なコミュニティから、ベストプラクティス、チュートリアル、ヒントやコツ、ハウツーガイドなどを提供するビデオが大量にアップされています。

２．React-Bootstrap

• GitHub スター数：２２２,０００
• 週間 NPM ダウンロード数：１３０万
• 公式サイト：react-bootstrap.github.io

２０１１年に設立された Bootstrap は、Webサイトやアプリケーション向けの最も古くて広く使われているオープンソースの CSS フレームワークの１つです。

また、Bootstrapは、モバイル優先型の Web 開発を優先した最初の CSS フレームワークの１つで、デザイナーはレスポンシブな Web サイトをサッと構築したり拡張することができます。

React-Bootstrapは、Bootstrap の Javascript を置き換えると同時に、JQuery のようなリソースの重い依存関係を排除して、包括的かつシンプルな Reactコンポーネントライブラリ を構築します。

コンポーネント

Bootstrapに馴染みがあれば、React-Bootstrap の一般的な外観のコンポーネントライブラリがすぐにわかるでしょう。

CSS の前身と同様に、React-Bootstrapは、モバイル アプリケーションよりも Webデザインを優先するUIコンポーネントを特徴としています。

テーマ設定とカスタマイズ

React-Bootstrapは、最小限のスタイリングで非常に汎用的なので、デザイナーにとって微調整やカスタマイズがしやすくなっています。

Bootstrap では、クラスとバリアントが定められているため、CSS を使ってコンポーネントを選択してカスタマイズするのは簡単です。

また、Bootstrap の長い歴史と幅広い用途のため、管理ダッシュボードから多目的な Web サイト、Eコマース、ランディングページなど、あらゆるもののための無料およびプレミアムの React-Bootstrap テーマやテンプレートが大量に見つかります。

ドキュメント

React-Bootstrapには、MUI ほど詳細で包括的ではないものの、優れたドキュメントがあります。React-Bootstrap はそのシンプルさと命名規則により、理解、使用、カスタマイズが最も簡単な React ライブラリの 1 つとなっています。

Bootstrap は、Stack Overflow でも幅広く紹介されているので、ほとんどの問題の答えが見つかるでしょう。また、アドバイス、チュートリアル、デザインプロジェクトなどを提供するブログやYouTubeビデオも多数あります。

３．Semantic UI React

• GitHub スター数：１３２,０００
• 週間 NPM ダウンロード数：２５３,０００
• 公式サイト： react.semantic-ui.com

Semantic UI React は、React-Bootstrap に代わるものとして人気があります。

React-Bootstrap と同様に、Semantic UIは、そのコントリビューターが Reactコンポーネントを構築するために使うオープンソースの CSS フレームワークとして始まりました。

コンポーネント

Semantic UI React には、Web サイトや Web アプリケーションのための幅広い UIコンポーネントがあり、そのコンポーネントは、ミニマルでシンプルでありながら、Bootstrap よりもクリーンでモダンなスタイリングを提供します。

また、Semantic UI React は、１,６００以上の無料アイコンと７,８６４以上のPro（有料）などの FontAwesome のアイコンセットを使用しています。

テーマ設定とカスタマイズ

Semantic UI は直感的でわかりやすい命名規則を使っているので、コンポーネントのカスタマイズが簡単であり、ドキュメントには、Semantic UI React を使ったテーマ設定のステップバイステップガイドもあります。

ちなみに、MUI やReact-Bootstrapとは異なり、Semanticにはテンプレートオプションがほとんどありません。

ドキュメント

Semantic UI Reactのインタラクティブなドキュメントでは、CodeSandbox のサンプルが提供され、コードを検査したりコンポーネントで色々と試すことができます。

また、ドキュメントでは、コンポーネントを多角的に視覚化するために、例、コード、プロップを切り替えることができます。

４．Ant Design (AntD)

• GitHub スター数：８９９,０００
• 週間 NPM ダウンロード数：１２０万
• 公式サイト：ant.design/docs/react/introduce

Ant Design (AntD) も、中国最大のオンライン マーケットプレイスである Alibaba の親会社である Ant Group によって開発された、広く使用されている人気の Reactコンポーネントライブラリ です。

MUI と同様に、Webアプリケーションとモバイルアプリケーションの両方に膨大なコンポーネント ライブラリを提供します。

ちなみに AntD は、本記事で紹介されている、JavaScript の一種である TypeScript を使う唯一の React ライブラリです。

コンポーネント

AntDには、モバイルデバイス用の無限スクロールや Pull-to-Refresh のような UI パターンなどの、デスクトップとモバイル用の膨大なコンポーネントライブラリがあります。

また、Ant Design ProComponents には、複雑なインターフェースを構築するための高度な React UI 要素（MUI Xに類似）があります。

また、プロジェクトをスタートさせ、UI をより速く構築するための既成のテンプレートやスキャフォールドの膨大なライブラリーもあります。

テーマ設定とカスタマイズ

AntD は、デベロッパーがコンポーネントをカスタマイズしたりテーマ設定したりするために、デザイントークンや変数を使います。また、UI ライブラリは Less を使っており、全 AntD 変数の完全なリストを GitHub で提供しています。

ドキュメンテーション

AntD の包括的なドキュメントで、使用とカスタマイズのための指示をステップバイステップでしてもらえます。また、CodeSandBox や CodePen、StackBlitz で各コンポーネントを検査することもできます。

５．Chakra UI

• GitHub スター数：３６４,０００
• 週間 NPM ダウンロード数：５２３,０００
• 公式サイト：chakra-ui.com

Chakra UI は、Segun Adebayo によって設立されたナイジェリアベースの Reactコンポーネントライブラリ であり、Chakra の無料コンポーネントライブラリか、インターフェースをより速く構築するための既成の複雑な UI コンポーネントを提供する Chakra UI Pro のどちらかを選ぶことができます。

コンポーネント

Chakra UI のコンポーネントライブラリは、Web ベースのアプリケーションやWeb サイトに対応しており、好みに応じて TypeScript か Javascript React コンポーネントを選べます。

そして Chakra のデザイナーはWAI-ARIA標準に従っているため、すべての要素がアクセシブルです。

また、スタイリッシュな UI コンポーネントは Semantic UI に似ており、「ダーク」と「ライト」のオプションが用意されています。

テーマ設定とカスタマイズ

Chakraのデザイナーは、製品とブランドの要件を満たす変数を使って完全にカスタマイズできる UIライブラリを作成しました。

また、Charka は、Create React App、Framer Motion、React Hook Form、および React Table とも統合して、ライブラリの使用法とカスタマイズを拡張します。

ドキュメント

Chakra UIには、ガイド、ビデオチュートリアル、サンプル、FAQ、主要なチームメンバーとつながるためのリンク、活発な Discord コミュニティなどの優れたドキュメントがあります。

Chakra のユーザーは React ライブラリに対して非常に一生懸命で熱意があり、質問の際は常に誰かしらいます。

UXPin Merge を使った React コンポーネントによるデザイン

React ライブラリを使う際の課題の１つに、実際のコンポーネントを使って UIをデザインできるツールが限られている点が挙げられますが、UXPin Mergeを使うと、Gitレポジトリ、Storybook、または npm から Reactコンポーネントを使ってレイアウトを構築することができます。

その仕組みをご覧になりませんか。こちらからUXPin Mergeをぜひご覧ください。

The post おすすめの Reactコンポーネントライブラリ appeared first on Studio by UXPin.

プロトタイプは、デザイナーが製品の外観を仕上げ、デザインを検証し、改善点を見つけるために構築されます。一方、最終製品は市場にリリースされる実装されたデザインのことをいいます。

プロトタイプも最終製品も、プロダクトデザインプロセスでよく聞く用語ですが、この２つの具体的な違いを探ってみましょう！

主なポイント：

• プロトタイプは、製品のデザインプロセスでの成果物であり、最終製品のイメージである。デザイナーはプロトタイプを使ってさまざまなアイデアを検証し、ユーザーやステークホルダーから製品についての意見を聞き、デベロッパーに何を作る必要があるかを示す。
• 最終製品は、市場に出せる状態の製品のことを指す。バックエンドとフロントエンドの設計があり、エンドユーザーが完全に使用できる状態。プロダクトデザイナーが作成、検証したプロダクトデザインに基づいてデベロッパーが最終製品を構築する。
• プロトタイプと最終製品の間には、 リソース、作成する理由、柔軟性、ライフサイクル、機能性のレベルなどの６つにおいての違いがある。

実装しやすいインタラクティブなプロトタイプをデザインをつくりませんか？他社よりも速く、開発した製品を市場に送り出しましょう。UXPin Mergeについてこちらからぜひご覧ください。

プロトタイプとは

プロトタイプとは、デザインコンセプトを具体的またはインタラクティブに表現したものです。

プロトタイプが最終製品をシミュレーションすることで、デザイナーやステークホルダーは、機能性をテストして、デザイン上の決定を検証し、フィードバックを集めることができます。

洗練された最終製品に対して、プロトタイプは多くの場合、核となる機能や単一のユーザーフローにのみ焦点を当てた不完全なものであることから、インサイトやユーザーインタラクションに基づく反復や変更を手短にできます。

デザイナーがデザインプロセスのさまざまな段階で利用するプロトタイプには、以下のような種類があります：

• ペーパープロトタイプ：紙やホワイトボードに描くシンプルなワイヤーフレームで、ユーザーフローのテストや情報アーキテクチャの視覚化に最適。
• ワーキングプロトタイプ：データを扱い、ユーザーのアクションに反応するプロトタイプだが、完成した製品ではなく、進行中のもの。
• 機能的プロトタイプ：最終製品の外観を模倣したプロトタイプだがバックエンドのコードがない状態。
• インタラクティブプロトタイプ：クリック、スクロール、移動などのマイクロインタラクションが追加されたプロトタイプ。

最終製品とは

最終製品とは、市場に投入されるアプリやWebサイトのことであり、よく「最終製品」や「完成品」と呼ばれ、プロトタイプの最後の反復から派生します。

これは、製品デザインのプロセスから何度も繰り返されたデザイン、ユーザーからのフィードバック、そして厳密なテストの結果を表しています。

意図された機能が全て備わり、エンドユーザー体験のために最適化されたことで、この製品は、ターゲットとするユーザーによる発売と消費の準備が整った状態であるということになります。

プロトタイプ と 最終製品 の５つの主な違い

違い１：意図された目的

プロトタイプ：

• アイデアを具体的に、あるいはインタラクティブに表現する
• テストおよびフィードバック収集のツールとしての役割
• ステークホルダー、デザイナー、デベロッパー間のコミュニケーションの促進
• 本格的な開発を行う前に、デザイナーがデザインやユーザビリティの問題を特定し、修正できるようにする
• 開発にリソースを投入する前に、新製品の実現可能性を検討する

最終製品：

• エンドユーザーに完全で機能的なソリューションを提供する
• 製品のデザインプロセスにおけるデザインの決定、フィードバック、改良の実現を表す
• ユーザーのエンゲージメント向上や売上向上など、ビジネス目標の達成を目指す
• ターゲットユーザーのグループに合わせた、最適化されたエクスペリエンスの提供

違い２：調整への柔軟性

プロトタイプ：

• 迅速な変更と反復のためにデザインされている
• フィードバックのループが短くなり、デザイン要素のピボットや修正がしやすくなる
• 間違いやデザイン上の欠陥は予測され、リアルタイムで対処される
• 複数のデザインソリューションの探求とテストを重視

最終製品：

• 変更はより慎重に行われ、多くの場合、大規模なテストと検証が必要となる
• ユーザーからのフィードバック や 分析、バグ、開発のアップデートに基づく反復作業
• 調整は、より広範なシステムや関連機能に影響を及ぼす可能性がある
• 柔軟性はあるが、定義された製品のフレームワークの制約の範囲内での話

違い３：創造性に必要なリソース

プロトタイプ：

• 通常、必要なリソースや投資が少ない
• モックアップをサッと作成するために、入手しやすいツールやコンポーネントを活用することに重点を置く
• デザインツールで、変更と調整がより低コストで効率的になる
• 完全にコミットすることなく、費用対効果の高い実験が可能

最終製品：

• 時間的にも金銭的にも、より大きな投資が必要
• 高品質なコンポーネント、コーディング、リソースを使って、持ちの長さと拡張性を実現
• 改造や修正によって費用が増加する可能性がある
• 期待される長期的な収益と製品の安定性により、初期の高額なコストが正当化される

違い４：プロトタイプと最終製品のライフサイクル

プロトタイプ：

• 特定のプロジェクトにおけるテストや検証のための一時的なモデルとして機能する
• 頻繁に変更される可能性が高く、プロジェクトがリリースされれば破棄されるかもしれない
• 長期的な使用や実世界での挑戦に耐えるようには作られていない

最終製品：

• 長期的な実用性と運用を考慮したデザイン
• セキュリティの脆弱性やその他のプログラミング上の課題からの保護など、実世界での使用を想定して構築されている
• 定期的なアップデートとメンテナンスを受けるが、製品の核となる機能は維持される
• 新しいイテレーションがそれに取って代わるまで、つまり数カ月から数年間、その役割を果たすことが期待される

違い５：機能性のレベル

プロトタイプ：

• 主に主要機能をステークホルダーやユーザーに紹介する
• 完全な機能を備えていない場合があり、多くの場合、プレースホルダーやダミーのコンテンツが含まれている
• 視覚的またはインタラクティブな UI（ユーザーインターフェース）を模倣し、それによってフィードバックを集められるようになる
• 特定の要素やユーザーフローのテストに重点を置き、多くの UI や機能は除外される場合がある

最終製品：

• 意図した機能が全て統合されて完全に機能する
• 機能の信頼性を確保するために厳格な品質保証を実施
• エンドユーザーのエクスペリエンスに合わせ、機能が全てユーザーのニーズに合致するように調整されている
• 洗練されたインターフェース、シームレスなナビゲーション、最適化されたパフォーマンス

最終製品を作る前にプロトタイプが必要な理由

プロトタイプは、製品を成功に導くために重要な役割を果たすものであり、青写真のような役割を果たします。そしてユーザーに共感され、ビジネス目標を達成し、市場で際立つ製品を作るためにチームを導きます。

以下はその方法です：

• リスクの軽減： プロトタイプで、チームは大きなリソースを投入する前に製品のアイデアをテストすることができ、それによってコストのかかるミスを回避することができる。
• ユーザー中心設計： プロトタイプを使った早期のユーザーテストによってユーザーのニーズが明らかになり、最終製品が確実にユーザーの期待に応えられるようになる。
• フィードバックのループ： プロトタイプが反復的なフィードバックを促すことで、デザイナーは継続的に製品を改良し、完成させることができる。
• ステークホルダーの調整： デベロッパーから投資家まで、各々が画一的な理解を共有できるよう、製品ビジョンを具体的に示す役割を果たす。
• 開発の効率化： デベロッパーがより明確な全体像を把握することによって、やり取りが減り、効率的なコードが保証される。

プロトタイプから最終製品になるまで

以下のステップ・バイ・ステップのワークフローは、製品開発チームが研究からプロトタイプ、最終製品までどのように進めるかが示されています。

ステップ１：問題を理解する

• 市場における問題やニースを特定する
• 初期段階の市場調査を実施し、需要と潜在的なユーザーの関心を測る

ステップ２：ユーザーリサーチ

• ユーザーのインサイトを集めるための調査やインタビュー、観察を実施する
• ユーザーのニーズやペインポイント、要望を理解する

ステップ３：アイデア出し

• 潜在的なソリューションと機能のブレインストーミングをする
• 最初のアイデアをスケッチまたはワイヤーフレーム化する

ステップ４：プロトタイプをデザインする

• リサーチとアイデアに基づく、忠実度の低いプロトタイプを作成する
• UXPin のような専門的な UX デザインツールを使って、忠実度の低いインタラクティブなワイヤーフレームを作成し、アイデアを反復して改善する
• 忠実度の低いデザインを忠実度の高いプロトタイプに変換する
• ユーザーテストの前にプロトタイプを主要なステークホルダーと共有し、フィードバックを取り入れて改良する

ステップ５：プロトタイプでユーザーテストをする

• エンドユーザーを代表するユーザーテスト参加者を募集する
• テストユーザーにプロトタイプを操作させ、チームメンバーは彼らの行動を観察し、質問し、インサイトを集める
• フィードバックを分析し、改善点を特定する

ステップ６：デザインの反復

• データに基づいてプロトタイプを調整するために、インサイトを活用する
• 問題によっては、ステップ１に戻って新しい解決策を考えることが求められる
• デザインを改良しながら、忠実度の高いプロトタイプに移行する

ステップ７：技術的な実現可能性

• デザインプロセスを通じてエンジニアと協議する
• 技術的に達成可能で、資源効率に優れたデザインであることを確認する

ステップ８：デザインハンドオフ

• 最終デザインとプロトタイプをエンジニアと共有する
• ユーザーのペインポイントやソリューションの背景にあるアイデアを説明するための文書を含む
• 主要な文書には、スタイルガイド、コンポーネントとパターンの内訳とその状態、情報アーキテクチャ、（アイコン、SVG、メディアなどの）アセット、プロトタイプが含まれる

ステップ９：開発とリリース

• エンジニアは、開発プロセスを導くのにハンドオフ文書を使う
• インタラクティブなプロトタイプで、デベロッパーはインタラクション、アニメーション、トランジションを理解できるようになる
• デベロッパーは、Web、ネイティブアプリストアなど、さまざまなプラットフォームに変更を公開する

ステップ１０：QA（品質保証）テスト

• 最終製品にバグや不具合、矛盾がないかテストする
• ​​デザインチームは UX監査を実施し、最終製品がデザイン仕様を満たし、ユーザビリティの問題がないことを確認する
• チームは、最終製品が意図したとおりの外観と機能を備えていることを確認する

UXPinでインタラクティブなプロトタイプを作る

UXPin を使うと、デザイナーは最終的な製品体験を正確に表現するプロトタイプを作成できます。ベクターグラフィックスを生成する従来のデザインツールとは違って、UXPin は HTML、CSS、Javascript を裏でレンダリングするため、デザイナーはより忠実でインタラクティブなプロトタイプを作成できます。

また、UXPin には独自技術である『UXPin Merge』があり、完全な機能を持つReactコンポーネントでデザインすることができます。

画像ベースのデザインツールとコードベースのデザインツール

画像ベースのデザインツールは、コードコンポーネントがどのように見えるかを画像や視覚的に表現します。このようなモックアップは美的感覚に優れていますが、忠実度が低いため、デザイナーは複雑なインタラクティビティはともかく、基本的なユーザーインタラクションはほとんどテストすることができません。- 複雑なインタラクティビティは気にしないようにしましょう。

UXPin のようなコードベースのデザインツールは、フォーム要素のようなコンポーネントがインタラクティブであるため、より忠実で機能的です。

UXPinのフォームからテキスト入力をキャンバスにドラッグすると、ユーザーがデータを入力できる状態になります。それでデザイナーは、変数（バリアブル）を使ってその情報を取得し、プロトタイプの他の場所でそれを使うことで、画像ベースのツールではできないダイナミックなユーザー体験が生み出されます。

条件付きインタラクション と Expression

UXPin の条件付きインタラクション とExpressionを使って、プロトタイプをさらに進化させましょう。条件付きインタラクションでは、ユーザーやシステムのアクションに対して、「if-then」や「if-else」の条件を作成できます。

一方、Expressionでは、フォームバリデーション、計算コンポーネント、その他のJavascript のような機能によって、プロトタイプより複雑にします。

UXPin Mergeでより良い結果を

最終製品と見分けがつかないほどダイナミックで没入感のあるプロトタイプを作成してみませんか？

高度なプロトタイプを使用することで、テスト範囲を広げ、開発前にデザインを反復して正確なデータとインサイトを得ることができます。

デベロッパーと共有できる再利用可能なコンポーネントでプロトタイプをデザインするためのテクノロジーであるUXPin Mergeをぜひご利用ください。 

The post プロトタイプと 最終製品 – 比較ポイント５つ appeared first on Studio by UXPin.

Figmaのデザインツールでは、基本要素としてコンポーネントを使用し、コピー＆ペーストでデザインできます。

コンポーネントの使用によって、デザイン制作をスピードアップし、一貫性を促進と、デザイナーの作業をより効率化につながります。

本記事では、FigmaとUXPin（Merge含む）では、コンポーネントでどのような点で違うのかを見ていきましょう。

デザインから開発へのハンドオフを最適化して、入力フィールド、クリック可能なメニュー、並べ替え（整列）可能なデータテーブルなど、インタラクティブなコンポーネントが溢れるプロトタイプを作成してみませんか？

UXPin Mergeでデザインをシンプルにしましょう。詳細についてはこちら。

Figma のコンポーネントとは？

Figmaのドキュメントには、「“Components are elements you can reuse across your designs. They help to create and manage consistent designs across projects.” （コンポーネントは複数のデザイン間で再利用可能な要素であり、複数のプロジェクト間で一貫性のあるデザインを作成して管理する時に便利です。）」 と書かれています。

デザイナーはFigmaで、図形、アイコン、画像、テキストなどのコンポーネントを使ってコンポーネントを作成します。そしてそれらのコンポーネントは、エンジニアが最終製品の開発で使用するコード化されたコンポーネントを、ベクターベースで視覚的に表現したものです。

ベクターベースのデザイン要素を理解する

Figmaのベクターベースは外観的には完璧ですが、その静的な性質から、機能的なUI要素やデザインパターンというより、あくまでグラフィカルな表現です。

そのため、画像ベースやベクターベースのデザインツールのほとんどは、機能を表現する上で限界があります。デザイナーは見た目を美しくすることはできますが、体験を正確に再現することはできないからです。そしてプラットフォームは、ライブデータを使用できないベクターグラフィックスをレンダリングします。

結果ではなくワークフローを改善

FigmaのConfig 2023でのリリースにより、デザイナーは一部インタラクティブなプロトタイプやコンポーネントをより簡単に作成できるようになりましたが、ユーザーテストの面ではほとんど変わっていません。Figmaのコンポーネントのレンダリングは変わりませんが、ワークフローがシンプルになりました。

そしてデザイナーは、インタラクティブ性を作るために複数のフレームを使う代わりに、ステートの変更のようなインタラクションをコンポーネントに直接適用することができます。

これはデザイナーのワークフローをシンプルにするための大きな前進ですが、ツールのベクターベースの制限は変わらぬ同じです。

UXPinのコンポーネントとは？違いについて

UXPinのコンポーネントの原理はFigmaと同じですが、UXPinは、静的な画像を扱う代わりに HTML、CSS、Javascriptを裏でレンダリングするため、デザイナーはより忠実性や機能性を活用できるようになります。

UXPinのコンポーネントを組み合わせることで、デザインチームは完全にインタラクティブなプロトタイプを作成できるのです。

例えば、デザイナーはあらゆる入力フィールドを設定して、コードのような機能を模倣することができます。

テキストコンポーネントを使うことで、登録時に［ユーザー名］と［パスワード］を取得し、サインイン時に同じ認証情報を使用するようユーザーに求めることができ、サインアップフローを正確に再現することができます。

インタラクティブプロトタイプを理解する

インタラクティブプロトタイプは、クリック/タップ、スワイプ、スクロール、入力などのユーザーエンゲージメントに反応することで、最終製品が忠実に模倣されており、デザイナーはプロトタイプを用いてステークホルダーやテスト参加者に実際のユーザー体験を提供できるため、開発フローのテストの質が強化されます。

完全にインタラクティブなプロトタイプを作成するには、以下の２つの方法があります：

• コードの使用 – エンジニアリングの入力が必要
• コードベースのデザインツールの使用 – エンジニアリングの入力は不要

このコードベースのアプローチにより、デザイナーはドロップダウンメニュー、アコーディオン、画像カルーセルなどの複雑なUIパターンのようなコンポーネントを作成することができます。

デザインと開発の融合

UXPin独自の Mergeの技術によって、デザイナーがデザインプロセスにおいてインタラクティブなコンポーネントを使用することができるように、組織はデザインシステムをレポジトリから UXPinに同期できます。Mergeのおかげで、デザイナーは一行も書くことも見ることもなく、コードのあらゆる力を得られるのです。

セットアップにはエンジニアリングの入力と技術的な専門知識が必要ですが、この初期プロセスが完了すると、Mergeでは自動的に UXPin に更新が同期され、デザインチームに新しいリリースが通知されます。

そして Mergeを使って、グラフ、データ テーブル、日付ピッカー、ビデオ/オーディオ プレーヤー、ダッシュボードなど、あらゆる種類のコンポーネント、パターン、またはページのテンプレートをインポートできます。

UXPin MergeとFigma Dev Mode

FigmaのDev Modeでは、エンジニアが、CSSやフロントエンドのコードなど、技術的な観点から要素を検証することができます。Figmaは、「design to code」のワークフローで、この基本的なコードを自動的に生成します。しかし、このコードは便利ではありますが、製品としてすぐに使用できるものではなく、ほとんどの場合、すべての製品の構文やプログラミング手法に合わせることができないため、冗長になってしまいます。

一方 UXPin Mergeでは、「Code-to-Design」のワークフローでは逆の働きをします：UXPin Mergeは、デザインツールからコードを生成するのではなく、リポジトリからビジュアルコンポーネントを取得します。

デザイナーがUXPinで使用するMergeコンポーネントは、開発者がフロントエンド開発で使用するものとまったく同じであり、インタラクティブ性を含むコンポーネントのプロパティはUXPinに同期されるため、デザイナーはこれらの設定や調整を行う必要がありません。

この Mergeワークフローは、デザイナーとエンジニアが同じ制約の中で同じUIライブラリを使って作業することで、デザインドリフトはなくなり、技術的負債は軽減します。これによって、組織内に「信頼できる唯一の情報源（Single source of truth）」ができます。

UXPin MergeとFigma – コンポーネントの比較

FigmaとMergeの違いを説明するために、ここでは２つの同じマテリアルデザインのボタンのコンポーネントを使います。Figmaでマテリアルデザイン2のUIキットを使い、Mergeを使ってMUIのReact コンポーネントをUXPinにインポートします。

MUIはReactのコンポーネントライブラリの基盤としてマテリアルデザインを採用しています。

そして、何も変更を加えずに、各 UIライブラリからコンポーネントをキャンバスにドラッグしました。

Figma:

UXPin:

UXPinコンポーネントはデフォルトでインタラクティブであり、ホバーとクリックのインタラクションはレポジトリで定義されています。Mergeコンポーネントはグラフィカルな表現ではなくコードコンポーネントなので、完全にインタラクティブです。

Figmaコンポーネントは、基本的に画像であるため、デフォルトではインタラクティブではありません。

なのでデザイナーは、プロトタイプを作成する前に、デザインツールでインタラクションを設定する必要があり、エンジニアが何を作るべきかを理解できるように、デザインハンドオフの際には多くの補足ドキュメントとコンポーネントのバリエーションを共有する必要があります。

Specモードと開発モード

Mergeの 「Specモード」 は、Figmaの「開発モード」とも大きく異なります。開発モードを使うと、デザイナーは提案されたCSSやその他のコードを使って要素を検証できますが、それは本番環境に対応していないこと確認されていません。

また、デザイナーは、Figmaコンポーネントのバリアント、インタラクション、アニメーション、トリガーなどもそれぞれ共有しなければいけません。

UXPinでは、プロトタイプのデフォルトまたは初期状態のMergeコンポーネントのJSXプロパティ（余白、タイポグラフィ、サイズなど）のみが表示されます。

そしてデベロッパーにはすでに同じUIライブラリがあり、同じレポジトリからプロジェクトにインポートして開発を開始します。

UXPinからJSXコードをコピー/ペーストして、IDE（統合開発環境）で関連するコンポーネントに適用するだけです。

デザインシステムチームが各コンポーネントのインタラクションやトリガーなどのプロパティを既にレポジトリで確定しているので、デベロッパーはドキュメントの追加は必要ありません。

このような組み込まれた制約は、デベロッパーがコンポーネントのインタラクティブ性を変更できないということですが、Figmaではコンポーネントインスタンスをマスターコンポーネントから切り離し、そのプロパティを変更できます。

FigmaとUXPinのプロトタイプ

デザイン環境、ツール、ワークフローはFigmaとUXPinで大体似ていますが、次のような違いもあります。

フレームとページ

最大の違いの１つとして、Figma がフレームとアートボードでのワークフローを採用しているのに対し、UXPinでは画面ごとに独立したキャンバスがあるページを採用している点です。

デザイナーは、UXPinのOverview 機能を使うと、Figmaと同じように１つの画面でページを視覚化できます。

インタラクティブ機能の追加

Figmaのプロトタイプ機能により、デザイナーは、限られたユーザーアクションで基本的なインタラクティブ性を追加することができます。

Config 2023のリリースでは、バリアブルを使ってコンポーネントの状態を簡単に変更できるようになりましたが、正確性が重要な検証業務においてコードで提供できるほどのものにはまだ程遠いです。

一方、UXPinのインタラクションには、デスクトップおよびモバイルプロトタイプのためのユーザートリガーとアクションが数多く含まれています。

Mergeコンポーネントはデフォルトでインタラクティブなため、デザイナーは主にページ遷移やポップアップのようなナビゲーションのインタラクションに集中できるので、デザインと反復をより速やかに行うことができます。

テスト範囲

Figmaには忠実さと機能性がないため、デザイナーは、このプラットフォームを使ってテストできることが限られています。

デザインチームは、プロトタイプの範囲を広げるために、プラグインや統合、複数のツールを使うことがよくありますが、それだとコストや時間などのリソースが増えてしまいます。

UXPin Mergeではデザイナーはプラグインや統合なしで最終製品と見分けがつかない完全にインタラクティブなプロトタイプを作成できます。

さらに、APIを使って外部サービスに接続し、テスト範囲を大幅に拡大することもできます。

このような高度なプロトタイプにより、デザイナーはテスト中に有意義なインサイトを集め、より良い製品成果のための正確なデザイン上の意思決定を行うことができるのです。

「Code-to-Design（コードからデザイン）」のワークフローの利点と使いやすさを体験してみませんか。

詳細およびこの革命的なテクノロジーへのアクセスリクエスト方法については、Mergeのページをぜひご覧ください。

The post Figma とUXPin – コンポーネント の比較 appeared first on Studio by UXPin.

機能的プロトタイプとは、製品の中核となる機能を持つ作業モデルのことです。デザイナーは UXPin Mergeを通して、自分のデザインをデベロッパーにシームレスに伝えることができます。  

主なポイント：

• 機能的プロトタイプは、製品の実際の形であり、その主な機能を示すものである。
• UXPin Mergeは、インタラクティブなReactコンポーネントをデザインエディタに統合する。デザイナーとデベロッパーの円滑な連携、プロトタイプのテスト、デザインから開発への移行が簡単にできる。
• 機能的プロトタイプは、ユーザーの行動のインサイト、デザインの検証、改善の促進をもたらす。
• 機能的プロトタイプを作るには、インタラクションのデザイン、テストの実施、学習プロセスの取り込みが必要。
• UXPin Mergeを活用することで、デザイナーはデベロッパーから共有されたインタラクティブな Reactコンポーネントを通じて、プロトタイプの作成と開発のギャップを埋めることができる。

 UXPin MergeではデザインエディタにReactコンポーネントを統合し、デザイナーは統合したコンポーネントを使ってプロトタイプを作成できるようになります。

デベロッパーもまた、デザイナーが使うものと同じReactコンポーネントを使用するため、作成したプロトタイプを使ってユーザーテストを実施すれば、開発準備はスムーズに完了します。詳細についてはぜひこちらからご覧ください。

機能的プロトタイプとは

  機能的プロトタイプは、製品デザインがどのように機能するかを動的に表現したものです。このプロトタイプを使用することで、製品を操作してその特性や欠点がわかり、より良いユーザー体験のためにデザインを改良することができます。  

イメージベースのプロトタイプは、製品の外観やレイアウトのシミュレーションをすることはできても、実際の動作を描写するには不十分なことがよくあります。

一方、機能的プロトタイプは、インタラクティブ性という貴重な要素を導入しており、各クリック、スワイプ、スクロールは単なる定義されたアニメーションではなく、ユーザージャーニーを垣間見ることができ、それによって製品の使いやすさや効率性についてのインサイトがもたらされます。  

機能的プロトタイプ と 非機能的プロトタイプ

  機能的なプロトタイプと非機能的なプロトタイプの主な違いは、提供されるインタラクティブ性の深さです。

機能的なプロトタイプは外観を超えて製品の動作を体験できますが、非機能的なプロトタイプはプロトタイプを操作することなく視覚的なプレビューを提供します。  

機能的プロトタイプ：

機能的プロトタイプは、製品デザインの実際の機能を模倣できるという強みがあります。 また、見た目だけではなく、アクション、インタラクション、UX（ユーザーエクスペリエンス）も含めてその動きも見ることができます。そして機能的プロトタイプを操作するときは、ユーザーが製品内で行うことを厳密に反映したシュミレーションで行います。ボタンのクリックなどの機能やユーザーフローは完全に実際の製品の再現となります。  

機能的プロトタイプの例：

 例えば、フィットネスアプリをモバイル向けにデザインすることを想像してみてください。機能的プロトタイプでは、ユーザーはインターフェースを操作し、ボタンをタップして運動の追跡シミュレーションを行います。実際の運動を記録しているかのようにアプリのリアルタイムフィードバックも受けることもできます。このプロトタイプではデザインだけでなく、アプリの使いやすさも表すことができます。  

非機能的プロトタイプ：

  非機能的プロトタイプは、主に製品の視覚的な側面を表します。プロトタイプ自体は、デザインシステムのコンポーネントやレイアウトなど、最終製品のように見えるかもしれませんが、ユーザーとのインタラクションを定義するダイナミックな相互作用はありません。非機能的プロトタイプは静的なスナップショットのようなものであり、製品が実際にどのように機能するかではなく、どのように見えるかの単なるプレビューです。  

非機能的プロトタイプの例：

  先ほどの例で取り上げたフィットネスアプリでの話と照らし合わせると、非機能的プロトタイプは、画面のレイアウト、ボタンの配置、全体的な美しさなど、アプリの視覚的エッセンスを捉える一方、インタラクションなどの”動き”のシミュレーション機能はありません。ユーザーはボタンをタップしたり、ワークアウトのトラッキングのシミュレーションを行うことはできず、アプリの静的なビジュアル表現を見ることしかできません。  

機能的プロトタイプの利点

  機能的プロトタイプには以下のような利点があります：  

• ユーザーがどのように製品に接するかを理解することで、UXデザインの失敗を回避する。
• ユーザーテストやフィードバックを通じて、UXデザインのコンセプトを検証できる。
• UX デザインを反復的に改良することで、UXや機能性が上がる。
• インタラクティブなプロトタイプをステークホルダーに提示することで、連携が強化される。
• 効率的な反復と革新により、デザインプロセスにおける時間やリソースの節約になる。

機能的プロトタイプを作るには

 このプロセスでは、サインアップフォームの機能的なプロトタイプを作成します。メールとパスワードの入力がされているかどうかを確認し、実際のユーザー体験を再現するためにメールの形式とパスワードの長さを検証します。

以下は、サインアップフォームの機能プロトタイプの例です（UXPinを使用）：

１．キャンバスを設定する

  ダッシュボードから空白のドキュメントを選択すると、アートボードが開き、そこからサインアップフォームを作成することができます。

サインアップフォームが動作するプラットフォームの画面サイズを以下のように特定します：  

• CANVAS SIZE （キャンバスサイズ）までスクロールする
• キャンバスのサイズを選択する

２．UXPinライブラリを使ってレイアウトをデザインする

空白ドキュメントを開くと、中央にキャンバスが表示されます：

• Design System Libraries（デザインシステムライブラリ）に移動
• UXPin Libraries（UXPinライブラリ）を選択

• コンポーネントをキャンバスに追加するライブラリを選択します。自分でコンポーネントライブラリを作成し、その要素をキャンバスにドラッグ＆ドロップすることもできます。

メールやパスワードの入力、ラベルやボタンなどの要素を追加して、サインアップフォームのレイアウトをデザインします。

３．メールとパスワードの入力をインタラクティブな要素にする

• メール入力フィールドを選択する
• Interaction（インタラクション）へ行く

• Trigger（トリガー）へ行く
• トリガーを「Focus（フォーカス）」に設定する

• アクションまでスクロールし、Set State（ステートを設定する）を選択
• Element（要素）に移動し、Email input（メール入力）を選択する。

次に、ステートを設定し、インタラクションを追加します：  

• Set State（ステートの設定）で Base（ベース） を選択
• 「Add（追加）」をクリック

パスワード入力フィールドについても、このプロトタイプのプロセスを繰り返します。  

３．検証ロジックの追加

  メールとパスワードのフィールドが入力されているかどうかをチェックするロジックを設定します。そして、入力されていない場合はエラーメッセージが表示されます。新しいインタラクションを追加します：  

• メール入力を選択する
• インタラクションへ行く
• 「New Interaction（新しいインタラクション）」に進む

次に、メール入力フィールドが空かどうかを検出する条件を設定します：  

• トリガーを「Focus Lost（フォーカスの喪失）」に変更する。
• 「Conditions（条件）」に移動し、最初のフィールドで「Content of element（要素の内容）」を選択する。
• Email input （メールの入力）を選択する（自動的に選択されるはずである）
• 条件が空であることを選択する。
• Add condition （条件の追加）をクリックして終了する。

次に、新しいインタラクションを確認します：  

• 「Action（アクション）」で「Set state（ステートの設定）」を選択する
• Element（要素） を「Email input（メールの入力）」に変更する
• Set state（ステートの設定）を「Empty（空）」にする
• 「Add（追加）」に行く

パスワード入力フィールドについても、このプロトタイプのプロセスを繰り返します。  

４．メールフォーマットの検証を設定する

  次に、メール入力が有効なメールフォーマットに従っていることを確認する条件を追加します。上記の手順に従って、メール入力フィールドに新しいインタラクションを作成します。  

• トリガーを「Focus Lost（フォーカスの喪失）」に設定する
• Content of element （要素の内容）を「email input（メールの入力）」として選択する
• 条件を正規表現にマッチするように設定する
• 「Email（メール）」を選択
• 「 Add condition（条件の追加）」をクリック

次に、新しいインタラクションを確認します：  

• Action で「Set state（ステートの設定）」を選択する。
• Element（要素） を「Email input（メールの入力）」に変更する
• ステートの設定を「Incorrect （誤）」にする
• 「Add（追加）」に行く

５．パスワードの長さ検証の設定

  入力されたパスワードの長さが必要な基準を満たしているかどうかを検証するロジックを追加します。  

上記の手順に従って、パスワード入力フィールドに新しいインタラクションを作成します。  

• トリガーを「Focus Lost（フォーカスの喪失）」に設定する。
• Content of element （要素の内容）を「password input（パスワード入力）」として選択する
• 条件を「doesn’t match regex（正規表現に一致しない）」に設定する。
• 「Custom（カスタム）」を選択し、パスワード入力の条件を入力する
• 「Add condition（条件の追加）」をクリックする

次に、新しいインタラクションを確認します：  

• Action（アクション） で「Set state（ステートの設定）」を選択する
• Element（要素）を「Password input（パスワード入力）」に変更する
• Set state（ステートの設定） を「Incorrect（誤）」にする
• 「Add（追加）」に行く

７．プロトタイプのテスト

  プロトタイプと対話し、フローを体験し、検証をテストし、最終製品の動作を正確に表現していることを確認します。

上記のような手順に従って、メールとパスワードの入力の検証を示すサインアップフォームの機能的プロトタイプを、UXPinを使って作成しましょう。  

UXPin Merge で機能的プロトタイプをデザインしよう

 ここまでお話しした通り、機能的プロトタイプ はデザインと開発間の重要な存在と言えるでしょう。UXPin Mergeは、動的なReactコンポーネントを統合させることで、デザインと開発の移行を効率化します。  

このリアルタイムでのコラボレーションによって、デザイナーはインタラクティブなモデルをテストし、デザインから制作までのプロセスをスピードアップすることができるのです。詳細は UXPin Merge のページをぜひご覧ください。

The post 機能的プロトタイプ – プロダクトデザイナー向けの簡単ガイド appeared first on Studio by UXPin.

この記事は、UXTweak のコンテンツデザイナー責任者であるDaria Krasovskaya様によるゲスト投稿です。ぜひ最後までお楽しみください！

プロトタイプが完成し、デザインを検証する方法をお探しですか？この記事では、プロトタイプテストを実施する際のベストプラクティスと知っておくべき情報をまとめました。

プロトタイプテストは、デザインを検証し、ビジネスの目標を達成しながらユーザーのニーズを満たすことを確認するための優れた方法です。UXチームがデータに基づいた意思決定を行い、ユーザー中心の製品を作成する上で大いに役立つ、極意とも言えるユーザーリサーチ手法です。

プロトタイプとは

プロトタイプは、デザインコンセプトとプロセス検証のために構築される製品を具体的に表すものであり、製品が本格的な生産に入る前に改良を加えることができます。

そして、製品固有のニーズと製品ライフサイクルの段階に基づいて、以下のようにさまざまなタイプのプロトタイプを開発することができます：

• 高忠実度プロトタイプ： 最終製品を模した詳細なモデル。製品の使いやすさを改良するために製品開発プロセス後半で使用される。
• 低忠実度プロトタイプ： 製品ライフサイクルの初期段階で、製品を構築するデザインコンセプトのテストや検証に使用するシンプルなモデル。
• ワイヤーフレームまたはペーパープロトタイプ： 製品の構造とレイアウトの概要を示す非常に基本的な表現方法。ワイヤーフレームまたは手描きのペーパープロトタイプのいずれかの形式を取ることができる。

プロトタイプテストとは

プロトタイプテストは、UXの手法の1つで、製品が本格的な生産に移る前に、プロトタイプを評価してデザインを検証したり、改善点を特定したりするものです。

プロトタイプテストは重要なフェーズで行われ、UX専門家は、製品がユーザーのニーズや期待に合致していることを確認することができます。

また、プロトタイプの種類によって、テストは一般的なUX（ユーザーエクスペリエンス）、機能性、ユーザビリティだけでなく、問題の製品の全体的な美しさを評価することができます。

製品のプロトタイプテストが重要な理由

プロトタイプテストは、対象ユーザーの視点で製品を見ることができる見逃せない機会であり、製品開発にとって多くの利点があります。これによって、デザインプロセス全体と最終製品の開発に付加価値を与えます。

以下で、プロトタイプテストを実施する主なメリットを見てみましょう：

反復的な改善

プロトタイプテストは、UXデザインにおける継続的改善の思考の典型です。UX専門家はプロトタイプテストで製品の使いやすさ、機能性、美しさに関して、潜在的な改善点を特定することができることにより、製品の改善をサポートします。 UXは反復的なプロセスですが、プロトタイプテストも同様なのです。

時間とコストの節約

プロトタイプを作成し、UXプロセスの早い段階でテストするのは、費用、時間、リソースの節約になる優れた方法です。

プロトタイプのテストにより、製品が生産に入る前にコストおよび時間を効率化し、専門家によるコストのかかる再デザインや手直しを回避することができます。

ステークホルダーとのやりとり

先述したように、プロトタイプは製品の具体的な表現なので、チームが同じ認識かを確認するための優れたツールとして機能します。

さらに、プロトタイプテストは、社内のステークホルダーからのフィードバックを集めるだけでなく、製品がユーザーのニーズを満たしながら、ビジネスの戦略的目標に貢献していることを確認する見逃せない機会でもあります。

リスク軽減

プロトタイプテストのもう 1 つの重要な利点として、リスク軽減のメカニズムとして機能する点があります。 プロトタイプテストにより、UX専門家は開発プロセスの早期段階でリスクと課題の特定して対処できるため、対象ユーザーに製品が採用される可能性が高まります。

そしてプロトタイプテストといえば、モバイル用のテストも忘れずに。Unswitchの２０２３年の調査によると、世界の携帯電話市場の統計において世界のスマートフォンユーザーは４６億人いるとのこと。

プロトタイプテストを行うタイミング

プロトタイプテストは、反復的で動的なプロセスであることから一過性のタスクとして行わないようにしましょう。プロトタイプのテストは製品開発を通じて行っていきましょう。プロトタイプテストは、初期段階の場合特に、コンセプトを検証するための素晴らしい方法となります。

アイデアの検証後はプロトタイプテストで基本的な機能性を確認し、製品が対象ユーザーのメンタルモデルに反していないことを確認することができます。

発売直前や発売後といった後期段階では、プロトタイプのテストを行うことで、全体的なユーザーエクスペリエンスを検証し、変化するユーザーニーズに対応するための改善点を的確に特定できます。

プロトタイプテスト用製品の種類

プロトタイプテストは汎用性の高いツールであるため、ソフトウェアアプリケーションやプラットフォームなど、多くの製品に適用することができます。ある種の UI を伴うデジタル製品であれば、プロトタイプを使ってテストすることができますが、家電製品や医療機器などの物理的な製品も、プロトタイプのユーザーテストから恩恵を受けることができるというのは注目に値します。

プロトタイプの種類

プロトタイプテストにはさまざまな種類があり、それぞれ「製品の評価」という点で異なる目的があります。最もよく知られているカテゴリーで「量的テスト」と「質的テスト」があります。さらに、ファシリテーターの有無によって、「モデレート型」と「非モデレート型」に分類できます。

このようなカテゴリが持つ独自の性質をより理解できるように、それぞれの主な特徴と違いを概説した表を以下のように作成しました：

「量的テスト」と「質的テスト」

「モデレート型テスト」と「非モデレート型テスト」

プロトタイプテストの実施方法

プロトタイプテストの初心者であれば、このガイドで、効果的なソフトウェアプロトタイプテストの実施、さらに、よりユーザー中心の製品向けのデータに基づいた意思決定を行うことができるようになります。

１．プロトタイプテストを計画する

まずは、テストの目的を明確に設定することから始めましょう。たとえば、「使いやすさ」や「ユーザー満足度」に焦点を当てたいと思うかもしれません。目標がすべて決まれば、プロジェクトのニーズに最も適したプロトタイプテストのタイプを選択します。そしてリサーチの目標に沿ったテストのシナリオを作ることから始めましょう。ユーザーペルソナを使って対象者を確定し、ユーザビリティテスト参加者を募集しましょう。

２．プロトタイプテストのツールを選択する

適切なプロトタイプテストツールの選択は、プロトタイプテストの取り組みを左右します。プロトタイピングツールとの統合のしやすさだけでなく、テスト固有の要件に基づいて適切なツールを選択しましょう。

３．テストを実行する

プロトタイプのセッションを実施し、質的データと量的データの両方を取るようにしましょう。一挙手一投足まで見逃さないよう、メモを徹底的に取ってレポートを作成することも忘れずに！

４．結果を分析する

次は結果の分析です。パターンを特定し、質的データと量的データの両方を考慮した上で、結論を導き出しましょう。そして特定した問題の重大性や影響度に基づいて優先順位をつけます。

５．反復と繰り返し

今度は、調査結果をデザインチームへの実行可能な提案に変換します。 プロトタイプに変更を実装し、行われた改善のプラスの効果を検証するために追加のテストを必ず加えてください。そしてその最終製品に満足するまで、改良とテストを行い続けましょう。

おすすめプロトタイプテストツール

現在市場に出回っているプロトタイプテストツールの中から、おすすめを以下に挙げましょう：

１．UXtweak

UXtweakのような主要なプロトタイピングツールとのシームレスな統合によって、プロトタイプのテストがしやすくなります。また、使いやすいインターフェースによって、あらゆるレベルの人にとって利用しやすく、専任のサポートチームによる専門的なガイダンスを受けることもできます。UXtweakのプラットフォームは、プロトタイプテストのリサーチが大幅に効率化されるリクルート用のユーザーパネルを備えている点も魅力です。

２．Lookback

Lookback もまた、プロトタイプテストを実現する強固なツールです。UXリサーチャーやデザイナーがリアルタイムでテスト参加者と対話できるライブリモートテストツールを提供します。このコラボレーション機能によりチームメンバー間の連携を促進します。

３．Userlytics

Userlyticsは、リモートプロトタイプテストツールを特徴とする包括的なUX分析ツールです。また、プロトタイプテストの参加者が、メモや音声、ビデオなど様々な形でフィードバックを収集できる、きれいに作られたマルチメディアフィードバックツールも魅力です。

４．Optimizely

Optimizely もまた、プロトタイプテストを実現する優れた実験プラットフォームです。このプラットフォームは A/B テストやリモートセッション録画のようなツールが提供され、プロトタイプのテスト作業を強化できるデータ駆動型のインサイトとパーソナライズ機能があります。

ヒント：FullStory統合を使って、UXPinのプロトタイプをテストすることもできます。 

プロトタイプテストの募集方法

プロトタイプテストの参加者を募集するのは、すべてのプロトタイプテスト調査において不可欠なステップです。インサイトの妥当性は、募集採用の質やターゲットを代表とする多くの参加者に影響を与えますからね。テストを達成するには、参加者の募集を行う前に、ターゲットの具体的な特徴を定義し、ユーザーペルソナを参照するようにしましょう。

もう１つの大きなヒントは、特定のスクリーニングクエスチョンを使って、ターゲットとしている層をその参加者が代表していることを確認することです。これが完了したら、参加者を１つのチャネルからのみ集めようとしないでください。

その代わりに、SNS や関連するオンラインコミュニティなど、いくつかのリクルートチャネルを利用して、リサーチに豊かなインサイトがもたらされるような多様な参加者を集めましょう。

参加者の募集を慎重に行うことで、よりユーザー中心の製品に貢献する質の高い、実用的な結果がもたらされることをお忘れなく。

プロトタイプテストのベストプラクティス

もしプロトタイプテストに足を踏み入れようとしているなら、以下のルールを覚えておきましょう。

量的データと質的データを組み合わせる

質的方法論と量的方法論の両方をプロトタイプテストのリサーチに統合すると、大きな効果が得られます。 数値統計でユーザーの行動を定量化することができ、質的なインサイトはユーザーの行動の背後にある「理由」を明らかにすることができます。

それによって、ユーザーの内発的動機とニーズをより包括的に理解できるようになり、よりユーザー中心のデザインプロセスが実現します。

現実的なシナリオを含める

プロトタイプテストを実施するとき、複数のシナリオとエッジケースを含むなどのセッションを一気に詰め込んでしまいがちです。 テスト参加者向けに現実的なタスクを作成して、順調に進めていきましょう。 実際のタスクを使うことで、参加者がリアルにプロトタイプに取り組むことができ、インサイトがより実用的なものになります。

テスト参加者の多様化

これは本当に大事です！ 前述したように、参加者の募集はあらゆるプロトタイプテスト調査のすべてと言えるでしょう。 テスト参加者の多様性を常に目指すことで、ニーズや期待についてより幅広いインサイトが得られ、対象とするユーザーについてより包括的な理解につながります。

テスト全体で一貫性を確保する

最後に重要なことですが、さまざまなプロトタイプのテスト セッション間で常に一貫性を確保してください。

一貫性により、プロトタイプテストのセッションから得られるインサイトが信頼できるものであり、一番重要なこととして、比較可能であることが保証されます。

プロトタイプテストをするときに避けるべきよくある間違い

プロトタイプテストをするときに避けるべきよくある落とし穴を以下で見てみましょう：

アクセシビリティに関する考慮事項を無視する

誘惑に駆られるかもしれませんが、プロトタイプテストのセッションではアクセシビリティを必ず考慮してください。 そうしなければ、基本的なユーザーのニーズが無視されたデザインになる可能性があります。

モバイルテストをしない

モバイル ユーザーは増加しているため、モバイルのプロトタイプテストもお忘れなく。常にモバイルエクスペリエンスをテストし、デスクトップのパフォーマンスがモバイルデバイスでの最適なUXメトリクスになるとは決して考えないでください。

インサイトの文書化でしくじる

インサイトの文書化でしくじるのは、プロトタイプテストにおける大きな落とし穴の 1 つです。 貴重なインサイトを失くしたり、結論を急ぐことを避けるために、各プロトタイプテストのセッションを徹底的に文書化し、質の高いメモをとることを怠らないようにしましょう。

まとめ

プロトタイプテストは、ユーザーとビジネスの両方のニーズに合わせてデザインを調整する上で、非常に重要な役割を果たします。 このテストによってUXチームはよりユーザー中心の製品を大いに構築できるようになるため、UXデザインプロセスに統合する価値のあるユーザーリサーチの手法の頂点の 1 つに挙げられます。

プロトタイプテストを最大限に活用するには、プロトタイプテストに対して反復的なアプローチを採用し、決して一過性のタスクとして扱わないようにしましょう。

UXPinを使ってインタラクティブなプロトタイプを構築してみましょう！UXPinは、アイデア出しからデザインハンドオフまで、デザインプロセス全体をカバーするオールインワンのデザインツールです。こちらからUXPinをぜひ無料でお試しください。

The post これを読めばすべてわかる プロトタイプテスト 【徹底ガイド】 appeared first on Studio by UXPin.

デザインシステムのガバナンスを「急成長、創造性、柔軟性を阻むもの」だと考える人もいますが、デザインとユーザビリティの一貫性を維持しながら適切に実施することができれば、デザインシステムのガバナンスはスケーラビリティと創造性を促進できるのです。

いいデザインシステムのガバナンスは、成長や利益よりもユーザーを優先させることです。また、企業文化においてもチームメンバーが従い、受け入れるガバナンスのプロセスをどのように導入するかに重要な役割を果たします。

UXチームとエンジニアリングチームのツールは、デザインシステムのガバナンスにも影響を及ぼします。UXチームは、最終製品の変更に合わせてデザインツールの更新が必要にあり、プロセスが人的エラーにさらされることになるのです。

UXPin Merge を使えば、チームは２つの別々のデザインシステムのアップデートを心配する必要がありません。UXPin Mergeは、GitレポジトリやStorybook 統合（React、Revue、Angular、Emberなどとの接続が可能）のコードコンポーネントとエディタツールを同期し、別々のデザインシステムの必要性をなくし、ヒューマンエラーを軽減しますからね。

UXPinがデザインシステムのガバナンスを強化する方法をぜひコチラからご覧ください。

デザインシステムのガバナンスとは

デザインシステムのガバナンスとは、製品のデザインシステムを維持・更新するためのプロセスやプロトコルのことです。

例えば、アプリの終了アイコンを「X」から「ー」に変えるような小さな変更であっても、何段階もの承認と実施プロセスを経ないといけません。

デザインシステムのガバナンスは、以下のような目的を果たします：

• デザインとブランドの一貫性の維持
• ユーザビリティの問題につながる誤ったデザインの決定の防止
• チームメンバーへの、創造的な思考や、変更を試みる前の手持ちのツールでの問題解決の促進
• アクセシビリティを考慮した確実なアップデート
• 組織全体への変更点の周知
• デジタル製品およびデザインドキュメントの更新

効果的なデザインシステムのガバナンスがなければ、新しいコンポーネントの編集やアップデートは、ユーザビリティの問題や矛盾を生み出して製品の評判を落とすような「無法地帯」のようになる可能性があります。

デザインシステムの維持の課題

デザインシステムの維持には多くの課題があり、どの組織でも、デザインシステムの管理者またはチームがないといけません。。

ここでは、デザインシステム維持のための一般的な課題７つと、効果的なガバナンスモデルが不可欠である理由を見ていきます。

１．社内政治

残念ながら、うまくいっているデザインシステムであっても組織内の権力闘争から逃れられるわけではありません。経営者の力を使って、デザインシステムチームの最初の決定を覆してデザインの変更の推進や阻止に働くチームメンバーがいることだってあり得ますし。

その点ガバナンスは、経営陣やその他のステークホルダーにデザインの変更とその理由を十分に伝え、賛同と承認を得やすくしてくれます。

２．複数のチームや部署からのインプットの管理

デザインシステムは、UXやエンジニアリングチームだけのものではなく、企業のデザインシステムは、製品チームやその他のステークホルダーが共有しています。

このようなインプットをすべて管理するのは、適切なガバナンスシステムがなければ大変です。

３．デザインシステムは、よく後付けやサイドプロジェクトになる。

多くの企業、特に設立間もないスタートアップ企業では、製品のデザインシステムは優先事項ではなく、UXデザイナーが暇な時や週末に行うサイドプロジェクトで、成長需要との整合性を保つために細々とやっています。

このような環境では、デザインシステムは乱用されやすく、誤ったデザイン決定が行われがちです。ガバナンスが不十分なため、UX チームがユーザビリティの問題を修正するのに変更を元に戻さなければならないといったこともよくあります。

４．お粗末なコミュニケーション

部署間、チーム間、個人間の適切なコミュニケーションがなければ、例えば２つのチームが同じ作業を別々に行うことになったり、「他の人がやっている」と思い込んで肝心のユーザビリティの変更が忘れられたりなど、デザインシステムはバラバラになってしまいます。

そこでデザインシステムのガバナンスによって、組織全体のコミュニケーションが促され、誰もが最新の情報を得ることができるのです。

５．チームメンバーの消極的な姿勢

製品のデザインシステムに難色を示すチームは、気に入った部分だけ選んで、あとは「より良いデザイン方法」を開発します。新しいメンバーや、デザインシステムの構築に携わっていない人が、「自分の方がうまくやれる」と思い込んでしまい、他の人の努力を台無しにしてしまうのです。

このような消極的な姿勢は、製品の使い勝手や一貫性に影響を与えるだけでなく、要らぬ対立を生むことにもなりかねません。

そこで抑制と均衡が複数備わっているガバナンスモデルによって、デザインシステムがチームメンバーに乗っ取られるのを防ぎます。

６．変化に対する抵抗

時にはその逆もあります。システムは今のままでいいと考え、いかなる変更も跳ね除けてしまうデザインシステムの管理者もいます。デザインシステムは決して完全なものではなく、組織の成長のために進化しなければならない、進行中の作業なんですけどね。

７．「信頼できる唯一の情報源（Single source of truth）」のジレンマ

多くの企業が、UXデザイン、プロダクト、エンジニアリングを中心としたすべての部門間で単一のデータセットを扱うという、『信頼できる唯一の情報源（Single source of truth）』のジレンマに悩まされています。

UXチームはデザインツールを使い、エンジニアはコードを使い、プロダクトチーム（技術的なノウハウが乏しい場合が多い）はパワーポイント、PDF、紙など、あらゆる種類のツールを使って仕事をします。

このようにワークフローが分散しているため、『信頼できる唯一の情報源』の維持は大変であり、全員が最新の情報を得られるようにするために、追加のスタッフやリソースが必要になることも少なくありません。ガバナンスシステムがよくても、「信頼できる唯一の情報源」のジレンマは常に付いて回る課題なのです。

世界的な決済サービスの大手である PayPal は、『信頼できる唯一の情報源』のジレンマをUXPin Mergeで解決しました。同社は、UXPin Mergeを使って、Gitレポジトリからのコードコンポーネントで内部 UI（ユーザーインターフェース）のデザインシステムを構築し、それを維持しています。

デベロッパーが新しい変更を実施すると、UXPin のデザインエディターのコンポーネントが同時に更新されるため、デザイナーとエンジニアは常に同じデザインシステムで作業することができます。

デザインシステムのガバナンス規準の確立

デザインシステムの変更や更新が必要となる主なシナリオは４つあり、そのシナリオでは、プロトタイプの作成や修正を依頼したりする前に、チームが一連の質問やテストを行う提出プロセスが必要です。

• 新要素の導入：新しい要素を追加するためのワークフローを確立することで、デザインシステムの整合性を確保しながら、各チームメンバーには追加する機会が平等に与えられます。
  
  
• パターンの推進：パターンは、「１回限りのもの」と「新しいベストプラクティス」の２種類に分類され、チームは、この新しいパターンを推進する前に、現在利用可能なものと比較してテストしないといけません。
  
  
• パターンのレビューと適応：どのデザインシステムにも、リリース前にパターンをレビューする、少なくとも２名で構成されたチームが必要です。このレビュープロセスにより、新しい要素が現在のデザインシステムの規準と実践に合致していることが保証されます。
  
  
• デザインシステムのアップデートのリリース：チームは新しいアップデートの準備ができたときにリリースするのではなく、アップデートのリリーススケジュールのきちんと作らなければいけません。厳密なリリーススケジュールを設定することで、品質保証と文書化のプロセスを正しく実行できるようになります。

このサブミットプロセスを管理するには、変更が必要なステップを全てマッピングしたシンプルな決定木の使用が効果的です。

このInayaili de León氏による優れた例では、Canonicalチームが、コンセプトからリリースまでのシンプルな決定木に従って、新しいパターンをデザインシステムに追加する方法を示します。

彼女は、デザインシステムと同様、決定木も製品の進化に合わせて更新・改良していく作業であることを認めています。

ステップバイステップのガバナンスモデル例

デザインシステム・ガバナンスのアプローチには様々な方法がありますが、ここではデザインシステムの第一人者であるブラッド・フロスト氏 にヒントを得た１０個のステップからなるプロセスをご紹介します：

１．使えるものを使う

製品チームは、現在のコンポーネント・ライブラリを使ったソリューションを見つけるためにあらゆる努力を払わなければいけません。これは、デザインシステムが十分に文書化され、誰もがアクセスできるものでなければならないということであり、現在のデザインシステムが新しい要件を満たしていない場合、チームはステップ ２に進むことができます。

２．デザインシステム（DS）チームへの連絡

製品チームはDSチームに連絡し、問題と変更案について話し合います。この場合も、DSチームと製品チームは協力して既存のソリューションを探します。デザインシステムを熟知しているDSチームは、製品チームが見落としていたものを発見することもありますが、それでもソリューションが見つからない場合、チームはステップ３に進みます。

３．その変更が単発のものなのか、デザインシステムの一部なのかの判断

製品チームとDSチームは、その修正が一度限りのもの（スノーフレーク）なのか、デザインシステムの一部なのかを判断します。通常、一度限りの変更は製品チームが担当し、デザインシステムの変更はDSチームが担当しますが、いずれにせよ、チームは変更の優先順位を決め、スケジュールを立てる必要があります。

４．初期プロトタイピング

チームが製品の変更をプロトタイプにしてテストを実施します。

５．初回レビュープロセス

DSチームとプロダクトチームは、プロトタイプとテストの結果を確認します。両チームとも異論がない場合は次のステップに進み、変更点が不足していると判断した場合はプロトタイプとテストに戻ります。

６．UX および開発テスト

デザインが最初のレビューに合格すると、UXチームと開発チームに送られ、変更が UX（ユーザーエクスペリエンス）と技術要件を確実に満たしているようにするためにさらなるテストが行われます。

７．最終確認

プロダクトチームとDSチームが再度集まり、UXと開発でのテスト結果を確認します。両チームが満足すれば、次のステップに進みます。そうでない場合は、繰り返しテストを行います。

８．ドキュメント作成とリリーススケジュール

チームは新しい変更のドキュメント化や変更履歴（例：Github）の更新、さらにリリースのスケジュール化を行います。

９．変更点のリリース：変更点のリリース、バージョン管理ガイドラインに従った製品のバージョンアップ、全チームへの通知（Slack、Asana、Trello、Githubなど）を行います。

１０．品質保証

品質保証のため、製品チームが最終的な変更点を確認します。

この１０ステップのプロセスにより、先に説明したデザインシステムに共通する７つの課題をすべて軽減できることがおわかりいただけると思います。複数の抑制と均衡により、デザインシステムはその完全性を維持しながら、変更を組織全体に伝達することができるのです。

このプロセスは、デザインシステムの多くの課題を解決しますが、抑制と均衡は人的エラーを排除するものではありません。なのでチームには、「信頼できる唯一の情報源（Single source of turh）を提供するツールが必要です。

UXPinによるデザインシステムのガバナンスの強化

UXPin Merge が、デザインとコードの間のギャップを埋めて「信頼できる唯一の情報源」を作成することで、デザイナーとエンジニアは常に同じツールで作業できるようになります。

ベクターベースの一般的なデザインツールでは、この問題は解決されず、デザイナーとエンジニアは、同じシステムを別々に更新し、同期させないといけません。

UXPin はコードベースのデザインエディターであり、Git や Storybook を介してコードコンポーネントを同期させ、プロダクトチーム、UXデザイナー、デベロッパーが同じコンポーネントで作業できるようにするものです。

最後に、プロトタイプはコードベースであるため、製品のアップデートやデザインシステムの変更に要する時間が大幅に短縮されます。

優れたデザインシステムのガバナンスを育む唯一のデザインツールをお試しになりませんか？UXPin Merge を使えば、デザインシステムを最大限に活用し、デザインコンポーネントとコードコンポーネントを全て最新の状態に保つことができますよ！

The post デザインシステムの ガバナンス とは？ appeared first on Studio by UXPin.

プロトタイピングツール は、デザイナーが最終製品のレプリカを作成するための製品で、ユーザーテストやステークホルダーへのプレゼンテーションや、デベロッパーへの引き渡しに使われます。デザインツールには、大抵追加機能としてプロトタイプがありますが、専用のツールを使うことで、より高度なプロトタイプができるようになります。

コードベースのデザイン革命を牽引する企業の１つである UXPin の１４日間の無料トライアルにサインアップして、次のデジタル製品や Web デザインのプロジェクトで UXPin の高度なプロトタイプ機能をぜひお試しください。

１．UXPin

UXPin は、デザインを完全にインタラクティブにすることができる、コードベースのプロトタイピングツールです。多くの主要なデザインソリューションとは違い、UXPin にはプロトタイプとテストに必要なものがすべて組み込まれているので、プラグインは必要ありません！

UXPin は、デスクトップ（Mac および Windows）へのダウンロードか、ブラウザでの使用を選択できますが、UXPin のダウンロードの方には、オフラインでも作業を継続できるというメリットがあります。

そして、ブラウザでのプロトタイプのテストや、UXPin の Mirror アプリを使って、iOS や Android などのモバイルデバイスでのプロトタイプの実行ができます。また、UXPin のドキュメントは素晴らしく、１ステップごとの説明やビデオによるチュートリアルで、このツールのあらゆる側面がカバーされています。

さらに UXPin には、他の プロトタイピングツール にはないもう１つの利点として、React コンポーネントで完全に機能するプロトタイプを構築するための UXPin Merge というのものがあります。

Merge を使うと、Git レポジトリや npm 経由での React コンポーネントの同期や、Vue、Angular、Web コンポーネント、Ember 向けの Storybook 統合の使用などのオプションがあります。また、Merge でレイアウトのデザインや、製品を １０ 倍速く立ち上げることができます。

２．Figma

Figma は、最も広く使われているデザインツールの１つであり、多くの YouTube コンテンツや詳細なドキュメントを備えた大規模で熱心なコミュニティがあります。

また、Figma には、複数のデバイスでプロトタイプをテストできるモバイルアプリを備えた「プロトタイピング機能」が内蔵されており、ブラウザでの作業も、Figma をダウンロードしてデスクトップでのオフラインの作業もできます。

ただ、Figma は初期段階のコンセプトには優れていますが、高度なプロトタイプはまだ完璧ではありませんし、デザイナーはユーザーテストに対応できるプロトタイプを作れるとは思えません。

２０２３年、Figma にはインタラクティブなプロトタイプをシンプルにする多くの機能が加わりましたが、Figma の入力はまだ制限されており、UX リサーチャーは、ユーザーの情報入力が必要なアクションをテストすることができません。このツールだと、ユーザーのインタラクションに適応する動的なユーザーフローは作りにくいです。

ただし、Figma で作成したプロトタイプにインタラクションを追加できます。Figma のデザインを UXPin にインポートして、インタラクティブなプロトタイプを作成するためのプラグインを使います。詳しく次のチュートリアルをご覧ください：Figmaのデザインをインタラクティブなプロトタイプにしよう

３．Adobe XD

Adobe XD も人気のある UX デザインツールですが、２０２３年に廃止されました。

Adobe UX のプロトタイプの面白い機能の１つに、特定のインタラクションの時間を節約してくれるオートアニメーションがあります。オートアニメーションで、アニメーションシーケンスの最初と最後のフレームを作成すれば、あとは Adobe XD が埋めてくれます。この機能は全アニメーションで機能するわけではありませんでしたが、パララックス（スクロールエフェクト）のようなものを作成する際にはかなりの時間の節約になりました。

４．Invision

Invision は長年にわたって強力なプロトタイピングコンポーネントでしたが、Figjam に似たコラボレーション用のツールに焦点を当てることにしました。プロトタイピングツールはまだありますが、市場にある他のツールに比べると、２０２４年にインタラクティブな製品を作るには物足りない感じです。

Invision には素晴らしい DSM（デザインシステム管理）機能があり、デザインシステムの管理や、デベロッパーへの CSS やスターターコードの提供に便利です。また、DSM は Storybook と統合されているので、デザイナーとデベロッパーはデザインシステムを同期することができます。ただ残念ながら、デザイナーは UXPin Merge のようにコードコンポーネントを使ったプロトタイプの作成はできません。

５．Framer

Framer は、２０２４年の Web レイアウト作成向けのプロトタイピングツールにおいてトップに君臨するうちの一つです。ラピッドプロトタイピングのための AI 機能を備えており、ユーザーが希望する Web サイトの種類を入力すると、Framer がカスタマイズするデザインを提供します。 Framer では AI が非常に早く取り入れられました。

その他の特筆すべき機能には、レイアウトと挿入メニューがあり、その機能によって、コンセプトのデザインや反復をサッと行うことができます。これは印象的ですが、UXPin にもオートレイアウトとビルトインのデザインライブラリによる同様の機能があります。

Framer の Smart Components 機能には、UXPin の ステートに似た機能がありますが、それほど包括的ではありません。バリアントと変数を使って、スイッチの切り替えやチェックボックスのアクティブ化など、要素にホバーまたは押された状態を付けることができるくらいです。

また、Smart Components は、他のベクターベースのデザインツールからステップアップしたとはいえ、UXPin のステート、インタラクション、エクスプレッション、変数の機能ほど忠実ではありません。

その他のデザインツール比較

その他にも、よく使われている以下のようなプロトタイピングツールと UXPin の比較もご覧ください：

• Marvel App
• Justinmind
• Proto.io
• Axure
• Zeplin
• Balsamiq

UXPin を体験してみよう

デザインツールをお探でしたら、上記の５つも含め、デザイナーが見た目のいい Lo-Fi（低忠実度）ワイヤーフレームやモックアップを作成するのに使えるのがたくさんあります。

ただ、UX のデザインにはテストが必要であり、つまりモックアップではなく、Hi-Fi（忠実度の高い）プロトタイプが必要だということです！UX デザイナーはコード化された製品をデザインしますが、画像ベースのプロトタイプでユーザーテストを行います。ただ、それだと正確で意味のある結果を得ることは不可能であり、必ずユーザビリティの問題が発生し、それが最終製品に反映されてしまいます。

そこで、UXPin のようなコードベースのツールがあれば、デザイナーは機能するHi-Fi（忠実度の高い）プロトタイプを作成できるので、ユーザビリティの参加者は、ボタンや入力が機能することを「想像」する必要はありません。

UX デザインの革命に繰り出しませんか。１４日間の無料トライアルにサインアップして、UXPin でより優れたプロトタイプとテストをぜひご体験ください。

The post ２０２４年版 – プロトタイピングツール ５選 appeared first on Studio by UXPin.

Figma、AdobeXD、UXPin の３つは、デジタル製品をデザインするための主要なUX（ユーザーエクスペリエンス）デザインツールです。

この記事では、これら３つを比較してUIデザイン、モックアップ、プロトタイプ、連携に関してそれぞれの位置付けや特徴を紹介していきます。

どのデザインツールがあなたのプロジェクトやチーム・組織のニーズに最適か、ぜひご覧ください。

主なポイント

• AdobeXD は、Creative Cloud Suiteとシームレスに統合することで、Photoshop や Illustrator などのツールとのスムーズなデザインワークフローを実現する。

• Figma は、リアルタイムでの連携に最適なプラットフォームであり、複数のユーザーによる同時デザインが実現する。

• UXPin は他のデザインツールとは違い、コードベースのデザインツールであるため、複雑なプロトタイプを作成することができる上に、Mergeテクノロジーによってデザインとコードのギャップを埋める。

• 適切なデザインツールの選択は、プロジェクトの複雑さ、連携の必要性、統合の好み、プロトタイプ機能によって決まる。

世界最先端のUXデザインツールを使って、デザインプロセスに隠れたユーザビリティの問題を解決し、より多くのビジネスチャンスを特定しましょう。

デザインと開発をつなぐ「信頼できる唯一の情報源（Singel source of truth）」を作成しましょう。こちらからUXPin Mergeをぜひご覧ください。

AdobeXD とは

料金

Creative Cloud は ＄８２.４９（Photoshop、Illustrator、InDesign、Premiere Pro、Acrobatなどの２０以上のクリエイティブデスクトップおよびモバイルアプリケーションを含む）

最適な用途

Adobeユーザー、UIデザイン

機能の概要

• Photoshop や Illustrator などの Creative Cloud とのシームレスな統合

• 自動アニメーションで、スムーズなマイクロインタラクションとトランジションが実現し、プロトタイプのリアリズムが充実する

• 音声機能付きプロトタイプの統合で、UIデザイナーが音声UI をテストできるようになる

• リピートグリッドは、デザイン要素の迅速な複製を促進し、それによって反復作業を最適化し、デザインの一貫性を保証する

AdobeXD は、Adobe の Creative Cloud Suiteに含まれる UX および UIデザインツールです。

これは、インタラクティブなデザインを設計、プロトタイピング、共有するためのプラットフォームです。

Adobe のエコシステム内に統合されているため、デザイナーは Photoshop や Illustrator などのツール間を簡単に移行できるため、デザインプロセスが効率化します。

Figmaとは

料金

＄１２〜＄７５

最適な用途

UI（ユーザーインターフェース）デザイン、連携（コラボレーション）

機能の概要

• リアルタイムの連携により、複数のユーザーが同時にデザインを行うことができ、チームワークと即時のフィードバックを促進する

• 統合機能により、多くのプラグインやサードパーティ製アプリが提供される場合があり、それによってプラットフォームの機能が強化する

• ブラウザおよびデスクトップアプリケーション

• 開発モードで、エンジニアがデザインを分析し、スターターCSS でコードに変換しやすくなる

• バリアブルを使うと、デザイナーはユーザーのインタラクションに基づいてコンポーネントのプロパティを変更できる

Figmaは、リアルタイムの連携のために構築された、ベクターベースのデザインプラットフォームです。

ブラウザベースのツールであるため、アクセスの障壁がなく、それによって場所やデバイスに関係なくチームが同期して作業できることが保証されます。

また、Figmaの直感的なインターフェースとパワフルなプロトタイピング機能は多くの人に愛され、UXプロフェッショナルも愛用しています。

複数のデザイナーが同時にプロジェクトを編集できる機能など、コラボレーションに重点が置かれています。デザイン空間におけるチームワークが再定義されたことで Figmaはデザインツールのトップとして確立しました。

 FigmaはAdobeに買収されたのか

Adobe は２０２２年９月に Figmaの買収計画を発表しましたが、この買収はまだ成立しておらず、２０２３年８月の欧州委員会の調査を含む規制当局の精査を通過しないといけません。

規制当局は、Adobeによる買収で「インタラクティブ製品デザインのソフトウェアとデジタル資産作成ツールの供給に関する世界市場での競争を低下させる可能性がある 」ことを最も懸念しています。

そして、この契約が成立すれば、AdobeはAdobeXDを廃止し、UXデザインツールとして Figmaを Creative Cloud にバンドルすると噂されています。

UXPinとは

料金

＄３９〜＄１４９

最適な用途

UI デザイン、インタラクションデザイン、デザインシステム

機能の概要

• ブラウザとデスクトップアプリケーション

• 高度なインタラクティブプロトタイプにより、デザイナーはデザインプロセスにおいて、より多くのユーザビリティの問題を解決し、より良いビジネスチャンスを特定することができる

• UXPin のコメント機能を使ったリアルタイムの連携とコミュニケーション

• ステートにより、デザイナーは１つの要素に対して複数のステートを作成し、ドロップダウンメニュー、タブメニュー、ナビゲーショナルドロワーなどの複雑なインタラクティブコンポーネントをデザインできる

• Variables（変数）がユーザーの入力からデータを取得し、アプリバーに表示される名前やプロフィール画像のように、個別化されたダイナミックなユーザー体験を作り出す

• Expression（式） 複雑なコンポーネントや高度な機能を作成するための Javascript のような関数 – コードは不要！

• 条件付きインタラクションは、ユーザーのインタラクションに基づいて［if-then］と［if-else］の条件を作成し、複数の結果を持つダイナミックなプロトタイプを作成して、最終的な製品エクスペリエンスを正確に再現する

• UXPin の Merge テクノロジーを使って、React、Vue、Angular などのコードコンポーネントでデザインする

• UXPin の IFTTT 統合を使って、API やその他のデジタル製品を連携する

• UXPinのデザインシステムで、アセット、ドキュメント、UI 要素、カラー、タイポグラフィなどのコンポーネントライブラリを作成および共有する

• ネイティブアプリケーション（iOSとAndroid）の UXPin Mirror を使ったクロスプラットフォームのプロトタイプテスト

UXPinはコードベースのデザインツールで、デザイナーはリアルなプロトタイプを簡単に作成できます。

そしてデザイナーは、ツールのフォームとビルトインのデザインライブラリにより、 Figma や AdobeXD のような従来の画像ベースのデザインツールよりも速くモックアップやプロトタイプの作成や、テストおよび反復をすることができます。

UXPinの強みは、ベクターグラフィックスではなくコードをレンダリングできることです。

このコードベースのアプローチで、プロトタイプの範囲が広がり、ステークホルダーやユーザーからのより良いフィードバックのテストを強化するのです。

UXPinのMergeテクノロジーでデジタル製品デザインをレベルアップしてみませんか？

デザイナーはレポジトリからUIコンポーネントをインポートし、”実物に近い” 動きや操作・機能性のあるプロトタイプを作成しましょう！

UXPinとFigmaの違い

UXPinとFigma は、一見似ているように見えます。デザイナーは、左側にコンポーネントライブラリとレイヤー、右側にプロパティとインタラクションがあり、どちらのツールもデザインキャンバスが中央にあります。特に、Figmaでデザインし、UXPinでプロトタイプを作成するのが好きなUXデザイナーにとっては、このような親しみやすさでツールの切り替えがしやすくなります。

では、UXPinとFigma の主な違いを以下に挙げましょう：

• UXPinはコードベースで、Figmaはイメージベースである。UXPinのコードベースアプローチは、デザイナーが Figma や AdobeXD では再現不可能なコードのような機能やインタラクションを作成できるということである。
• UXPinには、テキスト入力などのフォームフィールドがあり、対する Figmaの入力フィールドは、使用不可で非インタラクティブなグラフィカル表現である。
• 「Code-to-Design（コードからデザイン）」か「Design-to-Code（デザインからコード）」の違いがある。Figma は「Design-to-Code（デザインからコード）」アプローチであり、デベロッパーは静的デザインをコードに変換しなければいけない。対する UXPinでは「Design-to-Code（コードからデザイン）」のワークフローを提供する一方で、「Code-to-Design（コードからデザイン）」へのソリューションも提供している。デザイナーはMergeを使ってコードコンポーネントをデザインプロセスにインポートできる。
• Figmaはアートボードとフレームを使い、UXPinは画面をページに分ける。

プロトタイプに最適なデザインツール

Figma や AdobeXD のような画像ベースのデザインツールは、ワイヤーフレームやモックアップ、基本的な低忠実度（Lo-Fi）プロトタイプには最適ですが、UXPinのインタラクティブプロトタイプ機能にはかないません。

例えば、Figma や AdobeXD では、美しいフォームやユーザーフローを作成できますが、入力はインタラクティブではありません。

そのため、デザイナーはテスト中に意味のあるインサイトを得ることができず、何か外部ツールを使うか、エンジニアと協力して実用的なプロトタイプを作成しないといけません。

一方、ステート、インタラクション、変数、Expressionなどの UXPinのインタラクティブ機能を使えば、デザイナーはコードベースのプロトタイプが反映されたインタラクション、ユーザーフロー、機能をデザインできます。

このような高度な機能により、プロトタイプの範囲が大幅に広がり、複雑なプロトタイプ機能や API統合であっても、デベロッパーを巻き込む必要がなくなります。

デザインツールの選び方

以下に、Figma、AdobeXD、または UXPinのいずれかを選択する際の重要な判断基準を挙げましょう：

• プロジェクトの範囲と複雑さ: どの３つのツールも、簡単なデザインに対して同等のエクスペリエンスと結果を提供するが、インタラクティブなプロトタイプを構築したい場合、またはデザインと開発を同期したい場合は、UXPinが最適なオプションである。

• 連携のニーズ: リアルタイムの連携がリストの上位にある場合、Figma の同時マルチユーザー機能は不可欠であり、 UXPinだと、Slackと統合されたコメント機能を通じて同様のソリューションを提供する。

• プラットフォームのアクセシビリティ: Figma と UXPin のブラウザベースのアプリケーションは、どこからでもアクセスを優先するには非常に重要であるが、もし Adobe Suite愛用者であれば、AdobeXDがエコシステムによりよく適合する。

• 統合と拡張機能: Figmaの豊富な統合エコシステムは、ワークフローがサードパーティ製プラグインで成り立っている場合は便利。Photoshopのようなツールとのシームレスな同期ではAdobeXDがお勧め。デザインと開発の同期を優先する場合、UXPinとMergeテクノロジーが最適である。

• フィードバック ループ: 効率化されたフィードバック プロセスは、最新の非同期製品開発にとって極めて重要。 UXPinのプレビューに関するコメント機能を使うと、ステークホルダーや他のチームは、UXPinのアカウントを持っていなくても、特定のチームメンバーにコメントを割り当てるなど、プロトタイプに関するフィードバックに注釈を付けることができる。

• 高度なプロトタイプ: UXPinは最も洗練されたプロトタイプ機能を提供するが、AdobeXDの音声プロトタイプはVUIデザイナーにとってユニークで便利な機能である。

• 信頼できる唯一の情報源（Single source of truth）： UXPin は、これら３つのツールの中で、Mergeテクノロジーを介して「Code-to-Design（コードからデザイン）」のソリューションを提供する唯一のツールである。Mergeがデザインと開発用の単一のUIライブラリでデザイナーとエンジニア間のギャップを埋め、シームレスな製品開発ワークフローとスムーズなハンドオフが実現する。

• 学習曲線: AdobeXD、Figma、およびUXPinには同等の学習曲線があるが、UXPinの高度な機能を習得するには少し時間がかかる。その代わり、デザインの迅速な反復と市場投入までの時間の短縮が得ることができる。

「以前まではBalsamiqを愛用していまいしたが、Figmaを使い始めてからはとても気に入りました。ですが、UXPinと出会って強力なスクリプト機能が使えるようになり、エンジニアの同僚が最終製品で使うのと同じライブ HTML UIコントロールを使ってインタラクティブなUIをデザインできるようになった今、もうFigmaには戻れません。」 シニアUXデザイナー、Anthony Hand

UXPinの「Code-to-Design（コードからデザイン）」が FigmaやAdobe XDを上回る理由

Figma と AdobeXD はビジュアルデザインを実現しますが、UXPin の「Code-to-Design（コードからデザイン）」へのアプローチは、デザインと開発間のギャップを埋めることで差別化を図ります。

また、UXPinは、ベクター グラフィックスの代わりに実際のコードをレンダリングすることで、プロトタイプの信頼性を確保し、それによってベクターベースのプロトタイプとインタラクティブ性の誤解による「よくある落とし穴」を回避します。

UXPinのMergeテクノロジーで、レポジトリから UIコンポーネントを統合し、それによって最終製品を正確に反映する、完全に機能する高忠実度のプロトタイプが実現します。

Figma と AdobeXDは視覚的な表現に依存しており、デザインに動きなどを加えるために追加のツールや開発者のサポートが必要になることがよくあります。ですが、UXPinはここで紹介したようなコードベースのアプローチと多機能性によって、シームレスで正確かつ迅速なデザインから開発までのプロセスを実現できます。

UXPin Mergeテクノロジーを使って「Code-to-Design」アプローチで製品開発ワークフローに革命を起こし、より良いデザインを効率的につくりましょう。デザイナーとデベロッパーの連携を改善し、顧客により良いUXを提供しましょう。

詳細とアクセスのリクエスト方法については、こちらのページをぜひご覧ください。

The post 【必見】Figma と AdobeXD と UXPin の違い appeared first on Studio by UXPin.

リソースの節約

デザインプロセスを反復すると、ユーザー（少なくともステークホルダー）からのフィードバックも定期的に得ることができるため、多くの時間節約につながります。

受け取ったフィードバックはポジティブなものも、ネガティブなフィードバックも正しい方向性を知ることができるきっかけとなるので、貴重な時間を無駄にすることはありません。

フィードバックが全くない場合、ゴールまで急いでも失敗している危険性があり、時間と帯域の大きな無駄となります。さらに、「時は金なり」ですから、デザインイテレーションは最も費用対効果の高い選択肢となりますね。

連携の促進

デザインプロセスを反復することで、ステークホルダーが意見を述べたり、自分のアイデアを共有したりする機会ができるため、健全な連携が促進されます。その結果、「自分の視点でのみ物事を見る」ということにならないため、自分だけでは発見できないような気づきが得られます。

本当のユーザーニーズへの対応

デザイン イテレーション のプロセス（特に連携を取り入れたプロセス）が確立されていないと、デザイナーは孤立して仕事をするという罠にはまりがちです。サイロ化すると、内省的になりすぎてしまい、それが早合点や、生産性のない完璧主義への暴走につながってしまいます。

しかし、デザインプロセスを反復的に実施することで、ユーザーのニーズに焦点を当て、ユーザーからのフィードバックに従った意思決定を行うことができます。また、漫然とした改善に終始するのではなく、次善の策に優先順位をつけてデザインの改善ができるようになります。

さらに、ユーザーからのフィードバックによって、ステークホルダー間の意見の対立を解消できるようにもなります。

定期的な更新のしやすさ

デザインプロセスの反復によって、ステークホルダーに最終結果を投げかけて「見といてね」と放置するのではなく、定期的に進捗状況の更新を提供することができます。

特にデベロッパーにとっては、これは「デザインの途中でも開発に着手できますよ」ということです（実際、デベロッパーは反復的な開発プロセスを活用することができますから、みんなにとっていい話になります）。

また、顧客と仕事をする場合、頻繁に更新することで、製品にかける努力を示すことができ、それによって顧客との良好な関係を築くことができます。さらに、製品の定期的な更新を顧客に伝えることで、マーケティング上の話題を提供し、世間の声を得ることだってできます。

UXPinのプロトタイプは、顧客やステークホルダーとの共有がすぐにできます。数回クリックするだけで、デザイナーは、顧客やステークホルダーが本物と同じように見えて機能するデザインイテレーションをテストする際に、コンテクストに応じたフィードバックのコメントを得られるようになります。また、アダプティブバージョンを使うと、シミュレーションされたプロトタイプは、デバイスやスクリーンサイズに適応します。ただし、プロトタイプの共有前に、プレビューモードでエラーや見落としがないかをチェックすることを忘れないでください！

 イテレーション が使われる場所

イテレーションはデザイナーだけのものではありません。ソフトウェアデベロッパーも、非同期で、あるいはデザインのイテレーションに連動して、仕事に反復的なアプローチを取ることができます。さらに大規模なものでは、プロジェクト全体をイテレーションで計画的に管理することも可能です。

デザインにおける イテレーション 

デザインにおいては、イテレーションは、以下のような多くのデザイン方法論において重要な役割を担っています：

• デザインスプリントの方法論
• HCD（人間中心のデザイン）
• デザイン思考およびリーンUX 
• ラピッドプロトタイピング （3Dテクノロジーを使って迅速（ラピッド）に製品の試作品（プロトタイプ）を作成する開発技法）のアプローチ

どのような方法論であっても、必要なリソースがあれば、同時進行の反復デザインプロセスを用いて、非同期で複数のユーザーニーズに対応することができます。

ソフトウェア開発におけるイテレーション

ソフトウェア開発では、イテレーションは継続的な改善の促進や、誤差の範囲の提供、そして製品開発プロセスの他の側面が妨げられるのを防ぐのに使われます（直線的で、すべてのプロセスを順次行うことを強制するウォーターフォール方法論とは違いますね）。実際、反復的なアプローチによって、例えば「アジャイルUX」と「アジャイルソフトウェア開発」を組み合わせて機能性を構築したり、デザインと開発のチームメンバーが連携して作業できるようになります。

プロジェクト管理におけるイテレーション

最後に、イテレーションは、より高いレベルでも機能し、それによって製品やプロジェクト管理プロセス全体の包括的なテーマとなることもあります。プロジェクトのステークホルダーに、ライフサイクルを通じて製品の方向性に関する定期的な最新情報や、主要な成功メトリクスを測るのに使えるデータを提供しますからね。

さらに、イテレーションは DesignOps や DevOps などの社内業務の改善にも活用でき、それによってチームの士気と生産性が大幅に上がります。

リサーチにおけるイテレーション

イテレーションは、リサーチによって促進されるべきです。デザインにおけるフォーカスグループであれ、開発におけるブラウザテストであれ、リサーチで学んだことはすべて、次のイテレーションを推進するために使用されるべきです。

場合によっては、リサーチは非同期かつ独立して行うことができ、「デザイン」または「開発」された成果物を得る必要がないこともあります。例えば、ナビゲーションのラベルや構造を考えるとき、デザイナーは様々な形式的・総括的なカード分類を繰り返し、最終的にシンプルな要件にたどり着くことができますよね。

反復的なデザインプロセスとはどんな感じか

反復的なデザインプロセスは、方法論によって異なりますが、一般的には、計画、アイデア出し、プロトタイプ、テスト、レビューという５つのステージにハッキリとと分けてまとめることができます。

ステージ１：計画

イテレーション（反復）は早いだけでなく、効果的に行われないといけないので、特定のユーザーニーズに焦点を当てたイテレーションを続けるには、ある程度の計画が必要です。

計画段階は、イテレーション中にどの問題を解決するかを決めることがほとんどです。時にはステークホルダーの観察に耳を傾けることもありますが、ほとんどの場合、以前のイテレーションやフィードバックフォームなどの別の場所からユーザーのフィードバックを直接集めるということになります。

いずれにせよ、この段階は常に「リサーチ」という燃料を得て、「目的」によって動かされます。多くのデザイン方法論では、問題は「機会」としてとらえ直され、多くの機会が存在する場合には、方法論は「ステークホルダーは製品の改善に一番いい機会であると思われるものに投票すべきである」述べています。例として、デザインスプリントの方法論は、機会を選択するために「How might we（どのようにすれば〜できそうか）」と「ドット投票（多数決のようなもの）」に依存しています。

つまり、計画段階では、 「今回のイテレーションで何を改善すべきか」という問いに答えられるはずです。

ステージ２：アイデア出し

この段階では、アイデアの良し悪しに関係なく、スケッチによってできるだけ多くのアイデアを出すことが目的です。これは通常、最高のアイデアを磨き上げ、最悪のアイデアを脇に置くという、それ自体が反復的なデザインプロセスそのものです。

創造力を維持するために、Crazy 8s（チームメンバーが30~60秒ごとに合計8つの異なるアイデアを考え、それぞれを紙に書き出す手法）、Four-Step Sketch（1）重要な情報を確認、2）紙の上でデザイン、3）複数のバリエーションの検討、4）詳細な解決策の作成を元にコンセプトを作り上げる）などの反復的な方法論があり、プロセスを無駄なく、楽しく、生産的に保つために時間制限を設けています。

最終的に、我々やチームは、少し洗練されたアイデアを１つ選び、前進させることになります。そして選ばれたアイデアは、プロトタイプ担当が問題提起、明確に定められた実行可能なタスク、そして詳細で十分なビジュアルガイドを得ることができるように、よくユーザーストーリーとして表現されます。

ステージ３：プロトタイプ

プロトタイプの段階になると、特定のアイデアに集中するため、反復的なデザインプロセスが少しシンプルに感じられるようになります。

生産性を最大化するために、通常は時間制限が設けられているので、UXPin のようなワークフローをサポートするデザインツールを使うのがベストであり、製品チームが手元にデザインシステムを用意して、UXデザイナーがそれを徹底的に理解すれば、さらなる効果が期待できます。

ステージ４：テスト

テスト段階は、解決しようとしている問題をプロトタイプが解決しているかどうか、また、どの程度解決できているかの確認を目的としています。何かを実装したり、リサーチを統合したりすることはなく、適切なリサーチ方法を用いて、ソリューションについてできるだけ多くのことを学び、フィードバック、発見、インサイトを文書化するだけです。

ステージ５：レビュー

最終段階であるレビューでは、リサーチを総括して、ソリューションの有効性について結論を出します。

結論は通常、以下のカテゴリーのいずれかに分類されます：

• 「すばらすい」：実装の時期
• 「いいですけど、、、」：プロトタイプに戻る
• 「不具合あり」：アイデア出しに戻る

デザインイテレーションプロセスの「やるべきこと」と「やってはいけないこと」

やる：失敗を恐れない

たとえ失敗したとしても、失敗を恐れず、試行錯誤し、「やってはいけないこと」を学びましょう。失敗は避けられないものなので、早めに解決して、そこから学ぶようにするのが一番です。

やる：柔軟に行く

デザインの方法論は、イテレーションに時間をかけすぎず、自由な創造性を発揮できるように厳しいルールを設けていますが、それでもある程度の自由度は認められています。最終的に、どの機会を優先するか、どのタイミングでイテレーションやテストを行うか、また、同時にいくつのデザインイテレーションプロセスを実行するかは、私たち次第なのです。

その判断は、あらゆるデータやリサーチを駆使しながらも、直感と経験によるところが大きいです。

やる：非同期での作業

ツールやチームメイトなど、利用できるすべてのリソースを活用し、他のデザイナーが非同期で製品の他の側面を解決でき、デベロッパーも有効な解決策を実装し始めることができることによって、最短時間で最大の成果を得ることができます。この２つが行われることで、製品のタイムラインが大幅に短縮されるのです。

やる：連携して耳を傾ける

どの問題を解決すべきなのか？どのイテレーションがベストか？プロトタイプをテストする準備はできているか？このフィードバックにはどんな意味があるのだろう？チームメイトから新鮮な視点と独自の専門知識を得ることで、このような疑問に自信をもって答えられるようになります。

やらない：すべてを解決しようとする

デザインイテレーションプロセスで解決する問題が決まったら、それ以外の問題を解決しようとするのは避けましょう。テストや観察の時に改善すべき点が見つかるのは当然ですが、それが後のイテレーションで良い出発点になるかもしれないので、それは書き留めておきましょう。

スコープクリープ（デザインイテレーションプロセスに忍び込む新たな問題）を許すと、気が散ってスピードが落ち、イテレーションが主要なメトリクスに与える影響を測るのが難しくなるだけですからね。

まとめ

デザインイテレーションの基礎は理解できたので、次のステップは、自身やチームに合った反復デザインの方法論を選択し、全員がそれを習得するために十分な時間を確保しましょう。

ただ、完璧なデザイン手法なんてないので、もしうまくいかない場合は、ワークフローを変更するか、別の方法を試すことを検討してください。

UXPinによるイテレーション（反復）デザイン

UXPinは、製品チームの速やかなイテレーションやアイデアのコラボレーション、実用的なフィードバックの獲得、そして最終的にはコードベースの高忠実度プロトタイプをサポートし、デベロッパーがより多くの作業を行えるようにするために作られたエンドツーエンドのデザインツールです。

UXPinでは、デベロッパー が HTML、CSS、JavaScript に変換されたプロトタイプの仕様の実装、デザインシステムのドキュメントの共同作成、さらにUXPin Mergeを使った実際のReactコンポーネントをプロトタイプにインポートできるため、検証済みのイテレーション作業をより速やかにして生産に移ることができます。

気になった方は、まずは14日間の無料トライアルからぜひお試しください。

The post デザイン イテレーション プロセス入門 appeared first on Studio by UXPin.

日付ピッカーは、Web サイト、アプリケーション、ゲーム、企業向けソフトウェア、OSなどで使われる、デジタル製品のデザインにおいて最も馴染みのあるUIパターンの１つです。

そしてデザイナーは、日付ピッカーがスクリーンサイズ、OS、デバイスなどでどのように機能するかを理解し、製品の美観、機能性、全体的なUX（ユーザーエクスペリエンス）への影響をテストしないといけません。

UXデザイナーは、従来の画像ベースのデザインツールで日付ピッカーは作成できませんが、UXPin Mergeでは可能です。UXPin Mergeの技術によって、完全に機能する日付ピッカーをGitレポジトリやnpmパッケージ、さらにStorybookからインポートすることができるのです。  

UXPinに同期された日付ピッカーは、最終製品のように機能します。アートボードをリンクしてインタラクションを作成する必要はありません！Mergeへのアクセスリクエストはこちらのリンクから。

 日付ピッカー とは

  日付ピッカーは、ユーザーが特定の日付、時間、またはその両方の組み合わせを選択できるようにする UIパターンであり、フォーマットの一貫性を確保しながら、日付の取得を効率化することを目的としています。

 日付ピッカー が必要な理由

  世界では、例えば米国だと「mm/dd/yyyy（月/日/年）」のように「日」の前に「月」を置くのに対し、英国では「日、月、年」の形式を使うというように、日付の表示形式が異なります。

これは微妙な違いに見えますが、データベースはユーザーが米国形式を使っているのか、英国形式を使っているかを区別することはできません。データベースは、どちらか一方の形式でしか日付を正しく読み取ることができないのです。例えば『２０２２年１０月１日』を数字で見てみましょう：

• 米国：10/01/2022 （英国だと 10日1月2022年）
• 英国：01/10/2022 （米国だと1月10日2022年）

  この例では、データベースは各エントリーを「１０月」ではなく「１月」として解釈しています。 また、ユーザーは同じ日付を複数の方法で入力し、異なるセパレーターを使用することもできます。以下に例を挙げましょう：

• Oct 1, 2022 
• Oct 1, 22
• 1 Oct 2022
• 1 Oct 22
• 10-01-22 / 01.01.2022 / 10/01/22 
• 22/10/01 / 2022/10/01

  日付ピッカーによって、ユーザーが日、月、年を個別に選択し、あいまいさをなくし、システムが一貫した正確なフォーマットを提供できるようにします。 

モバイルとデスクトップにおける 日付ピッカー の UIデザイン

モバイルの 日付ピッカー 

デザイナーは、iOSやAndroidのようなモバイルのオペレーティングシステムがユーザーにどのように日付ピッカーを表示するかを認識することが重要です。ちなみに、 iOS のネイティブピッカーでは無限スクロールのUIが使われ、Androidアプリケーションでは月全体を表示するカレンダービューが使われています。

また、iOSでは親指でのスクロールができますが、Androidでは親指タップに最適化されたUIとなっています。

デザインシステムからカスタムの日付ピッカーを使うこともできますが、ネイティブのオプションを使うことで、親しみやすさが生まれ、製品の学習曲線が短くなります。ただし、モバイルアプリにネイティブの日付ピッカーを使う場合は、iOSのUIで述べたようなユーザビリティの問題が生じないように注意しましょう。

デスクトップの 日付ピッカー 

  大抵のデスクトップのWebサイトやアプリケーションは、カレンダーの日付ピッカーが使われており、余分なスペースとマウスを使うことで、ユーザーは数回のクリックだけで簡単に日付を選択できます。また、多くの製品では、ユーザーが手動で日付を入力するための入力フィールドが提供されています。

日付の数値の入力フィールドは、デスクトップでもうまく機能します。UXデザイナーは、ユーザーを正しいフォーマットに導くべく、プレースホルダーや有益なエラーメッセージを含めないといけません。

 日付ピッカー の UIデザイン５種

数値の入力フィールド

  最も基本的な日付ピッカーは、数値入力またはテキスト入力フィールドです。このようなフィールドには、日付ピッカーを備えたモーダルポップアップが含まれる場合があるか、ユーザーは区切り文字を使って日付を入力する必要があります。

製品によっては、US Web Design Systemsのこの例のように、ユーザーが日付を入力するか、モーダルを使うかを選択できるものもあります。

プレースホルダーは、「MM/DD/YYYY（月/日/年）」といった日付のフォーマット方法をユーザーに示す必要があります。UXデザイナーは、ユーザーが「月」と「日」を入力するとセパレーターが表示される日付のオートフォーマットを適用することで、これをさらに推し進めることができます。また、デザイナーは、ユーザーがフォームに記入する方法を知ることができるように、ヘルパーテキストを下に追加することもできます。こちらの例をご覧ください。

ドロップダウン日付セレクタ

  デザイナーは、Webサイトやデスクトップのアプリケーションで、大体はドロップダウンの日付セレクタを使用します。ただこのような日付ピッカーはマウスではうまく機能しますが、オプション間のスペースが少ないため、モバイルデバイスのユーザー、特に大きな指や親指を持つユーザーには難しいかもしれません。

ドロップダウンセレクタは、カレンダーモーダルで単一の入力フィールドを使うよりも多くのスペースを占有し、ユーザーが「日」、「月」、「年」を個別に選択する必要があるため、入力に時間がかかります。

なので、ドロップダウンセレクタは、デスクトップアプリケーションやWebサイトには最適ですが、オンボーディングフォームではボトルネックになるかもしれません。

スクロール 日付ピッカー 

  スクロール日付ピッカーは、ユーザーが日、月、年を別々に選択するため、ドロップダウンと同様に機能します。このようなスクローラーは、ユーザーが親指を使って日、月、年をスクロールできるモバイルデバイスで最も便利です。

ただ、多くのユーザーは、スクロール式の日付ピッカーが遠い未来や過去の日付には適していないとの不満を抱いています。何十年もスクロールするのは時間がかかり、特に手や指に障がいのあるユーザーにとっては大変です。

ちなみに、iOSのデフォルトの日付ピッカーは、スクロール式の日付ピッカーの最も一般的な例ですが、Appleでは、はるか過去や未来の日付にカレンダーピッカーがよく使われています。

カレンダー 日付ピッカー 

  カレンダーUIは、最もよく使用される日付ピッカーであり、カレンダー日付ピッカーは、OS、デバイス、画面サイズに関係なくうまく機能します。

物理的なカレンダーやデジタル形式のカレンダーは誰でも見慣れたものであるため、ユーザーはこのような日付ピッカーで慣れ親しみ、それによって認知的な負荷や製品の学習曲線が軽減します。

カレンダーのUIは、日付範囲のピッカーに特に有益で、それによってユーザーは自分の選択を視覚化してサッと調整することができます。  

タイムラインピッカー

タイムラインピッカーは、１週間までの短い日付範囲や数時間の時間枠を選択するのに適しています。タイムラインのUIは、ユーザーが［開始日］と［終了日］を選択するためにインジケータをドラッグすることができるので、モバイルデバイスで特に便利です。

タイムラインピッカーは日付にも使えますが、タイムウィンドウの選択に最適です。

 日付ピッカー のUIとUXのベストプラクティス

日付ピッカー のアクセシビリティ

  デザイン性の低い日付ピッカーだと、障がいのあるユーザーやスクリーンリーダーを使うユーザーはイライラしてしまう可能性があります。全ユーザーが日付の選択にアクセスできるようにするには、物事をシンプルに保つことが非常に重要です。

以下は、日付ピッカーにアクセスしやすくするための推奨事項です：

• 日付フィールドには明確なラベルを使いましょう。例えば、誰かが予約をしている場合、スクリーンリーダーや認知障がいのユーザーが必要な日付を知ることができるように、フィールドに「予約日」または「予約日を選択してください」というラベルを付けます。
  
  
• プレースホルダーと入力フィールドの上または下にフォーマットのヒントを含めましょう。このバリデーションで、明確な指示によって全ユーザーに利益がもたらされると同時に、日付ピケットがより利用しやすくなります。
  
  
• ユーザーは、タッチ、マウス、スクリーンリーダー、キーボードを使って日付ピッカーを使えないといけません。UX デザイナーは、全ユーザーとデバイスが 確実にUIを操作して簡単に日付を選択できるようにするために、日付ピッカーをテストしないといけません。
  
  
• 日、月、年のフィールドを分けることで、スクリーンリーダーやキーボードユーザーが日付を入力しやすくなります。UX デザイナーは、ユーザーがカレンダーを使って選択を完了できるように、ボタンまたはカレンダーのアイコンを含めるのもいいでしょう。（USWDSの日付ピッカーの例を参照）。

以下は、日付ピッカーのアクセシビリティリソースです：

• Collecting dates in an accessible way by Hassell Inclusion
• Date picker by US Web Design System
• General accessibility guidance for forms by US Web Design System

現在の日付を表示

  カレンダーピッカーでは、ユーザーに［現在の日付］と［選択内容］の表示が重要です。現在の日付を強調表示することで、ユーザーが選択する際の基準となり、特に旅行や予約の際に重要です。

「現在の日付」と「ユーザーが選択した日付」の区別は、混乱を避けるために非常に重要です。マテリアルUI では、現在の日付にはアウトラインを、選択された日付には陰影のある背景を使用することで、これをハッキリと区別しています。

空いてない日をブロックする

日付を選択しても、その日が利用できないことが判明するのは、最もイライラするユーザー体験のひとつであり、それでユーザーは選択をやり直して、空きを見つけるまで試さないといけません。そこで、空いてない日付をブロックすることで、ユーザーはカレンダーに戻ることなく選択することができます。

追加の重要な意思決定データを提供する

Booking.com や Airbnb などの多くの旅行予約アプリは、ユーザーが最良の料金を見つけることができるように、各日付の下に１泊あたりの料金を表示しています。この情報でユーザーはお金を節約できるため、ポジティブなユーザー体験が生み出されます。

不要なデータの削減

カレンダーのUIは、ごちゃごちゃして煩わしい場合があります。デザイナーは、カレンダーを読みやすくしてタスクを完了しやすくするために、UI要素、線、その他のコンテンツをできるだけ減らさなないといけません。例えば、ユーザーは「生年月日」を選択する際に「曜日」を見る必要はありませんよね。

また、UXデザイナーは、カレンダーの背後にあるコンテンツを遮断するために、モーダルオーバーレイに無地の背景を使わないといけません。

UXPinで 日付ピッカー をデザインする方法

UXPinは、インタラクティブで動的な忠実度の高いプロトタイプを作成するための高度なプロトタイピングツールです。大抵のプロトタイピングツールでは、１つのインタラクションをプロトタイプ化するために複数のアートボードを作成する必要がありますが、UXPinではステート、Variables（変数）、条件を使って完全に機能するページを作成できます。

UXPin に日付ピッカーを挿入するには、まず垂直ツールバーの「Search All Assets（すべてのアセットを検索）」の検索アイコン（command + F / Ctrl + F）をクリックします。

次に、入力フィールドで「date（日付）」または「calendar（カレンダー）」を検索します。

オプションは［Components（コンポーネント）］ の見出しの下に用意されるものもあり、タッチユーザーに最適なものもあれば、キーボードユーザーに最適なものもあるでしょう。ただし、「Input calendar（カレンダー入力）」は、タッチユーザーにはカレンダーを提供し、キーボードユーザーには入力フィールドを提供します。

 日付ピッカー コンポーネントのスタイリング

UXPin のコンポーネントはすでに優れたUXを提供するようにデザインされていますが、皆さんはブランドが持つビジュアルアイデンティティやアプリ/ Web サイトの美的感覚に合うようにスタイリングしたいと思うでしょう。そのためには、右側のプロパティパネルを使いましょう。

UXPinのデザインシステムライブラリ（特にテキストスタイルとカラースタイル）を使っている場合は、すでに確立されているスタイルを活用することで、日付ピッカー コンポーネントとデザインの他の部分の視覚的な一貫性をある程度維持できます。

コンポーネントをカスタマイズするには、スタイルを設定したいレイヤーを選択し、「デザインシステムライブラリ」の アイコン（⌥ + 2 / alt + 2）をクリックして UXPinのデザインシステムライブラリに移動し、レイヤーに適用したいスタイルを選択します。

実際のコンポーネントで代用

デザイナーは、同じコンポーネントを何度も挿入したりスタイリングしたりして毎回最初からいちいち作るのではなく、デベロッパーによってすでに構築されたリリース可能なコンポーネントを使用できます。コーディングなしで Git、Storybook、または NPM からコンポーネントを取り込むことができ、見た目も機能も本物と同じです。これを実現できるUXPinが持つテクノロジーについてご覧になりませんか。こちらからぜひアクセスをリクエストしてください。

The post UI を魅力的にする 日付ピッカー のデザイン appeared first on Studio by UXPin.

 Facebook のマーク・ザッカーバーグ氏の“Move fast and break things!（素早く行動し、破壊せよ）“ という言葉もある通り、ラピッドプロトタイピング  によって「プロトタイプ」の制作過程がスピードアップし、デザインチームは最終デザインをより早くエンジニアリングチームにプッシュすることができます。  

完璧を求めると貴重な時間が費やされ、それによって製品チームは競争から一歩遅れてしまいますが、ラピッドプロトタイピングによって、デザインチームはデザインの主な機能とフローだけに集中でき、速やかに市場に投入することができます。  

主なポイント  

• ラピッドプロトタイピングは、製品開発の次の段階で絶対に必要な機能や画面を考慮しながら、実用的なプロトタイプを迅速に作成する方法論である。
• ラピッドプロトタイピングのプロセスにプロトタイプの作成やユーザーとのテスト、可能な限り迅速な反復があることによって、デザインは可能な限り早く開発されるようになる。
• ラピッドプロトタイプによって、ステークホルダーは、リソースを投入して製品を作る前に、製品がどのように見えるか、 UX（ユーザーエクスペリエンス）がどのようなものかをすぐに確認することができる。
• ラピッドプロトタイピングは、効率的で、速く、アクセスしやすく、ユーザーが楽しめる製品を作ることに重点が置かれている。

  UXPinの高度なプロトタイピング機能により、デザインチームは製品を迅速に構築できます。プロトタイピングでReactコンポーネントを使って、生産可能なプロトタイプを１０倍速く構築してみませんか。詳しくは UXPin Mergeをぜひご覧ください。  

 ラピッドプロトタイピング とは

ラピッドプロトタイピングは、ユーザーフローをテストして速やかにアイデアを検証するために、忠実度の高いプロトタイプを作成するプロセスであり、デザイナーがUXの最適化だけに集中して「あったらいいな」の機能や見た目に振り回されるのを防ぐべく、「スピード」を目標としています。

チームが製品を市場に投入するのが早ければ早いほど、成長と製品改良のための資金を得るための収益が生み出されますからね。

ラピッドプロトタイピングと従来のプロトタイプ

ラピッドプロトタイピングに比べ、従来のプロトタイピングプロセスでは、以下５つの段階で定義されています：

1. スケッチ：紙に大まかなスケッチを描き、ブレインストーミングを行う。
2. ワイヤーフレーム：ボックスや大まかなシェイプで骨格を作り始める。
3. モックアップ：色、タイポグラフィ、写真、その他のビジュアルデザイン要素を使って、ワイヤーフレームに詳細を注入する。
4. プロトタイプ：基本的なプロトタイプのために画面をつなぎ合わせたり、高度なプロトタイプのためにアニメーションやインタラクションを追加することで、モックアップにインタラクティブ性を追加する。
5. ハンドオフ：エンジニアリングのチームは、最終製品にするためのプロトタイプを受け取る。

ただし、Lean UXやラピッドプロトタイピングのような新しい考え方が一般化し、できるだけ早くコーディングに取りかかりたい派の人も多いことから、上記のような従来の手法は時代遅れになりつつあります。

 ラピッドプロトタイピング の利点

 ラピッドプロトタイピング の主な利点を４つざっと見てみましょう：

1. コスト削減：製品をより早く市場に投入することで、人件費が削減されると同時に、製品の早期収益化が実現する。
2. 時間の節約 ：テスト中にユーザーのペインポイントを把握できることで、変更に多大な時間とコストがかかるような開発にエラーが発生する可能性がなくなる。
3. ユーザー重視：時間が限られているため、チームはUXの最適化に集中し、「あったらいいな」のような機能に惑わされない。
4. アクセス可能：デザイナーでなくてもプロトタイプを作成してテストできる環境が作り出され、このプロセスにより、製品チームは 、（多くの場合は数回の反復を経て）デザインを製品チームに提示する UXデザイナーにアイデアを説明する必要がなくなり、時間が節約される。

 ラピッドプロトタイピング のプロセス

ラピッドプロトタイピングは独立したプロセスというより、効率化のためのフィルターであり、できるだけ質の高いフィードバックを得るために、フィードバックに基づいてサッと修正を行い、Hi-Fi（高忠実度）のプロトタイプに素早く移行します。

また、ラピッドプロトタイピングでは、明確な目標とKPIの設定が重要であり、チームは設定した目標を達成するために必要なタスクだけに集中します。

そして以下のステップは、ラピッドプロトタイピングとテストのフェーズに適用されます（デザインプロセスの初期段階はすでに完了していると仮定します）。

事前準備 – インタラクティブワイヤーフレーム

ラピッドプロトタイピングがデザインプロセスの最終段階に重点を置くのに対し、インタラクティブワイヤーフレームは初期段階のデザインにスピードと効率をもたらします。

インタラクティブなワイヤーフレームがあれば、UXチームはモックアップや忠実度の高いプロトタイプのデザインに移行する際に、大きなスタートを切ることができます。

インタラクティブワイヤーフレームに関する無料電子書籍をダウンロードして、この初期段階のデザイン戦略がラピッドプロトタイピングプロセスの最適化にどのように役立つかぜひご覧ください。

ステップ１：デザインシステムの構築

デザインシステムで、デザイナーは効率的なラピッドプロトタイピングに不可欠な要素である「スピード」と「一貫性」を維持することができます。また、デザインシステムによって、新しいデザイナーのオンボーディングは効率化され、（PayPal が Mergeで行なっているように）デザイナーでなくても製品を構築できるようになります。

UXPinでは、デザインシステムをゼロから作成したり、Google のマテリアルデザイン、Bootstrap、iOSのような広く使われているシステムを使うことができます。さらに、すぐに使えるインタラクティブな UIパターンを使って、再利用可能なコンポーネントを簡単に構築できます！

ステップ２：モックアップの作成

デザインシステムが完成すれば、モックアップの作成はドラッグ＆ドロップで簡単にできます。

ちなみに、Sketchでデザインしたい場合は、UXPinのSketchインポートを使えば、デザイナーは簡単にモックアップをアップロードして、プロトタイプやテストを始めることができます。

ステップ３ – UXPin 流インタラクションの作成

モックアップが完成したら、ユーザーフローをつなげてインタラクションを追加します。

まずはインタラクションをシンプルにしておきましょう。チームメンバーがコピー＆ペーストするだけで済むように、デザインシステムでインタラクションのガイドラインを作成するといいですね。シンプルなインタラクションで時間の節約になるだけでなく、統一性が保たれ、最終製品は見やすくて一貫性のあるものになりますからね。そしてデザイナーはいつでもインタラクションの修正をすることができます。

ここでの目標は、ユーザーがフローを完了するために重要なインタラクションだけに集中することだと覚えておいてください。UXデザイナーは、テストから正確なフィードバックを得るためにも、最終製品のように見えるプロトタイプを作らなければなりません。

UXPinを使うことで、コンポーネントや変数を作成、ステートを追加し、実際のデータを使って、忠実度の高いプロトタイプ作成して最終製品とまったく同じ外観と機能性を確かめることができます。

• コンポーネントを使うと、ボタン、アイコン、カードなどの再利用可能な要素を作成できるため、時間の節約になる。マスターコンポーネントはコンポーネントのプロパティを確定し、インスタンスコンポーネントはマスターコンポーネントの内容を反映する。マスターコンポーネントへの変更は、すべてのインスタンスコンポーネントに反映されるため、デザイナーは要素を１つ編集するだけで、フロー全体に変更を加えることができる。

• 変数を使うと、ユーザーの入力を保存し、提供されたデータに基づいてプロトタイプ内でアクションを実行できる。UXチームは、ユーザビリティテストやステークホルダーへのデモンストレーションの際に、個別化されたエクスペリエンスを提供することができる。これが、UXPinが持つラピッドプロトタイピングを促進する強力な機能である。
• 例えば、デフォルト、ホバー、アクティブ、無効など、要素やコンポーネントのステートを作成できる点は、UXPinのもう一つの強力な機能である。さらに、ドロップダウンやナビゲーションメニューのように、ステートをアクティブにしたり切り替えたりする「トリガー」を設定することもできる。
• UXPin Mergeを使うと、デザイナーは忠実度の高いプロトタイプを他のデザインツールにはないレベルで作成できる。UXPin Mergeは、コード化されたコンポーネントを使ってデザインする際に、プロトタイプの外観や機能を最終製品とまったく同じにすることができる。 − UXPin Merge については、本記事の後半で。

ステップ３：テスト、微調整、繰り返し

忠実度の高いプロトタイプが完成したら、いよいよテストです。UXPin では、ブラウザ上でプロトタイプをテストしたり、UXPin Mirror （iOS & Android）をダウンロードしてモバイルデバイスでテストすることができます。

そして UXチームは、ステークホルダーからのフィードバックやユーザビリティ調査を集め、デザインを微調整してから、テスト段階に戻って変更を検証することができます。

また、UXデザイナーは、即座にフィードバックを得てラピッドプロトタイピングプロセスをスピードアップするために、テスト中にちょっとした変更を行うかもしれません。

UXPin Merge がラピッドプロトタイピングを速める方法

従来のデザインツールは、ベクターまたはラスターグラフィックスをレンダリングします。そのグラフィックは最終製品のように見えるかもしれませんが、機能が限られているため、テストやステークホルダーからの有意義なフィードバックは得られません。

この方法で作成されたプロトタイプだと、カートに商品を追加したり、ビデオを再生したりするように、ユーザーがデータを入力したり、要素の状態をアクティブにしたりしたことを「想像」しないといけません。

UXPinはコードベースのデザインツールです。デザイナーがキャンバスに何かを描くと、UXPin は HTML/CSS/JS のコードをレンダリングします。そこでさらに一歩進んで、Git や Storybookと統合する Merge テクノロジーを導入した結果、ゼロからデザインすることなく、用意されたインタラクティブなUI要素でプロトタイプを作成できます。

UXPinのプロトタイプは最終製品のように見え、機能するため、テスト参加者やステークホルダーは、UXPinのプロトタイプを操作したときに何が起こるかを考える必要がなくなります！また、デザイナーは、JSON、Google Sheets、または CSV から実際のデータを使って、本物の製品体験をシミュレーションし、複数のシナリオをテストするために素早く変更することもできます。

さらに、UXPin Mergeは、実際のUXと有意義なフィードバックによってラピッドプロトタイピングを加速させるだけでなく、デザインからエンジニアリング、そして最終製品への移行を大幅に短縮してくれます。

PayPalのDesignOps 2.0 – UXPin Merge のサクセスストーリー

UXPin Mergeは PayPalのDesignOps 2.0の中核を成しており、プロダクトチームのメンバーがラピッドプロトタイピングを使ってPayPalの社内ツールのインターフェースを構築しています。

基本的に、UXPin MergeでPayPalの製品チームは、UI（ユーザーインターフェース）を構築し、Reactコンポーネントで忠実度の高いプロトタイプをテストするための、ノーコードのドラッグ＆ドロップツールを使用できます。さらに、PayPalのプロダクトマネージャーは、JSON、Google Sheets、または CSVから実際のデータをインポートすることで、プロトタイプに最終的な製品機能が付きます。

また、PaypalのUXデザイナーは、プロトタイプやテストのプロセスに参加する代わりに、プロダクトチームのメンターとして、必要に応じて指導やサポートを提供します。

コードコンポーネントを使うことで、PayPalのエンジニアは、ベクターやラスターベースのデザインツールを使うよりもずっと速く製品チームのプロトタイプを開発することができるのです。

UXPin Mergeによって、PayPalがたった３人のUXデザイナーで効率的なラピッドプロトタイピングを実現できるのであれば、今あなたが行なっているデザインプロセスに何をもたらせるでしょうか？ぜひUXPin Mergeのページをご覧ください。

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

The post ５分でわかる【 ラピッドプロトタイピング のプロセスと忠実度】 appeared first on Studio by UXPin.

プロトタイプ はデザインプロセスにおいて最も重要なステップの1つですが、いまだに一部のデザイナーやプロジェクトチームを悩ませています。

よくある誤解として、モックアップのことを「プロトタイプ」と呼んでいることです。また、プロトタイプは一連のスケッチでも、最終製品の機能的なレプリカでもありません。

プロトタイプ とは何か？

プロトタイプとは、最終製品のシミュレーションのことで、製品チームが実物の製造にリソースを投入する前にテストするために使用します。

プロトタイプの目的はアイデアをステークホルダーと共有し、最終的にデザインをエンジニアリングチームに渡して開発する前にアイデアをテストして検証することです。  

プロトタイプ はユーザビリティテストで参加者と共にユーザーのペインポイントを特定し、解決するために不可欠です。プロトタイプをエンドユーザーと一緒にテストすることでUXチームはデザインプロセスの中でユーザーエクスペリエンスを視覚化し、最適化することができます。

エンジニアリングにはコストがかかり、最終製品に変更を加えることはチームが予想しているほど簡単ではありません。そのため、デザインプロセス中にエラーを発見し修正することは非常に重要です。

プロトタイプには主に4つの観点における品質があります。

• 表現方法 – プロトタイプそのもの、紙やモバイル、またはHTMLとデスクトップなど。
• 精度 – プロトタイプの忠実度、ディテールのレベル（低忠実度または高忠実度）。
• インタラクティブ性 – テスト段階でユーザーが利用可能な機能（完全機能、部分機能、閲覧のみなど）。
• 進化 – プロトタイプのライフサイクル。あるものはすぐに作られテストされ捨てられ、その後改良されたバージョンと交換される（「ラピッドプロトタイピング」として知られる）。また作成と改良を繰り返し、最終的に最終製品へと進化するものもあります。

ElementorのUXディレクターによると、ウェブサイト構築プラットフォームのデザイナーは、デザインの複雑さにもよるが、平均4〜5回のプロトタイピングセッションを行うという。

ユーザーのニーズを解決するための初歩的なアイデアであっても、デザインのあらゆる可能なイテレーションをプロトタイプ化すべきです。プロトタイピングは、最終バージョンのベータテストのためだけに行うべきではありません！

プロトタイプをテストすることで、エンドユーザーが製品にどのように接するかについて新たな気づきが得られるのであれば、忠実度や方法は気にせず、時間をかけてユーザーのフィードバックを集めて反復する価値があります。

プロトタイプの種類

プロトタイプを紙、デジタル、HTMLの3つのタイプに分けてみていきましょう。

ペーパープロトタイピング

ペーパープロトタイプとは、紙やデジタルのホワイトボードに描かれたプロトタイプのことである。このようなプロトタイプは、デザイン思考のワークショップのように、デザイナーがまだアイデアを練っている初期段階で使用されます。

ペーパープロトタイピングは、デザインチームが協力して多くのコンセプトを素早く検討するデザイン初期段階で最も効果的です。チームメンバーは、シンプルな線、形、テキストを使ってアイデアを手書きでスケッチします。美学ではなく、多くのアイデアとスピードが重視されます。

UXチームは、床やテーブルの上にペーパースクリーンを並べたり、ボードに固定したりして、ユーザーフローをシミュレートする。これらのプロトタイプをテストするための一般的なやり方は、一人が「製品」を操作し、実際のユーザーの行動に従ってスケッチを切り替えることです。

ペーパープロトタイプのメリット

• 速い – プロトタイプのスケッチは数分でできます。そのため、紙はたくさんのアイデアをテストするのに適しています。ブレインストーミングの会議中であってもすぐにプロトタイプを描くことができるので、アイデアが頓挫しても数分以上は無駄になりません。
• 安価 – メーカー製のペンと紙があればプロトタイプを作ることができるので、安価で身近なものです。
• チームビルディング – ペーパープロトタイピングは共同作業であり、多くの場合、チームで楽しく新鮮なアイデアを生み出すことができます。これは素晴らしいチームビルディングのエクササイズであり、これらの自由な発想のセッションはしばしば創造性を刺激します。
• ドキュメンテーション – チームメンバーは、ペーパープロトタイプの物理的なコピー、メモ、TODOを保管し、将来のイタレーションの際に素早く参照することができます。

ペーパープロトタイプのデメリット

• 非現実的 – どんなに熟練した技術をもってしても、ペーパープロトタイプはデジタル製品を手書きで表現したものにすぎません。そのためペーパープロトタイプはすぐに描けますが、エンドユーザーとのテストではほとんど、あるいは全く結果が得られません。
• 誤検証 – ペーパープロトタイプでは、アイデアを正しく検証できないことがあります。紙の上では良いアイデアに見えても、デジタルワイヤーフレームでは効果的に機能しない場合があります。
• 本能的ではない反応 – ペーパープロトタイプはユーザーの想像力に頼っているため、刺激を見てから反応するまでに時間がかかります。UXを成功させるためには、この「本能的な」反応が重要です。

これらのメリットとデメリットを考慮すると、ペーパープロトタイピングはデザインの初期段階でのみ行うことをお勧めします。紙からデジタルに移行した後は、同じデザインやユーザーフローのために手書きのプロトタイプを再度作成する必要はありません。

ペーパープロトタイピングの詳細については、以下の参考資料をご覧ください。

• Paper Prototyping as a Usability Testing Technique （ユーザビリティテスト手法としてのペーパープロトタイピング）by Justin Mifsud
• Better Use of Paper in UX Design by Marcin Treder（紙の良い利用方法）
• iPhone User Interface Design, Paper Prototype Design （iPhoneのユーザーインターフェースデザイン、ペーパープロトタイピングのデザイン）(video)
• Printable Paper Prototyping Templates courtesy of Tripwire Magazine（印刷可能なペーパープロトタイピングのテンプレート）

デジタルプロトタイピング

デジタルプロトタイピングは、デザイン・プロセスのエキサイティングな部分です。プロトタイプは最終製品に近い形で作成されるため、チームはアイデアをテストし検証することができます。

デジタルプロトタイプには2つのタイプがあります。

• 低忠実度（Lo-Fi）：ワイヤーフレームを使用したユーザーフロー
• 高忠実度（Hi-Fi）：モックアップを使用したユーザーフロー

低忠実度のプロトタイプでは、調査チームは基本的なユーザーフローと情報アーキテクチャの概要を把握できます。高忠実度のプロトタイプでは、ユーザーインターフェース、インタラクション、およびユーザビリティテスト参加者が製品を実際に操作する方法をテストし、より詳細に検討します。

 デザイナーは、FigmaやAdobe XDなどのデザインツールを使ってプロトタイプを作成します。またデザイナーではない製品チームのメンバーが、パワーポイントやGoogleスライドを使ってユーザーフローをシミュレーションすることもあります。

UXPinの特徴として、デザイナーは、他のデザインツールでは実現できない、最終製品とまったく同じ外観と機能を持つプロトタイプを作成することができる点です。

デジタルプロトタイプのメリット

• リアルなインタラクション – ハイフィデリティのデジタルプロトタイプでテストすることにより、UXチームはユーザーが最終製品とどのようにインタラクションするかを見ることができ、ユーザビリティに関する問題を効果的に解決することができます。
• 柔軟性 – 早期にテストを行い、頻繁にテストを行うことができます。初期のプロトタイプから始めて、デザインプロセスが進むにつれ徐々に高度なものにしていくことができます。
• スピード – アイデアをテストするにはペーパープロトタイプが一番早いかもしれませんが、ユーザビリティの問題をテストするにはデジタルプロトタイプが一番早いです。製品がエンジニアリングの段階になると、変更にはかなりの時間と費用がかかります。

デジタルプロトタイプのデメリット

• 学習曲線 – プロトタイプを作成する前にソフトウェアを学び、理解する必要があります。しかし、ほとんどのデザインソフトウェアには同じツールが搭載されているため、ソフトウェアの切り替えは比較的簡単です。
• コスト – ローフィデリティからハイフィデリティのプロトタイピングへと移行するにつれ、時間と労力のコストが増加します。

プロトタイプが成功するかどうかは、チームが各ユーザビリティテストでの明確な目的とKPIを示すかどうかにかかっています。適切な計画がなければ、デザイナーは余計な機能やインタラクションを追加してしまう可能性があります。

デジタル・プロトタイプの作成に役立つリソースをいくつかご紹介します。

• A 10-Minute Rapid Prototyping Lesson by Marek Bowers（10分でできるプロトタイプの高速レッスン）

HTMLとJavaScriptのプロトタイピング

まれに、より正確な結果を得るためにHTMLとJavaScriptのプロトタイプを作成することがあります。この方法の欠点は、コーディングにかなりの時間と技術的コストがかかることです。

しかしUXPin Mergeではそのようなことはありません。

デザイナー（および非デザイナー）は、最終製品のような外観と機能を持つ、コードベースのハイフィデリティ・プロトタイプを作成することができます。

例えば、UXPin Mergeでは、チームはGitリポジトリから取り出したReactコンポーネントやStorybookコンポーネントを使用して、完全に機能する高忠実度のプロトタイプを作成することができます。UXPin Mergeではプロトタイプが最終製品のように機能するため、参加者はボタンやドロップダウンの動作を「想像」する必要がありません。

HTMLを組み込んだ低視覚・高機能のプロトタイプ。(画像提供：Mike Hill氏）

HTMLプロトタイピングのメリット

• 最終製品の機能性 – HTMLプロトタイプは、最終製品の正確なモデルを参加者に提供します。
• 最終製品の技術的基盤 – HTMLプロトタイプの構築は、研究者に貴重な研究ツールを提供し、開発者に最終製品を構築するための基盤を提供します。
• プラットフォームにとらわれない – ほぼすべてのOSやデバイスでプロトタイプをテストすることができ、ユーザーは外部のソフトウェアを実行する必要がありません。

HTMLプロトタイピングのデメリット

• デザイナーのスキルレベルに左右される – HTMLプロトタイプは、あなたのコーディング能力に依存します。コード化されていないプロトタイプは、UXデザインとは関係のないユーザビリティの問題を引き起こす可能性があります。
• 創造性の阻害 – 使えるプロトタイプを作るために、コーディングには時間と集中力が必要です。デザイナーは、使い慣れたデザインツールを使うのと同じレベルの革新性や創造性を達成できないかもしれません。

HTMLプロトタイピングに関する参考資料をご紹介します。

• Designing with Code by Andy Fitzgerald（コードでデザイン）
• The Advantage of Rapid Prototyping by ZURB（ラピッドプロトタイピングの利点）
• コードでデザインする【UXPin Merge入門】 – Robert Kirkman

プロトタイピング のプロセス

プロトタイピングに最適なプロセスというものはなく、製品や用途によって異なります。以下に、最も効果的な3つのプロトタイピング・プロセスをご紹介します。

(注：低忠実度から高忠実度に移行する際には、必ずプロトタイプをテストすることをお勧めします。)

紙⇒低忠実度デジタル⇒高忠実度デジタル⇒コード

ほとんどのデザイナーは、紙⇒低忠実度デジタル⇒高忠実度デジタル⇒コードのプロセスでプロトタイピングを行いますが、実はこれは私たちがUXPinをつくった方法でもあります。

チームで協力して多くのアイデアを練り、紙の上でワイヤーフレームをスケッチし、デジタルに落とし込む前にユーザーフローを作成します。ここでUXチームは、クレイジーエイトや「どうしたらいいか」という質問など、一般的なブレーンストーミングの手法を用いて、エンドユーザーの気持ちになって考えます。

低忠実度デジタルプロトタイプ（ワイヤーフレーム）は、デザインプロセスの早い段階で、ナビゲーションや情報アーキテクチャなどの重要な要素をテストします。モックアップに移行する前に、フィードバックをもとにワイヤーフレームを素早く調整することができます。

ナビゲーションや情報アーキテクチャが完成したら、デザイナーは、色やコンテンツ、インタラクション、アニメーションなどを追加して、最終製品に似せたモックアップを作成します。

リサーチャーによるテストが終了したら、UXチームはエンジニアにデザインを引き継ぎ、最終製品を開発します。  

紙⇒低忠実度デジタル⇒コード

低忠実度のプロトタイピングからコードに移行することは、以前からある手法ですが、最近ではほとんど使われていません。高忠実度と比較してみると、低忠実度のプロトタイピングではコストが安い反面、ユーザビリティの問題の多くを捉えることはできません。

Yelpのデザイン変更作業で作成された低忠実度のプロトタイプ。

Yelpのデザイン変更作業で作成された高忠実度のプロトタイプ。

HTML プロトタイピング => コード

一人で開発をしていると、初期のプロトタイピングの方法を省略してすぐにコードに取りかかることがあります。アイデアを出し合う相手がいない中で、開発者がいきなりコードに取り組むのは理にかなっていると言えます。

基本的にプロトタイプは基礎を作り、最終製品へと進化していきます。このプロトタイピングの方法は、効率的なワークフローを持つ熟練した開発者にのみ有効です。

優れたデザインスキルを持つデザイナーでも、このプロトタイピング方法は避けた方がいいかもしれません。低忠実度プロトタイピングと高忠実度プロトタイピングは、コードを構築・編集するよりも圧倒的に速いからです。  

紙⇒UXPin Merge – 高忠実度 プロトタイピング ⇒コード

UXPin Mergeを使用すると、ラピッドプロトタイピングによってUXプロセスを加速できます。コードコンポーネントを使用して完全に機能する高忠実度プロトタイプを作成し、最終製品の実物と同じ状態でユーザビリティテスト参加者に提供します。

UXチームは、上記で説明したような通常のペーパープロトタイピングプロセスにしたがって作業を行います。次に、デザイナーはUXPin Mergeを使用して、すぐに使用できるインタラクティブなコンポーネントをキャンバス上にドラッグ＆ドロップするだけで、忠実度の高いプロトタイプを作成します。

その結果、最終状態を「想像する」必要はなくなり、プロトタイプは最終製品と同じように機能します。UXPin Mergeが提供するコードベースのデザインツールでプロトタイプを作成することは、エンジニアがベクターベースのデザインで作業するよりもはるかに早くプロトタイプを構築できるのです。さらに詳しく知りたい方はこちらのページをご覧ください。

The post プロトタイプ とは？機能的なUXへの道 appeared first on Studio by UXPin.

新しいプロジェクトの開始時に企業が考えることの一つとして、「コンポーネントライブラリを採用するか、ゼロから始めるか 」というのがあります。メリット・デメリットの比較検討が必要であり、プロジェクトの範囲と優先順位の考慮も必要です。 その際に最も人気のあるコンポーネントライブラリの1つがMUIで、GoogleのMaterial Design UIを最初にモデル化された包括的なReact UIライブラリです。

今回はMUIについてみていきましょう、なぜMUIを使いたいのか、他のコンポーネントライブラリとの違いは何か、そして次のプロジェクトのデザインの始め方ついてお話します。 コードでデザインってどんな感じだろう、と思ったことはありませんか？

UXPin Mergeは、コードコンポーネントをレポジトリからUXPinのエディタに同期させる画期的な技術です。この強力なツールにより、デザイナーは一行のコードも書かずに、きちんと機能するコードベースのプロトタイプを作成することができます。Merge の詳細と、次のプロジェクトのためのアクセス要求方法についてご覧ください。

また、UXPinのトライアルでは、コードコンポーネントを使ったデザインがどんな感じか試すことができ、トライアル中にMUI 5キットを用意していますので、MUIを間近で体験することができます。14日間の無料トライアルに登録して、MUIをぜひご利用ください。

MUI とは

MUIは、デザイナーやデベロッパーがReactアプリケーションを構築するのに使えるUIコンポーネントの巨大なライブラリです。このオープンソースプロジェクトは、コンポーネント作成のためのGoogleのガイドラインに従っており、基礎的なUI要素と高度なUI要素のカスタマイズ可能なライブラリが備わってます。 また、MUIはReactのテンプレートやツールを販売しており、プロジェクトに合わせて微調整できる既成のユーザーインターフェースがあります。

MUI のような コンポーネントライブラリ を使う理由

デザイナーは、新製品の開発や既存プロジェクトの機能追加にUIキットを使用することがよくありますが、これらのライブラリにより、デザイナーは必要なコンポーネントをドラッグ＆ドロップして、さっとインターフェースのデザインができます。

MUIコンポーネントライブラリを使用する7つの理由を探ってみましょう。

1. 市場投入までの時間を短縮

競争の激しい今日のテク環境において、市場投入までの時間は、企業が常に最適化を求めるメトリクスとなっています。コンポーネントライブラリを利用することで、デザイナーやデベロッパーは、すぐに使える徹底的にテストされたUI要素で、大きな幸先のいいスタートを切ることができます。

デザイナーは、要素をドラッグ＆ドロップしてユーザーインターフェースを構築し、製品やブランドの要件に合わせてコンポーネントをカスタマイズすることができます。

デザインチームは、UIコンポーネントをゼロから構築してテストすることに煩わされることなく、優れたカスタマーエクスペリエンスのデザインにより多くの時間を費やすことができ、市場投入までの時間が大幅に短縮されます。

デザイナーがプロトタイプの作成、テスト、反復を速くできるため、ユーザビリティテストはずっと速くなります。テスト中にユーザーインターフェースがうまく機能しない場合は、膨大なライブラリからその場で変更を加え、参加者やステークホルダーから即座にフィードバックを得ることができます。

デザインハンドオフでは、エンジニアはコンポーネントライブラリをインストールし、プロトタイプやスタイルガイドからの変更をコピー＆ペーストすることで、ゼロから始めることなく製品を開発することができます。

2. 信頼できる唯一の情報源（Single source of truth）

信頼できる唯一の情報源（Single source of truth）の維持は、デザインシステムのガバナンスにおける最大の課題の1つです。製品チーム、UXデザイナー、およびデベロッパーが、同期していないデザインシステムを使用していることは珍しいことではなく、その結果、エラーや再作業が発生し、DesignOpsは大きな課題に頭を抱えることになります。

MUIのコンポーネントライブラリを使用することで、デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成しながら、こういった課題を大幅に減らすことができます。デザイナーとエンジニアは別々のデザインシステム（デザイナーは画像ベース、エンジニアはコードベース）を持つことになりますが、MUIは彼らに同じスタートブロックを提供します。

UXPinのコードベースエディターでMergeを使用すると、デザイナーとエンジニアは同じデザインシステムのコンポーネントを単一のレポジトリで同期して使用します。レポジトリが更新されると UXPin に同期され、デザイナーに変更点が通知されます。Reactコンポーネント ライブラリにはGitを、その他の一般的なテクノロジーにはStorybookを使用してMergeを接続できます。

3. デザインの一貫性

一貫性は、ユーザーエクスペリエンス、信頼の構築、ブランドロイヤリティには欠かせません。同じUIコンポーネントを使用することで、デザイナーは一貫性を高め、エラーや手戻りを最小限に抑えることができます。

4. 拡張性

拡張性もまた、製品デザインの重要な要素です。ゼロからデザインシステムを構築する場合、デザイナーは製品をスケールアップする前に、新しいコンポーネントのデザイン、プロトタイプの作成、テストが必要です。

MUIの包括的なUIライブラリにより、デザイナーはプロトタイプに必要なコンポーネントを検索して、すぐに拡張することができ、エンジニアは、MUIから同一のReactコンポーネントをコピー＆ペーストし、デザイナーの仕様に合わせてカスタマイズできます。

MUI Xには、データグリッド、日付ピッカー、チャート、ページネーション、フィルタリングなど、複雑な製品をより速く拡張するためにチームが使用できる高度なReactコンポーネントのライブラリが含まれています。

5. 容易なメンテナンス

MUIのようなコンポーネントライブラリには、コンポーネントのインストール、使用、更新、カスタマイズのための詳細なドキュメントが付属しています。デザイナーやエンジニアは、このフレームワークを使って企業のデザインシステムの維持ができ、ガバナンスシステムやプロトコルを簡単に確立することができます。

また、MUIには、あるバージョンから次のバージョンへの移行のためのハウツーガイドもあるので、企業はMUIがアップデートをリリースするたびに、最新のUIスタイル、テクノロジー、トレンドを利用できます。

6. アクセシビリティ

デザインシステムを設定した経験のある方は、すべてのコンポーネントがアクセシビリティ基準をクリアするのに必要な時間と費用をご存知でしょう。MUIのデザイナーは、WCAD 2.0のアクセシビリティ・ガイドラインを満たすようにコンポーネントをデザインすることに細心の注意を払い、研究者やデザイナーの負担を軽減しています。

ただし、アクセシブルなコンポーネントを用いてインターフェースをデザインする場合でも、ナビゲーションやユーザーフローをテストして、製品全体がアクセシビリティの基準を満たしていることの確認が必要であることに留意することが重要です。

7. スキルの強化

MUIのオープンソースコンポーネントUIライブラリは、スタートアップ企業や若い起業家が新製品を開発する際に、特に教育、指導、技能伝授を受けられない発展途上国において、その能力が発揮されるようにします。

また、チャリティ団体、非営利団体、NGOなど、製品やツールを開発したいがデザインシステムに投資する予算がない場合にも、このライブラリーは非常に有益です。 誰でもMUIの優秀なデザイナーやデベロッパーのスキルを活用し、フォーチュン500社で使用されているのと同じコンポーネントライブラリを使用して、洗練されたデジタル製品を開発し、グローバル市場で競争することができます。

MUIが他の コンポーネントライブラリ と異なる点

GoogleのMaterial Design UIは、間違いなく世界で最も優れた、最も包括的なデザインライブラリの1つであり、MUIは、Material Designの上に構築することで、それに匹敵するReactコンポーネントライブラリを提供します。

MUIはTheming機能で簡単にカスタマイズでき、ライブラリのドキュメントも充実しているため、多国籍企業や製品アイデアを持つ一人のデベロッパーでも製品の構築が可能です。 MUIは非常に広く使われているため、デザイナー、研究者、デベロッパーからなる大規模なグローバルコミュニティが存在し、指導やサポートを受けることができます。

Reactが最も人気のあるフロントエンドフレームワークの1つであるという事実も加わり、MUIは魅力的なコンポーネントライブラリとなっています。

興味深い事実と数字

ここでは、MUIの興味深い事実と数字をご紹介します。 注：MUIの統計は上昇を続けており、これは、2022年1月時点のものです。

• MUIは、Googleと差別化するために名称を変更することにして、2014年にMaterial UIとしてスタートしましたが、多くの人がMaterial UIはGoogleの製品だと思い込んでいるようでした。
• MUIには2,200人以上のオープンソースの貢献者がいます。
• GitHubで73,700スター以上獲得しています
• MUIが実施した2020年調査の回答者1,488人のうち、35％のデベロッパーが従業員5人以下の企業で働いていました。
• 調査では、27％のデベロッパーがエンタープライズ・アプリケーションにMUIを使用し、20％が管理者用ダッシュボードにライブラリを使用しています。

UXPinのMUI5キット

UXPin MergeのMUI統合で、UI Reactコンポーネントでプロトタイピングの力が発揮されます。 MUIは、きちんと機能するコードコンポーネントでのデザイン作成をサポートします。信頼できる唯一の情報源（Single source of truth）により、デザイナー、デベロッパー、製品チームなどは、エラーや摩擦を減らし、より効果的にコラボレーションを行うことができます。 忠実度が高いほど、参加者とステークホルダーから有意義なフィードバックを得られるような、より良いユーザビリティ・テストとなります。

その結果、全体的なユーザー体験が向上し、ビジネス価値が高まります。 UXPinのMUIキットの詳細と、この画期的なコードベースのデザイン技術へのアクセスをリクエストするための申し込み方法についてご覧ください：UXPinのMUIライブラリ：より速くデザインする。

UXPin Mergeによるコンポーネントライブラリの同期

UXPin Mergeで、Gitレポジトリ、Storybook、またはMUIからコードコンポーネントを同期し、実際のコードで完全に機能する高忠実度のプロトタイプの構築ができます。 メニュー、フォーム、タブ、データテーブル、日付ピッカー、アコーディオンなどの複雑なUIコンポーネントは、UXPinのコードベースエディタに機能が搭載されており、デザイナーは、ユーザーインターフェースの構築に必要なMUIコンポーネントをドラッグ＆ドロップします。

標準的な画像ベースのデザインツールと同じように、コンポーネントのプロパティパネルを調整することができます。 UXPin Mergeの優れた点は、デザイナーがコードベースのコンポーネントを使用してデザインするのに、新しいスキルセットを学んだり、コードの書き方を知る必要がないことです。

ワークフローは変わりませんが、プロトタイプの忠実度と機能性が大幅に向上します! デザイナーが Merge を使用せずに UXPin を使用する場合でも、ステート、Javascriptのようなインタラクション（条件付きインタラクションを含む）、変数、エクスプレッション、オートレイアウトなど、コードベースの高度な機能を利用できます。

The post MUI とは？MUIについて何を把握すべき？ appeared first on Studio by UXPin.

レスポンシブなWebサイト、モバイルフレンドリーなデザイン、アダプティブな画像は、UX（ユーザーエクスペリエンス）にとって重要です。 そのため、レイアウトを複数使用せずに、これらのような画面のサイズに合わせたプロトタイプを即応的にデザインできる機能があると時間の節約につながり、開発フローで有益となるでしょう。実はこれは、UXPin Mergeが持つ 実際のReactコンポーネントを使ってコードとデザインするという機能性によって実現可能なのです。

 Mergeが持つ機能をさっそく試してみたいという方は、ぜひこちらからアクセスしてください。認証プロセスとセットアップ完了後、すぐにレスポンシブなプロトタイピングを開始可能です。 MergeではGitを使用しているためデータの保存場所は関係なく、GitHubとの統合も必要ありません。お好きなコードベースプラットフォームをお使いください！  

 レスポンシブデザイン の問題

  最近のプロトタイピングツールの一般的な要件に、「デバイスの種類に合わせた切り替え機能」や「プロトタイプ内のコンポーネントを利用可能な範囲で自動調整できる機能」があります。これらの レスポンシブデザイン 機能は、UXPinを含むその他プロトタイピングツールのデフォルト設定では備わっていません。多くの場合で、複数のレスポンシブレイアウトを、テストしたいデバイスサイズごとに１つずつ作成するしかありません。ただ、このやり方の場合だとプロトタイプにインタラクティブ性がなく、特にモバイルデバイスやレスポンシブなサイトを日常的にデザインしていては生産性が低くなってしまいます。

例として、Material UIライブラリを使って、上記で述べた問題を説明します。下のビデオでは、Gridコンポーネントをx-smallのデバイスサイズで12 列、smallデバイスで6列になるように設計しています。しかし、このレイアウトコンポーネントとUXPinのキャンバスは関係ないので、コンポーネントでの変更はキャンバス上には反映されません。

Material UIコンポーネントは全て最初からレスポンシブですが、基本的にデフォルトでキャンバスサイズが固定されているため、UXPin Mergeはコンポーネントのメディアクエリを使えません。そのため、ページの更新やキャンバスサイズを変更しても、コンポーネントのレイアウトには反映されず、元のデザインのままとなります。

 Mergeの「 Code-to-Design 」ソリューション

  そこで UXPin Mergeの出番です。 Mergeでは実際のReactのコードを使ってデザインできます。コードでデザインすることで、ベクターベースのデザインツールのような制限に縛られることはなくなります。想像力と直感的なプログラミングを組み合わせることで、制限を越えて自由にコードを作成できます。それが Merge の魅力です。

そのため、レスポンシブなプロトタイピングでの問題を解決するには、さまざまなデバイスのサイズに対応可能なコンポーネントを作成し、キャンバスにある全てのコンポーネントのレイアウトを管理するプロトタイプの親コンポーネントとして使いましょう。本記事では、レスポンシブコンポーネントの作成方法を紹介し、コード化したデザインシステムを今日からレスポンシブにすることができます。

レスポンシブコンポーネントの作成

  まず、ラッパーとして機能する「DeviceViewer」という名前の React コンポーネントを作成します。ネストされたサイズ変更可能な IFrameコンポーネントにプロップとスタイルを渡します。コンポーネントがIFrame内にネストされると、キャンバスサイズを固定する必要なくなるため、すべてのメディアクエリ、レスポンシブプロパティ、およびスタイリングが完全に機能します。複数のページを作成することなくレスポンシブなプロトタイプをテストできるようになります。

下の画像は、DeviceViewerの簡略化された構造です。

const useStyles = makeStyles((theme) => ({···
}));
 
function DeviceViewer(props) {
 const classes = useStyles(props);
 const [frameWidth, setframeWidth] = React.useState(0);
 const [frameHeight, setframeHeight] = React.useState(0);
 const [deviceView, setdeviceView] = 
 React.useState(props.defaultView);
 
 React.useEffect(() => {···
 }, [props]); 
 
 const handleChange = (event) => {
   setdeviceView(event.target.value);
 };
 
 const setViewportDimensions = () => {···
 };
 
 const IFrameResize = () => {···
 };
 
 return (
   <div className={classes.root}>
     <Grid···
     <Box pb={3}>
       <IFrame···
     </Box>
   </div>
 );
}

お分かりかもしれませんが、これはMaterial UIライブラリを使ったReactコンポーネントのかなりシンプルなものです。スタイル、ステートメント、onChangeイベントハンドラ、HTML要素を構造化する 「return文」があります。

return文の内部には、Grid、Box、IFrameコンポーネントがあります。Gridコンポーネントは、デスクトップ、モバイル、タブレットなどの選択可能なビューポートサイズのドロップダウンリストであり、Boxは、基本的に IFrame コンポーネントを含むためのスタイリングラッパーです。

useEffect()

useEffectとデフォルトのプロップを使って、デバイスのビューサイズはステートの読み込みと更新時に変更され、その都度、ネストされたコンポーネントのプロップとスタイルが「前のIFrame」 から「新しいIFrame」 に渡されます。

if文（擬似コードで以下にあります）は、ユーザーがUXPinのエディタまたはプレビューモード（Preview）に合わせて、キャンバスに追加するスタイリングを決定します。

React.useEffect(() => {
   setdeviceView(props.defaultView);
 
   // We’ve redacted this code for readability 
   // UXPin mode change CSS handling
   if (in EDITOR mode)) {
     // remove drop-down styling
   } else if (in PREVIEW mode)) {
     // Change canvas margin properties
   }
 }, [props]);

handleChange()

IFrameを更新するときにデバイスのサイズを追跡するのに、ドロップダウンリストの値を参照する onChangeのhandleChange()関数をターゲットの値を渡します。

const handleChange = (event) => {
   setdeviceView(event.target.value);
 };

setViewportDimensions()

これらの値は、setViewportDimensionsで行ったようにハードコードすることもできますし、動的なキャンバスサイズが必要な場合はjsonとして渡すこともできます。

const setViewportDimensions = () => {
   switch (deviceView) {
     case "desktop":
       setframeWidth(1280);
       return;
     case "tablet":
       setframeWidth(768);
       setframeHeight(1024);
       return;
     case "tablet-landscape":
       setframeWidth(1024);
       setframeHeight(768);
       return;
     case "mobile":
       setframeWidth(375);
       setframeHeight(667);
       return;
     case "mobile-landscape":
       setframeWidth(667);
       setframeHeight(375);
       return;
     default:
       return;
   }
 };

ちなみにUXPinのプレビューモードで、setViewportDimensionsで設定したセレクトメニューはこのような表示となります。

IFrameResize()

IFrameResizeは、ステート読み込み時と更新時にIFrameコンポーネントから実行されます。IFrameResizeは、setViewportDimensionsを呼び出して、ステートのプロップに基づきIFrameのサイズを変更し、現在のIFrame（#target）のコピーを作成し、そのプロップとスタイルを新しいIFrameに渡します。こうすることで、新しいIFrameが読み込まれると、プロップとして渡されたコンポーネントが、新しい IFrameの寸法内に配置されます。

実際のIFrameコンポーネントとドキュメントを比較してすると、内部にネストされる子コンポーネントにデータとCSSを渡すために必要なプロップ全てが用意されており、サンドボックスタグは、Frameがキャンバス自体と通信できるようにするために追加されています。

そしてFrameContextConsumerは、jssを全て受け取り、指定された場所にcssルールを挿入し、子コンポーネントに渡します。

IFrameコンポーネントにプロパティを渡すラッパーコンポーネント（DeviceViewer）であり、ページの更新やレイアウトを直接変更することなく、子要素を更新したり変更したりすることができます。

まとめ

ここまで紹介したUXPin Mergeでのソリューションは他社のデザインツールと比較してみると、非常に画期的なアイデアであることがお分かりいただけると思います。Mergeでは、プラグインの作成または編集、APIを呼び出してデザインツールに追加機能を追加する必要はありません。代わりに、実際のReactコンポーネントで実装できるものは全てMergeで全く同じように使うことができます。これによって、デザインプロセスは促進され、レスポンシブなWebデザインにすぐに対応できる柔軟で直感的なコンポーネントを自由に作成できます。

UXPin Mergeが、提供開始当初では想像できないほど、国内外問わず多くの皆様にデザインワークフローで採用していただいており、さまざまなユースケースもいただきました。本記事で、少しでもUXPin Merge について知っていただけると幸いです。

 Merge を最大限に活用するために、ぜひこちらのUXPinのコミュニティでアイデアを共有してください！

まずは14日間の無料トライアルを始めたい方はこちらより。

The post UXPin Merge による レスポンシブデザイン appeared first on Studio by UXPin.