ノーコードやローコードのアプリケーションプラットフォーム（LCAP）は、近年さらに注目を集めてきています。ローコードの製品には、特定のニッチな分野をターゲットにしたものもあれば、広範囲のアプリケーション、ソフトウェア、ツールのコーディングを不要にするソリューションを提供するものもあります。

ローコードまたはノーコード開発のいい点は、アプリやツールの構築をより身近なものにしてくれることです。特に大きなアイデアはあるものの、資金があまりない若い起業家にとっては魅力的です。

多くのLCAPでは、ユーザーがAPIやGoogleのFirebaseのようなインフラストラクチャ・アーキテクチャと統合できるようになっており、企業は手頃な価格のアプリや既存のソフトウェアのプラグインを作ることができます。

ローコード開発は、UX調査やテストにおいても有効的です。UXデザイナーは、デザインを開発チームに渡す前に、LCAPを使って完全に機能するプロトタイプを作成し、より効率的にユーザーテストを行うことができます。このようなローコードのワークフローは、新製品や新機能をリリースする際の時間とコストを大幅に削減します。

ローコードとノーコード、その違いは？

多くの人にとって、「ローコード」と「ノーコード」は同じ意味を持つ言葉です。ノーコードと謳っている開発ツールのほとんどは、ユーザーがカスタマイズのために何らかのコード（通常はCSS）を挿入することを可能にしており、これが基本的にはローコードとなります。

最も一般的で広く受け入れられている言葉は、ローコード（Low-Code Application Platforms – LCAP）で、ローコードとノーコードの開発環境を指しています。

それでも、ローコードとノーコードには微妙な違いがいくつかあります。

ノーコードツール

ノーコードビルダーは通常、あらかじめテンプレートが用意されており、ユーザーはロゴや画像、テキストを変更することしかできません。

また、これらのノーコードツールでは、Google SheetsやAirtableのようなシンプルなデータベースに接続することもできます。技術的なスキルを持たないユーザーでも機能するアプリを構築できるため、ノーコード開発は非常に身近なものとなっています。

ローコードツール

ローコードビルダーは、テンプレートを提供するだけでなく、ページやコラムのレイアウトを編集したり、CSSやJavascriptを追加したり、APIを接続したりと、よりカスタマイズが可能です。

ローコードツールでは、GoogleのFirebaseやParse、AWS Amplifyのような、より技術的なデータベースへの接続も可能になるかもしれません。

SAPやSalesforceのような多くの企業向けアプリケーションは、企業がソフトウェアと統合するアプリを構築できるように、ローコードツールを提供しています。

ローコード開発の仕組みとは？

ローコードツールでは通常、ドラッグ＆ドロップ式のビルダーを使用して、アプリ（モバイル、デスクトップ、ウェアラブル・デバイス）やウェブサイトのページに要素を配置します。これらの要素には、テキスト、画像、ボタン、ナビゲーションなどが含まれます。これらの要素の中で、ユーザーはデータベースからデータを引き出したり、アクションやアニメーションを作成したりすることができます。

各要素は、ローコードツールがアプリやWebサイトをコンパイルする際に使用する、効果的なウィジェットです。また、ローコードツールの中には、ホスティングオプションを提供しているものもあり、ユーザーはコードのエクスポートや適切なホスティング環境の確保を気にする必要がありません。

デザインプロセスにおけるローコード

ローコードは、デザインプロセスにおいても不可欠なツールになりつつあります。まず、デザインツールが画像ベースではなくコードベースであれば、構築されたプロトタイプの挙動は最終製品に近くなり、インタラクションも非常にリアルになるという事実があります。

ローコードデザインツールのもう一つの利点は、製品チーム全体に力を与えることができることです。ローコードデザインソフトウェアを使えば、デザインの経験がほとんどないプロダクトチームでも、UXチームが作成したデザインライブラリを使って製品やインターフェースを簡単に作ることができます。

その典型的な例がUXPin Mergeです。デザイナーはMergeを使用して、準備の整ったUIコードコンポーネントをUXPinにインポートし、すぐにそれらを使ってデザインすることができます。これらの準備の整った要素は、開発者のGitリポジトリやStorybookから得られます。

製品チームは、これらのコンポーネントを使って新しい製品やユーザーインターフェースを設計することができます。何よりも優れているのは、インタラクションがすでに用意されているため、チームが作るプロトタイプは忠実度が高く、会社のすべての標準に沿ったものになるということです。

チームのメンバーはすぐに使えるコンポーネントを使うので、エンジニアリングチームは最終製品をより早く作ることができます。

PayPal DesignOps 2.0のローコードプロダクトデザイン

ローコードプロダクトデザインの素晴らしい実践例として、PayPalのDesignOps 2.0があります。UXPin Mergeを使用して、PayPalのUXデザイナーと開発者は、製品チームが作業できる60以上のコンポーネントのデザインライブラリを構築しました。

このコードベースのデザインライブラリにより、PayPal の製品チームは UX チームからの最小限のインプットで製品を作ることができます。また、エンジニアリングプロセスも格段に速くなり、開発者は製品開発作業の80％以上をUXチームの支援なしに終えることができるようになりました。

ローコード開発のメリット

ローコード開発の最も大きなメリットは、スピードとアクセシビリティです。誰でもアイデアを実用的なアプリに変えることができ、多くの場合、数時間以内に完成させることができます。

ここでは、ローコード開発のメリットについて詳しくご紹介します。

• スピード – ローコード開発では、チームや個人が迅速にアプリケーションを構築することができます。シンプルなアプリケーションでも、エンジニアが機能する製品にコード化するには数日かかります。より複雑なアプリケーションは、数週間から数ヶ月かかることもあります。
• コスト削減 – アプリやウェブサイトを構築する際、エンジニアリングは最もコストのかかるステップの一つです。セキュリティのように、専門的なエンジニアリングスキルを必要とする要素もあり、これにはコストと時間がかかります。
• 簡単なデプロイメント – ローコードツールは、多くの場合、ワンクリックでデプロイメントとホスティングを行うことができます。アプリやWebサイトのホスティングには、サーバーやホスティング環境について何も知らない場合は特に、多くの課題が伴います。
• コンセプトテスト – ローコードツールは、スタートアップ企業が新しいコンセプトやアイデアをテストするための安価な製品を作るのに最適です。概念実証に成功すれば、スタートアップ企業が重要なシードステージの資金を確保するのに役立つでしょう。既存の企業は、開発に投資する前にテストするために、新しいサービス、プラグイン、アドオンを構築するためにローコードプラットフォームを使用するかもしれません。

ローコード開発のデメリット

ローコードツールには多くのメリットがありますが、いくつかのデメリットもありますのでご紹介します。

• スケーラビリティ – ローコードツールはコンセプトの証明には優れていますが、これらのアプリはプラットフォームの限界に縛られているため、スケーラブルではありません。しかし、アプリが収益を上げるようになれば、開発者の雇用に投資し、スケーラブルなソリューションを考えることができます。
• イノベーションの制限 – ローコードツールは、イノベーションにも大きな制限があります。繰り返しになりますが、プラットフォームの枠内で作業しなければならないため、潜在的に革新的なコードやアルゴリズムを書くことができません。
• 高価なホスティング – ローコード・アプリケーションを構築するのは安くて速いのですが、ローコードツールで提供されるホスティングは、特に規模が大きくなるにつれて、通常のホスティングサービスよりも指数関数的に高価になります。
• パフォーマンス – ローコード開発がパフォーマンスに悪影響を与える要因はいくつかあります。第一に、これらのシステムは一律のソリューションを提供するため、最終的なアプリケーションには多くの冗長なコードや未使用のコードが含まれている可能性があります。第二に、ローコードホスティングサービスを利用している場合、共有ホスティング環境である可能性が高く、スピードとパフォーマンスの面で理想的ではありません。
• セキュリテイ – 機密データや消費者データを処理するアプリは、世界の一部の地域では、プライバシー法を通過するのに十分なセキュリティを備えていない可能性があります。例えば、EUのGDPRやカリフォルニア州のCCPAは、個人データの管理について非常に厳しい基準を設けています。

ローコード／ノーコードツールでは何が作れるのか？

「これがノーコードでできるの？」と驚くことがあるかもしれません。例えば、Bubbleのような有名なLCAPも、シンプルなAPIから複雑なソーシャルメディア、SaaSアプリケーション、Airbnbのような宿泊施設予約サイトなど、あらゆるものを作ることができます。

一部のLCAPプラットフォームでは、Javascriptの機能や洗練されたユーザーフローをドラッグ＆ドロップのビルダーで作成する機能を提供しています。

カスタムソフトウェアのアドオンとAPI

ローコード開発は、既存のソフトウェアと統合するためのカスタム・アドオンを必要とするビジネスに最適です。

例えば、従業員が勤務時間を記録するために会計ソフトに接続するローコードアプリを構築することができます。この種のアプリは会社にとって利益を生まないので、カスタムアプリに何万ドルも費やすことは経済的に意味がありません。

上記のシナリオでは、経理部の誰かがローコードでアプリを作り、1日で正確に動作するようにデプロイすることができます。

Zoho Creatorは、企業が現在のシステムと統合したネイティブのiOS/Androidアプリを構築することができるローコードアプリビルダーである。

SaaS製品

ローコードツールを利用して、シンプルなSaaS製品を開発するスタートアップが増えています。デザイナーやエンジニアに頼る必要がないため、コストを抑えて迅速に拡張することができます。

教育

ローコードは、教育用ツールやアプリの構築に最適なソリューションです。これらのアプリは、新しい学生の申し込みを受け付けるだけの簡単なものから、学生がビデオを見たり、宿題を提出したり、クラスメートと交流したり、コースノートをダウンロードしたり、成績表を受け取ったりできるカスタマイズされたバーチャル教室まで、さまざまなものがあります。

これらはローコードアプリケーションのほんの一例に過ぎませんが、特に必要なサービスのシステムをデジタル化しようとしている資金不足の発展途上国にとっては、その可能性は計り知れないものがあります。

ローコードは開発者を置き換えるか？

開発者の必要性は常にありますが、ローコードアプリのプラットフォームはアプリ開発の未来形とも言えるでしょう。

LCAP業界は急速に変化しており、新興企業に新たな機会をもたらし、多くの企業にレガシーシステムのアップグレードや改良を可能にしています。

デバイスの互換性のための自動アップグレードや、最新のセキュリティ要件を満たしたりするインテリジェントなLCAPを使用して、非常に複雑なエンタープライズアプリケーションが構築されるようになるのはそう遠い未来ではないでしょう。

ローコードツールの将来性

Brandessence Market Research社によると、ローコード市場は、2027年には651.5億ドル、2030年には1,870億ドル の規模になるといいます。

Salesforce、Microsoft、Appian、Oracle、Agileなどのソフトウェア大手は、すでにローコード市場に強力な足場を築いており、これらのシステムを継続的に改良して、顧客にさらなるカスタマイズを提供しています。

これらの企業は、ソフトウェアを構築するのではなく、顧客のビジネスニーズにぴったり合った独自のアプリケーションを開発するためのツールを提供することになるでしょう。

ここで重要なのは、こうしたローコードツールは、イノベーションを推進する開発者やエンジニアがいなければ存在しないということです。AIを搭載したものであっても、ローコードアプリケーションの限界に囚われることになるでしょう。

ローコードは必ずしも開発者に取って代わるものではなく、開発チームが構築するシステムやツールを変えるものです。

プロダクトチームの誰もが使えるローコードツールを使ってデザインと開発の連携を強化したいとお考えでしたら、Storybookを統合したUXPinの無料トライアルをお試しください。デジタル製品をより早く作るためのコードベースデザインツールのパワーをご体験ください。

The post ローコード ツール、ノーコードツール appeared first on Studio by UXPin.

デザイン会社のIDEOによれば、持続可能な長期的成長や成功する製品の特徴として、有用性（Desirability）、持続可能性（Viability）、実現可能性（Feasibility）が必ずあるといいます。

 デザイン思考 のプロセスでは、最も顧客の役に立つ製品や機能性を決めるために、リサーチ、つまり「デザインレビュー」を行います。このデザインレビューがうまくいけば、競合他社が解決していない問題を特定することができ、エンドユーザーとビジネスの双方に利益をもたらすでしょう。

しかし、デザインレビューは何から始めるべきでしょうか？競合における自社の強みはどうやって見つけるのでしょうか？そして、ユーザーや組織のために実行可能なビジネスモデルかはそのように判断するのでしょう？

本記事では、 デザイン思考 を概念化する段階でのリサーチと、以下３つの重要な基準を満たすアイデアを発掘する方法について見ていきます：

• 有用性（Desirability）
• 持続可能性（Viability）
• 実現可能性（Feasibility）

UXPinは、顧客に最高のユーザー体験を提供するための、高度なエンドツーエンドのデザイン、プロトタイピング、テストツールです。無料トライアルにサインアップして、UXPinでUXワークフローとデジタル製品デザインがどのように強化されるかをぜひお試しください。

デザインにおける有用性、持続可能性、実現可能性とは

有用性、持続可能性、実現可能性とは、アイデア、コンセプト、仮説を検証し、独自の価値提案（UVP （Unique Value Proposition）とも言う）があるかどうか、それを追求する価値があるかどうかを判断する デザイン思考 の方法論です。

この３つをすべてクリアしないと、リスクやコスト、失敗の可能性が高まってしまいます。有用性、持続可能性、実現可能性は、アイデアのリスク分析手法であり、イノベーションの芯の部分を見つけるためのツールキットであるとも言えるでしょう。

この方法論を適用することで、デザインコンセプトの弱点を突き止め、さらなるリサーチを重ねたり、アイデアを破棄して次のステップに進むことができるのです。

この方法論の由来

世界的なデザイン会社である IDEO は、２０００年代前半にアイデアをテストする方法として、『有用性』、『持続可能性』、『実現可能性』という デザイン思考 の手法を概念化しました。

IDEOは、最高のアイデアは、この３つの条件が満たされたときに成功すると考えました。逆を言えば、「素晴らしいアイデア」は、これら３つの基準のうち１つでも欠けているとうまくいかないことが多いのです。

では、この３つのレンズを通して、これらの３要素がどのように組み合わされているのかをみてみましょう。

有用性

デザイナーがまずチェックしないといけないのは、有用性 です。もし製品アイデアに市場価値がなく、誰もそれを欲しがらない、必要としないのであれば、それは売れませんよね。

また、有用性を調査することで、その商品が「欲しいもの」なのか「要るもの」なのかがわかります。

例えば、以下のようになります：

• 徒歩、公共交通機関、車、相乗りなどでの通勤が必要。
• 車通勤は便利で公共交通機関よりも快適かもしれないから、車通勤したい。

要るものとは、顧客にとってなくてはならないものであり、欲しい物とは、そのニーズを満たすための、より望ましい選択肢であることが多いです。どちらも「有用性」を満たすものですが、「欲しい」や「あったらいいな」よりも、「必要」という欲求を満たすものの方が、はるかに価値があります。

有用性のある製品を見つけるには、顧客を調査して、満たすことのできるペインポイント（「欲しいもの」と「必要なもの」）を特定しないといけません。

• 製品で問題が解決される人がいるか
• 競合他社は解決策を提示しているか
• もっといい考えはあるか
• そのアイデアは何がユニークなのか、なぜ競合他社ではなくそのアイデアを選ぶ人がいるのか
• その製品でエンドユーザーはどう思うか
• その製品は、使った人が誰かに話したくなるような有用性があるか
• その製品は、一度使ったら一生手放せないようなものか

有用性を調査する場合、そのアイデアをストレステストして、修正すべきギャップを見つけるという意図があります。ギャップが埋まれば埋まるほど製品は強くなり、ステークホルダーからの厳しい質問や顧客満足度にも耐えられるようになるのです。

持続可能性

持続可能性とは、その製品がビジネスとして成立しているかどうかを示すものです。たとえ世界で最も有用性のある製品があるとしても、それが高すぎたり、利益が出なかったりすれば、それは良いビジネスモデルとは言えませんからね。

本当に持続可能な製品アイデアは、短期的にも将来的にもビジネスとして意味があり、投資に対するプラスのリターンをより早く、より長く提供できるほど、デザインアイデアの持続可能性は高くなります。

持続可能性の素晴らしい例として、いかにしてコカ・コーラが１８８６年に生み出した飲料が、今でも世界で最も消費されている飲料の 1 つであり続けられるのかが挙げられます。その初期投資は、発明者に莫大な富をもたらし、１３５年以上経った今でも株主に信じられないほどの利益をもたらしていますよね。

また、持続可能性は、社会的、環境的なインパクト、つまりデザインの倫理的な側面も重要です。そのデジタル製品は、社会にとってプラスの利益をもたらしますか？例えば２０２１年に、フェイスブックの内部告発者フランシス・ハウゲン氏は、SNS 大手の内部調査で、インスタグラムが１０代の少女たちの不安や鬱、自殺願望を生み出していることを示す文書を公開しました。

Instagramは短期的には高い経済的リターンをもたらすかもしれませんが、このティーンエイジャーへの害は長期的に持続し得るものでしょうか。また、政府はFacebook や Instagram を規制するために何ができるのでしょうか？

Facebookは、社会的な論争、罰金、訴訟を克服するためのリソースを持つ巨大企業ですが、小さな会社やスタートアップ企業は、同じような圧力に直面した場合、ほとんどが折れてしまうでしょう。

そのため、持続可能性を検討する際には、事業、顧客、社会に対する価値の提供が必要であり、以下のようなことを検討してみるといいかもしれません：

• このデザインが成立するには何が必要か
• デザインを機能する製品にするには、どのような費用がかかるか
• 新製品や新機能を構築するための設備投資はあるか
• 価格モデルはどうなっているか、また、そのビジネスは利益を上げられるか
• ROI（投資対効果）が出るまでどのくらい時間がかかるか
• その製品はサステナブルか
• その製品は社会にどのような影響を与えるか

なお、持続可能性は有用性と同様に、その製品が確実に実行可能で持続可能であるようにするために、アイデアの調査、分析、ストレステストが求められます。

実現可能性

実現可能性は、現在のリソースに注目し、予測可能な将来において製品を開発する能力があるかどうかを判断します。そしてデザイナーは、その製品がビジネスにどのような影響を与えるかを考慮しないといけません。

実現可能な要因としては、以下のようなものがあります：

• 技術的な制約
• 財務上の制約
• 製品がブランディング、マーケティング、カスタマーサポートなどに与える影響
• 想定される市場投入までの時間
• 運営能力

理想的には、利用可能なリソースを用いて、会社の現在の能力の範囲内で新製品や機能をデザインしたいものです。新製品をサポートするためにインフラを構築しないといけないとなると、リスクとコストが増加しますからね。

新製品や新機能をデザインする際に考慮したい実現可能性に関する質問として、以下のようなものが挙げられます：

• 現在のデザイン体制で、新製品を開発するための部品が揃っているか
• デザイン・開発にかかる時間はどれくらいか
• 新製品の構築や拡張に十分なプロダクトデザイナー、UX デザイナー、エンジニアがいるか？
• 技術的な制約は新しいデザインに対応できるか
• 組織は新しい人材の採用が必要か
• 組織の能力を拡張する必要がある場合、それが将来の製品にどのような利益をもたらすのか
• その製品はブランドにどのような影響を与えるのか
• 製品のリリースは、マーケティング、セールス、カスタマーサポートなど、組織の他の分野に影響を与えるか？また、そのような部門はより多くの仕事をこなす能力があるか

デザインレビューにおける「有用性、持続可能性および実現可能性」の使用

組織は、「インフラ、マーケティング、販売、カスタマーサポートなどのコストを伴う開発を行う前にデザインやプロトタイプの問題点を特定する」という目的のもと、製品デザインの初期段階でデザインレビューを実施し、特定の基準に照らしてデザインを評価します。

基本的には、組織は製品デザインの有用性、持続可能性、実現可能性を知りたいと考えています。

UXデザインレビューのテンプレートのご紹介

「有用性、持続可能性、実現可能性」の デザイン思考 の方法論を適用することで、ステークホルダーに包括的かつ客観的なデザインレビューを提示するためのインサイトとデータを得ることができます。

以下は、ステークホルダーが読みやすく、理解しやすいように、デザインレビューの説明する際に使用できるストラクチャーまたはテンプレートです。

問題：問題は簡潔に述べましょう。デザインチームとビジネスチームは、この土台から共通の理解を深めていきますからね。

システム（現状）： 問題のコンテクストを理解するために、現在のシステムがどのように機能しているかを示しましょう（既存の製品であれば）。その後、あなたの提案する経験によって、システムがどのように機能するかを示すといいでしょう。

JBTD（ジョブ理論）： デザインレビューでは、何が顧客のモチベーションを高めるのかについて、共通の理解を持つことが重要です。Tony Ulwick氏はJBTDを「市場、顧客、ユーザーニーズ、競合他社、顧客セグメントを異なる角度から観察することでイノベーションをより予測しやすく、収益性の高いものにする。」であると定義しており、これによって、顧客がソリューションをどのように「採用」または「不採用」にするかの決定方法をステークホルダーが理解するために役立ちます。

事業目的： 顧客の問題解決におけるビジネス価値とROI を述べましょう。

把握すべきメトリクス： 測定しないものは改善できません。このメトリクスによって、新製品のデザインによって生み出されるビジネスと顧客の価値を定量化できるはずです。

提案された体験： 提案内容を文章でまとめ、明確で理解しやすいものにしましょう。その場にいる人たちは、その提案があなたが以前に明確にした問題とどのように関連しているのかを理解しないといけませんからね。

提案の意味合い：その提案がビジネスの他の部分にどのような影響を与えるか、もしかしたらわからないかもしれません。製品デザインの初期段階でそれを理解するのは、有用性、持続可能性、実現可能性のバランスを取るのに重要です。

基本的なエクスペリエンスデザイン： ワイヤーフレーム、モックアップ、プロトタイプ、またはMVP（最小実行可能製品）を提示して、顧客が製品をどのように望ましいと感じるかをステークホルダーがイメージできるようにしましょう。

デザインに反映されるインサイト：このデザインを選択した理由は何でしたか？インサイトや仮説などは何でしたか？いくつかの項目を箇条書きにして思考の深さを示しましょう。

新デザインに関する仮説：

• 新しいデザインについての仮説とは
• どのようにしてこの仮説にたどり着いたのか
• この仮説を、重要だと思われるメトリクスとどのように整合させることができるか

このような仮説は、明確でテスト可能なものであるべきです。明確な合格・不合格のメトリクスでテストを行うことで、この仮説は、少しずつ前進していることを測るための強力な基礎となるはずです。

チームの協調性を重視： ステークホルダーからどのような意見が必要か？デザインレビューのテンプレートのこのセクションによって、製品の成功の鍵を握るステークホルダーのために、明確なコンテクストと焦点を設定できます。

UXPinにあるデザインライブラリを使って、忠実度の高いプロトタイプやMVP を手短に構築し、デザインレビューの際にステークホルダーに提示することができます。無料トライアルにサインアップして、早速 UXPinプロトタイプ第１号を作成しましょう！

The post デザイン思考 における「有用性、持続可能性、実現可能性」とは appeared first on Studio by UXPin.

ReactJSとReact Nativeの違いを理解すると、デザイナーはエンジニアとのコミュニケーションは円滑になり、コストのかかる技術的な問題は回避され、デザイン引き継ぎ時の摩擦を最小限に抑えることができます。

デザイナーは、JavascriptやReactの基本的な違いを理解するのに、コードを学んだり技術的な詳細に踏み込む必要はありません。デザイナーに関係する最も大きな違いは、ウェブベースの製品とネイティブのモバイルアプリケーションをデザインする際のコンポーネントライブラリとその選び方です。

UXPin Mergeを使用すると、React UIコンポーネントをGitリポジトリからUXPinのデザインエディタに同期させることができるので、デザインチームは問題なく機能するコードベースのプロトタイプを作成できます。この信頼できる唯一の情報源（Single source of truth）により、デザインのズレがなくなり、市場投入までの時間が短縮され、デザイナーとデベロッパー間の結束が高まります。この画期的なテクノロジーへのアクセスに関する詳細およびリクエスト方法については、Mergeについてのページをご覧ください。

ReactJS とは

ReactJS（一般にReactと呼ばれる）は、Webベースのユーザーインターフェース構築のためのオープンソースのJavascriptライブラリです。コンポーネントベースのフロントエンドフレームワークで、バニラHTML、CSS、Javascriptを記述するよりも早く簡単にWebサイトやWebアプリケーションの開発・拡張ができます。

ReactJSでは、基本的なボタンから複雑なチャートやデータグリッドまで、再利用可能なタグやコンポーネントを作成でき、デベロッパーはコード一行でそれを呼び出すことができます。デザイナーがマスターコンポーネントを作成し、それをユーザーインターフェースの他の部分にコピー＆ペーストするのとよく似ていますね。

ReactJS の例

Facebookは、2011年に自社のWebベースの全製品のためにReactを開発し、現在もWhatsApp、Messenger、Facebook、InstagramのWeb版でこのフロントエンドフレームワークを使用しています。

Facebook以外にも、以下のような多くのグローバル企業やFortune 500社が、WebサイトやWebアプリケーションにReactを使用しています。

• Netflix
• Salesforce
• New York Times
• Reddit
• Cloudflare
• Tesla
• PayPal(PayPalがUXPin Mergeを使ってデザイン拡張させ、Reactリポジトリに同期した方法はこちら)

React Nativeとは

 React Nativeは、プラットフォームを超えたモバイルAndroidおよびiOSアプリ、ならびにWebベースのアプリケーションに使用されるReactJSのモバイル版です。ReactJSと同様に、 React Nativeは、モバイルアプリの開発・拡張のための再利用可能なコンポーネントをデベロッパーにもたらします。

技術的な大きな違いとしては、Reactは仮想DOM（Document Object Model）を使ってWebブラウザ上でコードをレンダリングするのに対し、React NativeはネイティブAPIを使ってモバイルデバイス上でUIをレンダリングする点が挙げられます。

Facebookが React Native を作った理由

 React Native 以前は、デベロッパーはApple XCodeまたはAndroid Studioを使用して、iOSとAndroid用の2つの別々のネイティブアプリケーションをそれぞれ作成しなければいけませんでしたが、今は React Native により、デベロッパーは、iOSとAndroid用のネイティブコードを自動的にレンダリングする単一のアプリケーションを開発することができます。

React Nativeの例

Facebookは、Instagram、Facebook、Facebook Ads Manager、Oculusなど、ネイティブモバイルアプリケーションに React Native を使用しています。 また、以下のように多くのグローバル企業がReact Nativeを使用しています。

• Coinbase
• Shopify
• Discord
• Skype
• Bloomberg
• Pinterest
• Baiduモバイル

 React NativeとReactJS の違い

２つの最大の違いは、ReactがJavascriptのライブラリであるのに対して、React NativeはJavascriptのフレームワークであることです。

• ライブラリとは、エンジニアがWebサイトやアプリケーションを開発しやすくするために、あらかじめ用意されたコードのことです。
• フレームワークはより複雑で、Webサイトやアプリケーションを構築するためのライブラリ、テンプレートフレームワーク、API、セッション管理などで構成されています。

その他にも、ReactJSとReact Nativeの決定的な違いは以下のようにあります；

• ReactJSはJavascriptとCSSでアニメーションを行い、React Nativeはアニメーション用のAPIを使用します。
• ReactJSはUIでHTMLをレンダリングし、React NativeはJSXをレンダリングします。
• デベロッパーは主に、Web開発にはReactJSを、モバイルアプリケーション開発にはReact Nativeを使用しています。
• ReactJSではWebページのナビゲーションにReact-routerが使われ、React NativeではNavigationライブラリが組み込まれています。

プロトタイプデザインのためのReact

ここでは、デザイナーがReactのプロジェクトに取り組む方法をいくつかご紹介します。

コンポーネントベースのデザイン手法

ReactJSやReact Nativeでは、コンポーネントベースのフレームワークを用いてUIを構築していました。デザイナーも同様に、コンポーネントベースのデザインマインドセットを使わなければいけません。自身がデザインするUIについてそれぞれ、「デベロッパーはこれをどのようにして核となるコンポーネントに分解できるのか」と自問してみましょう。

React製品をデザインする場合、コンポーネントを作成し、製品デザイン全体で一貫してこれらを再利用します。コンポーネント内でフォントサイズやスペーシングの変更は、エンジニアが新しいコンポーネントを構築したり、追加のスタイリングを記述する必要があるためなるべく避けましょう。

コンポーネントライブラリの採用

ReactJS やReact Nativeのデザインシステムをゼロから構築すると、デザインと開発の間で常に課題が発生し、ズレが生じてしまいます。そこで企業は、カスタマイズ可能なReactコンポーネントライブラリを採用することで、この課題を克服しています。

Reactコンポーネントライブラリを用いたデザインにより、デザイナーは、デザインを最終製品に変換する際にエンジニアが直面する制限や制約がわかってきます。

GoogleのMaterial Design UIをベースにしたMUIは、最もわかりやすく広く使われているコンポーネントライブラリの1つであり、デザイナーは、MUIを基盤として、ウェブサイト、ウェブアプリ、ネイティブアプリケーションのデザインシステムを構築することができます。

UXPinのMUI統合により、デザイナーはReactコンポーネントを使用してUIの構築ができます。UXPinのプロパティパネルでMUIコンポーネントをカスタマイズして、ブランドや製品の要件に対応させることができます。無料トライアルにサインアップし、UXPinでReactコンポーネントを使ったデザインを始めてください。

モーションとアニメーション

モーションとアニメーションは、特にネイティブアプリケーションの場合、デザイナーとデベロッパーの間でしばしば摩擦を起こします。ReactJSでは、エンジニアは比較的簡単にデザインアニメーションを再現できますが、 React Nativeで同じ結果を得るのは、追加のツールやパッケージがなければ困難または不可能です。このような追加には時間とコストがかかり、プロジェクトの制約を超えてしまう可能性があります。 モーションとアニメーションについては、プロジェクト開始時に必ずエンジニアと話し合い、デザインの引き継ぎ時に摩擦が生じないよう、何ができるかを判断しましょう。

ReactとUXPin Mergeでデザインする

UXPin Mergeで、デザイナーはReactコンポーネントを使用してきちんと機能するプロトタイプを構築できます。デザイナーは、他のデザインツールと同様にReactコンポーネントを使用しますが、最終製品に含まれるコンポーネントと同じであるため、忠実度と機能性が大幅に向上します。

UXPin MergeでのデザインのためにReactを理解する必要はありませんが、理解していたら、エンジニアリングチームとのコミュニケーションと連携が改善されつつ、より忠実で機能的なプロトタイプを作成できる可能性があります。

Reactのプロップ

Reactコンポーネントは、色、文字デザイン、ボーダー、シャドウなどのプロパティを確定するのにプロップを使用します。Merge はプロップを自動的に認識し、デザイナーが編集できるようにプロパティパネルが表示され、デザイナーは JSX に切り替えて、コードで表示および編集もできます。

プロップでデザイナーが変更を加えることができますが、同時にプロップは、ブランドの色や書体など、デザインシステムで確定された制約を設定するものでもあります。この制約により、一貫性が維持され、チームメンバーが不正に変更するのを防ぐことができます。

UXPinはベクターグラフィックスではなくコードをレンダリングするため、デベロッパーはデザイナーがコンポーネントのプロップに加えた変更をコピー＆ペーストするだけで、さっとUIを開発できます。

より忠実に、より機能的に

Reactコンポーネントを使ったデザインでは、デザイナーは最終製品の正確なレプリカを作ることができます。たとえば、機能する日付ピッカーを従来の画像ベースのデザインツールで作成することはできませんが、UXPin Merge を使用すると、日付ピッカー、チャート、データ テーブル、グラフなど、エンジニアがレポジトリに追加したあらゆる React コンポーネントでプロトタイプを作成できます。

定義されたインタラクション

インタラクションやアニメーションは、デザインプロジェクトに多大な時間を要し、デザイナーはプロジェクトごとにこれらのインタラクションを作り直さなければならず、エラーや矛盾が生じる可能性があります。

Mergeでは、プロダクションコードから生成された機能的およびインタラクティブな要素を使用してプロトタイプを作成でき、デザイナーは、プロップを使用して新しいインターフェースやコンポーネントに合わせてアニメーション設定の変更ができます。

デザインシステムにアニメーションを組み込むことで、デザイナーはインタラクションの矛盾をなくしつつ、プロトタイピングの時間を短縮できます。

Storybookを使ったその他のフロントエンドフレームワーク

Mergeを使うと、React でのデザインだけにとどまらず、当社の Storybook 統合により、Vue、Ember、AngularJS、Web Components などの他の一般的なフロントエンドフレームワークを同期することができます。

Reactコンポーネントと全く同じようにStorybookコンポーネントを使用して、忠実度の高いプロトタイプのデザインができます。プロップの代わりにStorybook Argsを使用して、UXPinのプロパティ、スロット、スタイル、入力などを変更します。

コードを使ったデザイン

プロトタイピングとテストの強化に向けて、きちんと機能するReactやStorybookコンポーネントを使ったデザインを始める準備はできましたか？ここでは、開始法を2つご紹介します。

1. 14日間の無料トライアルにサインアップすると、MUIのReactコンポーネントライブラリを使用してUIをデザインするためのMUI統合にアクセスできるようになります。
2. または、Mergeページで、ReactのGit統合、またはその他の一般的な技術用の Storybookへのアクセスをリクエストすることもできます。サポートチームのメンバーが、オンボーディングプロセスのお手伝いのご連絡を差し上げます。

The post React Native と ReactJS – それぞれの違い 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.

テクノロジーの世界では、常に最新のプログラムやアプリケーションを把握しておくことが重要です。サイトやアプリ、ゲームなどをいち早く提供させるために、ニーズに合った最適なコーディングを常に取り入れる必要があります。

コーディングに関わるか迷っている方は、「デザインツールはイメージベースからコードベースへ」や「コードでデザインをするとは？」の記事をぜひご覧ください。

コードに触れることなく、コードベースのインターフェースを作成しませんか。関数コンポーネントをドラッグ＆ドロップでレイアウトできるUIビルダーをぜひお試しください。製品デザインプロセスをスピードアップし、製品を他社よりも早く市場に投入できるようにしましょう。UXPin Mergeをぜひご覧ください。

コーディング とUXデザイン

コーディングとUXデザインは、それぞれに違う目的があり、異なるスキルセットが求められるソフトウェア開発における２つの異なる分野です。

コーディングには、特定のタスクや機能をどのように実行するかをコンピュータに指示する命令（コード）を記述することが含まれ、ソフトウェアアプリケーションのロジックと機能の実装に重点を置いています。

対するUXデザインは、ユーザーが製品やシステムに接する際に、ポジティブでシームレスな体験を生み出すことに重点が置かれており、ユーザーのニーズ、行動、好みを理解し、直感的でユーザーに優しいインターフェースをデザインします。

そしてコーダーは、JavaScript、Python、Javaなどのさまざまな プログラミング言語 や、フレームワーク、ライブラリ、開発ツールを使ってコードを書き、ソフトウェアアプリケーションを構築します。

UXデザイナーは、UXPinやFigmaなどのデザインツールを使って、ワイヤーフレーム、プロトタイプ、ビジュアルデザインを作成します。また、ユーザーリサーチツールやユーザビリティテストプラットフォーム、コラボレーションソフトウェアを使って、フィードバックを集めて、デザインを反復させます。

コーディングがデザインに重要な理由

コーディングは、デザインにおいて最も見過ごされがちな要素の１つですが、非常に重要な要素でもあります。

まず、コーダーとデザイナーの間に顕著な重複があるというのは腑に落ちます。結局のところ、どちらの分野も創造性、問題解決、ロジックに大きく依存していますからね、つまり、コーディングがデザインにとって重要であることはさておき、多くのデザイナーがむしろすぐに習得できるスキルでもあるということになります。

必要性という観点から、コーディングがテクノロジーに不可欠である重要な方法を２つ見ることができ、１つは、効率を上げるためにモジュール化されたコードの作成が挙げられます。これは、デザイナーが 最もコアな言語のひとつであるCSSを利用する場合です。

もうひとつは、スケーラビリティに最適である柔軟なコードの作成です。デザインプロセスを通じた小さな変更が非常に多いため、わずかな調整が行われるたびにコードを完全に書き直すようなことをしなくていいようなスイート（Suite）を作成する方法を知っておくことが重要です。

もちろん、ハンドオフやドキュメント化を難なく行うことができる UXPin のようなデザインツールもあります。１４日間ぜひ無料でお試しください。

それでは、前置きが長くなりましたが、スキルセットをデザインに適用する際にコーディング言語の構築に本当に役立つ言語について詳しく見ていきましょう。

1. Kotlin

Kotlin は JVM で使われる プログラミング言語 です。Java の代替言語として開発されたもので、Java と同様に実質的にどこでも使われます。Android アプリ（UXPin のマテリアルデザインライブラリも参照）開発が Kotlin の主な用途ですが、コードには iOS の機能もあります。Kotlin の人気は Java ほどではありませんが、Netflix、Uber、Pinterest など多くの企業で採用されています。

デベロッパーが Java ではなく Kotlinを使う理由はいくつかあり、ひとつめの理由はその利便性です。Kotlinのコードには幅広い用途があるため、経験豊富なコーダーにとっては、Java よりも Kotlin の方が生産性が高く、この効率性によって、プロジェクトの完了に必要な時間が短縮され、プロジェクトの納品コストも削減されます。

特にアプリ制作者にとっては、Kotlin の組み込みプログラムで業務がもっと楽になります。あなたが作業している間、Kotlin はバックグラウンドでバグを検索して防いでくれますし、よくあるコーディングミスを未然に防ぐアルゴリズムも含まれています。そして完成したプロジェクトはよりアクセスしやすくなり、アプリのアップデートがしやすくなるだけでなく、消費者がより安全に使えるようになります。

Kotlin コミュニティの一員であることで、利用可能なコミュニケーションがあるという特典も付いてきます。Kotlin デベロッパー専用の Slack チャンネルがあるので、質問、サポート、パートナーシップの可能性さえもあります。それに加えて、Kotlin チームは自分たちの仕事を継続的に説明するために、週または月ごとにニュースレターやビデオを出すようにしています。

2. Elm

Elm はクリエイティブな Web ブラウザベースのグラフィックインタラクションのためにデザインされたので、芸術的な創作を好む人にはピッタリであり、コーディングがどのようにデザインされるかを知るのにおすすめのプログラムです。また、Elm はフロント開発に重点を置いているのでバックエンドの編集は少し難しくなりますが、その点をあまり気にしない方にも最適です。

関数型言語である Elm は、デフォルトで無名関数、引数としての関数、部分適用に対応しており、様々な使い方ができます。また、プログラムやコードの問題を予測するためのコントロールが組み込まれており、驚くほどユーザーに優しいヒントが提供されています。

実は、Elm は扱いやすいコードの一つとして知られています。あまり予備知識を必要とせず、コーディング中に得られるあらゆるヘルプのおかげで、簡単に使うことができるので、コーディングの経験があまりない人には最適です！また、Elm はとても使いやすいので、子供でもコーディングしています。例えば Tynker は Top Coding Websites For Kids に掲載されているサイトで、Elm 言語を利用しています。幼い子供たちがこのような技術言語を使っていることに衝撃を受ける人もいるでしょうね。

3. Crystal

Crystal は、新しく改良された Ruby として開発されました。 プログラミング言語 に馴染みのない人のために説明すると、大抵の Webアプリを書くのに Ruby が使われており、非常にシンプルなコードではありますが、習得がしやすいわけではなく、処理速度が遅いため非常に時間がかかります。

シンプルなコードを維持することで、Crystal は Ruby の利便性を、より生産的で速やかな処理で実現することができました。実際にテストしたところ、Crystal には Ruby の２０倍の性能があり、３０倍高速でした。なので、Webアプリケーションに特化した場合、この言語が明確な選択肢となります。

Crystal は特定の言語を使う必要もありません。言語は型チェックされますが、特定の変数やメソッドの引数を指定する必要はありません。また、Crystal Play という素晴らしい機能もあり、これを使えば、実験を行ってから作業に関するフィードバックをすぐに得られます。

4. Swift

Swift は、iOS と MacOS アプリケーションの開発に使われる新しい言語です。Objective-C の代替言語として機能しますが、Swift の方がはるかに高速で、高いパフォーマンス能力を維持しています。

この言語は Androidドメインをカバーしていませんが、物事の全体的な計画を見ると、それでも信じられないほど便利です。 Apple の市場はすでに広範囲に広がっていて、まだ成長し続けており、Apple を通じて入手できる製品の多様性を考えると、このタイプの生産に焦点を当てることも有益です。そして現在、アプリに対応できるのは iPhoneやMacBookだけではなく、AppleTVや Apple Watchなど、その他にも多くのアプリが作成できる可能性があります。

ただし、Apple の大規模な消費者基盤が、この言語を選択する唯一の利点というわけではありません。Swift は構文がすっきりしていることから、読むのも書くのも簡単であり、コーダーの開発プロセスにおける膨大な時間とフラストレーションが抑えられます。そしておそらく、Objective-Cよりも Swift を選ぶ最大のメリットは、独立性でしょう。Objective-C は C が関与しないと進化できませんが、Swift にはこの問題がありません。

5. Java

ここでは「古いけどいい」以上の言葉が見つかりません。Javaの歴史は古いですが、今でも関数型言語のトップに君臨していおり、誰もが知っていますし、ほとんどの人が使ったことがあります。

Javaを選ぶ最大のメリットは、使い道が無限である点であり、モバイルアプリ、サーバーサイドアプリ、ビデオゲームなど、さまざまな開発に利用できます。ただそれ以上に重要なのは、何にでも実行できるという点です。Java は、その柔軟性と使いやすさから、言語領域でかなり堅い地位を維持しているのです。

主要な Web ブラウザはすべて Java に対応しており、プラグインを使う必要はありません。なので、以前に作成したアプリのメンテナンスがずっと少なくて済みます。そして言うまでもなく、Java はマルチメディアに対応しており、ほとんどの場合ユーザーに使いやすくなっています。さらに、Java は無料でアクセスでき、使うのも簡単です。なので Java は、子供向けのコーディング言語のトップに挙げられているほどです。

コードでデザインしてみよう

コーディングは何年もやっている、またはこれから始める方でも、世の中にはたくさんの言語があり、自身のニーズにぴったり合うものがあるはずです。他よりも高度なものもあれば、背景知識が必要なものもありますが、利用できるリソースはたくさんあります。

使い慣れたデザイン環境でコードベースのインターフェースを構築しませんか。UXPin Mergeを使って、最高のUIライブラリから再利用可能なコンポーネントを使って、一貫性のあるユーザーに優しいインターフェースを作成しましょう。UXPin Merge をぜひご覧ください。

The post ２０２４年に把握しておくべき プログラミング言語 appeared first on Studio by UXPin.

ダブルダイヤモンドのデザインプロセスは、問題の特定や、ソリューションの開発のために広く使われている方法論であり、この成果ベースのフレームワークは、核となる問題とエンドユーザーへの影響に焦点を当てながら、創造性と革新性を促します。

世界最先端のプロトタイピングツールで、より良い製品をユーザーに届けませんか。無料トライアルにサインアップして、UXPin によるインタラクティブなプロトタイピングをぜひお試しください。

ダブルダイアモンドとは

ダブルダイアモンドモデルは、２００３年にブリティッシュデザインカウンシルによって開発されたイノベーションとデザインのためのフレームワークです。デザインカウンシルは、どのような手法やツールを用いても、プロジェクトを実現するためのシンプルなデザインプロセスを求めていました。

デザインのフレームワークには２つのダイヤモンドが以下のようにあしらわれています：

• 問題を表すダイヤモンド
• ソリューションを示すダイヤモンド

デザイナーはこのダイヤモンドの中で仕事をし、このダイアモンドで彼らは問題を真に理解し、ソリューションを徹底的にテストすることができます。

デザイナーは、最初のダイヤモンドで核となる問題を特定すると、２番目のダイヤモンドの基礎となるデザインブリーフを作成します。２つ目のダイヤモンドでは、プロトタイプを作成し、リリース準備が整うまでソリューションをテストすることに重点が置かれます。

ダブルダイヤモンドデザインプロセスの起源

私たちがデザインフレームワークとして知っているダブルダイヤモンドは、ブリティッシュデザインカウンシルから生まれたものですが、このプロセスは、ハンガリー系アメリカ人の言語学者であるベーラ・H・バーナシー氏の「発散-収束モデル」から影響を受けています。

ベラのモデルは、最初のダイヤモンドを使って問題を広く深く探求し（発散的思考）、次に適切な集中的な行動をとる（収束的思考）というデザインフレームワークと非常によく似ています。

ダブルダイヤモンドデザインプロセスにおける４つのフェーズ

ダブルダイヤモンドのデザインプロセスは、２つのダイヤモンドと「４D」とも呼ばれる以下の４つのフェーズで構成されます：

1. 発見（Discover）
2. 確定（Define）
3. 開発（Develop）
4. 提供（Deliver）

ダイヤモンド１ – 問題の発見と定義

最初のダイヤモンドは、UXリサーチと探索に関するもので、多くの場合「問題空間」と呼ばれます。 ‐ デザイン思考プロセスの共感と確定のステージに似ていますね。

デザイナーはまず、問題とユーザーのニーズを調べることから始めますが、このフェーズには、アナリティクスや UX成果物のレビュー、エンドユーザーへのインタビュー、サービスサファリの実施、その他の初期段階のリサーチ方法が含まれる可能性があります。

第２フェーズでは、デザイナーは「発見」フェーズでのリサーチを用いて、問題とそれがユーザーに与える影響を確定しますが、デザインチームは、核となる問題にたどり着くまで、第１フェーズと第２フェーズを何度か繰り返すことがあります。そしてデザイナーが作成する UX 成果物には、以下のようなものがあります：

• ユーザーペルソナ：対象とするユーザーの架空の人物像で、その特徴やニーズを概説する。
• カスタマージャーニーマップ： タッチポイント間のユーザー体験を可視化した成果物。
• 問題ステートメント：取り組むべき具体的な問題を簡潔に表現したもの。
• 共感マップ：理解と共感を促進するために、ユーザーの思考、感情、行動を図示したもの。

第２フェーズの最後では、デザイナーはデザインブリーフを作成して、それをデザインプロセスの後半で適切なソリューションを見つけるための指針とします。

ダイヤモンド２- ソリューションの開発と提供

 ２つ目のダイヤモンドでは、適切なソリューションを見つけるためのアイデア出し、プロトタイプおよびテストを行います

開発のフェーズでは、ダブルダイヤモンドのフレームワークの中でも、チームが以下のようなさまざまなツールや手法を用いる忙しいフェーズです：

• ワークショップとブレーンストーミング：チームとして集まって、アイデア出しや仮説立て、実験の実行、可能性のあるソリューションについての話し合いを行う。
• 低忠実度（Lo-Fi）デザイン：スケッチ、ワイヤーフレーム、ペーパープロトタイプなど、デザイナーが多くのアイデアをサッと開発してテストするのに使われる、忠実度の低い（Lo-Fi）メソッド。
• 部門横断での連携：デザイナーは、エンジニア、プロダクトオーナー、その他のステークホルダーとミーティングを行い、可能性のある課題や制約に関するフィードバックを得るためにアイデアを話し合う。

開発のフェーズは、デザイナーが以下の点において最も可能性の高いソリューションを１つ特定するまで、アイデア出しやプロトタイプ、さまざまなアイデアのテストを繰り返すプロセスです：

• 問題を解決する
• ユーザーのニーズに合わせる
• 予算と技術的制約を満たす

状況によっては、デザイナーはソリューションを１つ選ぶか、いいと思うアイデアを２つ３つ選んで、提供のフェーズで忠実度の高いプロトタイプとテストを行います。まずは、１つのソリューションにたどり着くまで、うまくいかないものを排除することを目標にします。

それでデザイナーは、１つのソリューションにたどり着くと、最終的なプロトタイプを改良すべくさらにテストを行います。この一連のテストにおいて、デザイナーは、最終的な結果でデザインブリーフとステークホルダーが確実に満足できるように、ユーザビリティと UX（ユーザーエクスペリエンス）に焦点を当てます。

また、デザイナーは問題に遭遇すると、ソリューションを見つけるために開発のフェーズに戻り、ソリューションが見つかるまで反復とテストを繰り返します。

プロトタイプとテストが完了すると、デザインチームは、ドキュメント、注釈、アセット、他にもエンジニアがリリースのために最終製品を開発するのに使う指示など、デザインハンドオフに備えます。

あとは、デザインチームは UX監査と QA（品質保証）を実施し、最終リリースが確実にプロジェクトの要件、ビジネス目標、ユーザーニーズを満たしているようにする必要があります。

ダブルダイヤモンドデザインプロセスの使い方

ダブルダイアモンデザインプロセスをワークフローに活用する実践例を見ていきましょう。

第１フェーズ：発見

• ユーザーリサーチ：ターゲットユーザーへのインタビューやアンケートを実施する。
• 市場調査：競合他社や業界動向の調査
• ステークホルダーへのインタビュー：ステークホルダーからインサイトを得る。
• 共感マップ作成：共感マップを作成して、ユーザーの感情や動機を理解する。

第２フェーズ：確定

• データの統合：親和図を使ってパターンを特定する。
• 問題提起：明確で簡潔な問題ステートメントを作成する。
• ユーザージャーニーマップ：ユーザージャーニーをマッピングして、ペインポイントを特定する。
• デザインブリーフ：プロジェクトの目標と制約をまとめたブリーフを作成する。

第３フェーズ３：開発

• アイデア出し：共同ワークショップを通じてソリューションをブレインストーミングする。
• プロトタイプ：ワイヤーフレームやスケッチを作成する。
• ユーザーテスト：実際のユーザーとプロトタイプをテストする。
• イテレーション（反復）：フィードバックに基づいてデザインを改良する。

第４フェーズ：提供

• 高忠実度（Hi-Fi）プロトタイプ： 忠実度の高いモックアップでデザインの詳細を最終決定する。
• 開発：デザイナーとデベロッパーの密接な連携により、サイトを構築する。
• 品質保証：広範なテストを実施する。
• 立ち上げと監視：サイトを立ち上げ、継続的にパフォーマンスを監視し、さらなる改善を図る。

ダブルダイヤモンドデザインプロセスに従うことで、徹底したユーザー中心のアプローチで新しいサイトをきちんとデザインできることから、ユーザーのニーズを深く理解し、ソリューションを探って改良を重ね、最終製品を効果的に実装して立ち上げることによる、成功の可能性の最大化につながるのです。

UXPin でエンドツーエンドのUXデザインを試してみよう

プロトタイプとテストは、ダブルダイアモンドフレームワークなどのエンドツーエンドのデザインプロセスにおいて重要な意味があります。デザイナーは、潜在的なソリューションの徹底的なテストや正確な結果の獲得のために、高品質のプロトタイプの使わないといけません。

残念ながら、高忠実度のプロトタイプは、特定のツールでは時間がかかることがあり、ダブルダイヤモンドのデザインプロセスで多くのアイデアをテストするには理想的ではありません。

UXPin の完全インタラクティブデザインなら、デザイナーはスピードのために品質を妥協する必要はなく、最終製品のような外観と機能を備えた、忠実度の高いプロトタイプを作成できます。そしてより良いプロトタイプだと、テスト時に正確な結果がもたらされることで、デザイナーは画像ベースのデザインツールでもっと色々できるようになります。

UXPin には組み込みのデザインライブラリも標準装備されていることから、デザインチームはコンポーネントをドラッグ＆ドロップして、忠実度の高いモックアップを数分で作ることができます。数回クリックすれば、インタラクションを追加して、以下のコードのような機能を持つプロトタイプを作成できます：

• ステート：任意の要素に対して複数のステートを作成し、それぞれに個別のプロパティとインタラクションを設定できる。
• 変数：ユーザーの入力を捉えてデータに基づいたアクションを実行することで、ダイナミックで個別化された UX（ユーザーエクスペリエンス）をテスト中に作成する。
• 条件付きインタラクション: 「if-then 」と「if-else 」のルールを作成し、ユーザーのアクションや入力に対してさまざまな反応を実行する。
• Expression：フォームのバリデーション、計算コンポーネント、パスワード認証のシミュレーションなど、従来はコードでしか実行できなかった複雑な操作を実行する関数をデザインする。

どんなフレームワークでも、UXPin だとデザインプロセスを強化して、顧客により良いユーザー体験をお届けできます。無料トライアルにサインアップして、UXPin によるコードベースのデザインの可能性をぜひご体験ください。

The post ダブルダイヤモンドのデザインプロセス – 製品デザインを成功に導くおすすめのフレームワーク 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.

プロダクトのリデザインは、デジタル製品の多くの側面、特にその UX（ユーザーエクスペリエンス）、ビジュアルデザイン、技術的バグ、ビジネス価値を改善する機会です。

また、製品チームは、製品をより適切で最新のトレンドに対応させることで、製品のライフサイクルを延ばすこともできます。

UXPin Mergeのコンポーネント駆動型プロトタイプで、プロダクトリデザインの範囲を改善し、優れた結果を出しませんか。詳しくは Mergeページをぜひご覧ください。

プロダクトリデザインとは

デジタル製品の「リデザイン」とは、Web サイト、アプリ、ソフトウェア、ゲームなど、既存の製品の更新や改善のことを言います。

このようなリデザイン、変化するテクノロジー、トレンド、需要に対応し、製品の関連性と競争力を維持するのに非常に重要です。

リデザインの程度はプロジェクトの範囲によって異なり、UX の向上やユーザーニーズの変化への対応、技術的な問題への対処のために、UI（ユーザーインターフェース）、機能性、新機能に大幅な変更を加えることが含まれる場合があります。

リデザインのプロセスでは通常、現行製品の徹底的な分析、ターゲットユーザーのニーズや嗜好を理解するためのユーザーリサーチ、新しいデザインコンセプトやプロトタイプの開発が行われます。

そしてデザイナーは、最終的な製品がデザインブリーフの目標と目的を満たすようにすべく、そのプロトタイプをテストして反復しないといけません。

また、プロダクトリデザインは、デザイナーが多くのステークホルダーと協力し、過去の調査を見直し、新たな調査を行う必要があるため、複雑で時間のかかる場合が多いです。

製品をリデザインする理由

UX向上

UXの向上は、リデザインのプロジェクトの範囲に関係なく、優先されることがよくあります。

デザイナーは、製品がよりユーザーに使いやすく、効率的で、楽しめるようなものになることを目指します。

例えば、企業はWebサイトをリデザインして、より直感的でナビゲートしやすいものにするかもしれません。

技術上の問題

デザイナーは、パフォーマンスや機能に悪影響を与える技術的な問題やバグを解決するために、エンジニアと協力することがよくあります。

例えば、セキュリティ上の欠陥を修正するために、エンジニアリングチームが新しい認証システムを求めることがあります。

その際デザイナーは、リリース前に新しいログインフローをテストし、潜在的なユーザビリティの問題を特定しないといけません。

業界の新しいトレンドや需要に応える

組織は、業界のトレンドやベストプラクティスに対応するために製品をリデザインすることがよくあります。

業界のトレンドに合わせてデザインを変更したいい例として Instagram が挙げられます。同社は過去１０年間で、Snapchat に対抗した「ストーリー」 と、TikTok に対抗した「リール」の2つの大きなデザイン変更を行いました。

変化するユーザーニーズに応える

テクノロジー同様に、ユーザーのニーズも進化するので、組織は変化に合わせて製品をリデザインします。

また、ターゲットとするユーザーが変わることもよくあることで、その度に組織は新しいニーズや優先順位に合わせて製品をリデザインしないといけません。

パフォーマンスおよびスケーラビリティの向上

製品が急成長を遂げると、新しい技術やトラフィックの増加、成長に伴う使用量の増加に対応するために、製品をリデザインしないといけなくなることがよくあります。

新しいデバイスに最適化する

新しいデバイスや IoTが頻繁に市場に登場する中、デザイナーは需要に合わせて UI や機能をアップデートしないといけません。

例えば、２０２１年５月、Google は折りたたみ可能なデバイスに対応するための新しいレイアウトやコンポーネントを含むマテリアルデザイン３をリリースしました。

ビジネス目標との整合性を上げる

商品のリデザインは、多くの場合ビジネスの目標や目的に沿って行われ、その目標は、初売り、バレンタインデー、クリスマスなどの季節的なプロモーションや新製品に関連する場合があります。

例えば、ある ECブランドはが新しい製品群をリリースする予定がある場合、その製品を Web サイト上で宣伝して優先順位を付けるにはリデザインが必要になります。

ブランドアイデンティティの向上

企業は、組織のアイデンティティをよりよく反映させるため、あるいはリブランディングに合わせるために、製品のビジュアルデザインやブランディングを一新したいと思うかもしれません。

例えば、ある組織は製品のデザインを古く感じ、ブランドを現代のデザインのトレンドに合ったものにするためにデザインを変更したいと考えるかもしれません。

競争圧力への対応

組織は、競合他社に追いつき追い越すために、製品をリデザインをしないといけないことがよくあります。例えば、調査チームが、市場で提供されていない機能や特徴の需要を特定し、そこで企業は、競争上の優位性を獲得するために製品をリデザインします。

UX のための競合分析については、こちらの記事でご紹介しています。

ビジネスの成長を促進する

新たな市場への参入、新規ユーザーの獲得、既存ユーザーの維持、エンゲージメントや収益の向上など、ビジネスの成長を促進するのに、多くの場合はリデザインが必要です。

例えば、広く使われているブログプラットフォームである Ghost は、クリエイターエコノミーに焦点を当てるため、過去５年間で製品をリデザインしました。

同プラットフォームは、ブロガーや出版社といった元々の顧客層を今も惹きつけていますが、デザインの変更により、サブスクリプションベースのビジネスやクリエイターにとって好ましい選択肢となりました。

一般的な製品リデザインのプロセス

以下は、通常行われるリデザインプロセスのステップです。

１．リデザインの目標と目的を定める

目標と目的を定めることは、リデザインのプロセスを導く重要な第一歩です。

このステップでは、ステークホルダーに会い、ユーザーのニーズを考慮しながらリデザインのビジネス目標をリストアップし、優先順位をつけます。

２．現行製品の徹底的な分析を行う

次に、デザイナーは現在のデザインを、その特徴や機能性、UX やパフォーマンスに細心の注意を払いながら分析します。

この分析により、リデザイン時にデザイナーが対処しないといけない問題や課題が特定されます。

３．ユーザーリサーチを行う

ユーザーリサーチによって、デザイナーは製品のターゲットとなるユーザーのニーズ、嗜好、行動を理解することができます。

また、ユーザーリサーチの手法には、インタビュー、アンケート、ユーザーテスト、フォーカスグループ、既存製品の分析などがあります。

そしてデザイナーは、この顧客からのフィードバックをもとに、ユーザーペルソナの更新や、リデザインのプロセスの指針となる新しいペルソナの作成などを行います。

４．デザインコンセプトおよびプロトタイプを作る

デザイナーは、ステップ１から３で集めたリサーチを分析し、デザインコンセプトのアイデアを練ります。

このフェーズでは、デザイナーはデザインスプリントや迅速なコラボレーティブプロトタイピングのセッションを実施し、多くのアイデアを速やかに反復します。

ステップ４は、ユーザーの問題を解決しながら、プロジェクトの目標と目的を満たすソリューションを見つけることを目指しています。‐ 本質的にはデザインチームのバランスをとるということです。

５．テストおよび反復

デザインプロセスにおいて、テストは欠かせないものです。デザイナーは、ステークホルダーにプロトタイプを提示し、ユーザビリティテストを実施して、アイデアに対するフィードバックを得ます。

そして、プロジェクトの予算と範囲によっては、デザイナーは何度も反復を行い、コンセプトを洗練させてからハンドオフする場合もあります。

６．デザインハンドオフと開発プロセス

次に、デザイナーはデザインファイル、プロトタイプ、ドキュメントをエンジニアに渡し、最終製品を開発してもらいます。

そしてエンジニアが開発プロセスを完了すると、デザイナーは QA（品質保証）を行い、最終製品がデザインプロジェクトの仕様を満たしていることを確認します。

７．監視および保全

組織がリデザインをリリースした後、プロダクトオーナーは事前に設定したメトリクス（KPI）を通じてパフォーマンスを監視し、ユーザーからのフィードバックを集めます。

また、彼らはこのデータを使って製品を更新または改善することで、そのライフサイクルと市場での関連性が最大化されるかもしれません。

UXPin Mergeで速やかなプロダクトリデザイン

UXPin Merge は、企業がデザインシステムを UXPin のデザインエディタに同期させることができるようになる高度なコードベースの技術です。

なので、デザイナーはデザインプロセスで、エンジニアが最終製品に使うのと同じコンポーネントを使うことができます。

そしてこのコンポーネント主導のプロトタイプのワークフローにより、デザイナーは最終製品の完全に機能するレプリカを作成し、正確なユーザビリティテストや、ステークホルダーからの有意義なフィードバックを得ることができます。

製品分析のためのバージョン管理

Merge のバージョン管理で、デザインチームは古い製品のプロトタイプを作成するためにデザインシステムの以前のバージョンに切り替えることできるようになります。これによってデザイナーは既存の製品のプロトタイプを作成し、問題や改善の機会を特定することができます。

高忠実度のプロトタイプを数分で実現

製品の分析とリサーチが完了したら、デザイナーはプロトタイプを作成し、ソリューションをテストして、反復と改善を行うことができます。

その際、既存のコンポーネントライブラリを使ってプロトタイプを作成したり、UXPin のパターン機能を使って新しいプロトタイプを作成することができます。

また、このコンポーネント駆動型のプロトタイピング環境により、チームは従来のデザインワークフローよりも高い忠実度と精度で、ビルド、プロトタイプ、テスト、反復を行うことができます。

UXPin を使ったウェビナーでは、製薬会社の大手である ジョンソン・エンド・ジョンソン の UX デザイナーが、組織のデザインシステムを使って、１０分以内に UI の完全なリデザインを構築する方法を紹介しています。

The post プロダクトのリデザイン | うまくいくための工夫とヒント appeared first on Studio by UXPin.

Figmaは、美しいモックアップを作成し、他のデザイナーとリアルタイムで連携するための素晴らしいツールです。

ポートフォリオを作成し、自分のスキルをアピールするのに最適なツールのひとつですが、大規模な組織の場合だと、デザインをコードに変換するのが難しいため、Figma では不十分かもしれません。

そこで UXPin の出番です。UXPin で、デザイナーとデベロッパーはコミュニケーションを図り、デザインから開発ワークフローにコピーできる UI コンポーネントの共有ライブラリを使えるようになります。

変換は必要ありません。Figmaプラグインを連携し、UXPinにデザインを取り込んで、より強固なプロトタイピングができるようにしました。

今すぐ無料トライアルにサインアップして、最初のUXPinプロトタイプを作成しましょう！

Figma でデザイン、UXPin でプロトタイプ

わかります。Figma でのデザインっていいですよね！でもUXPinでのプロトタイプが持つ 高い忠実度や機能性もいいですよね。このように迷われている方には、UXPinのFigmaプラグインをおすすめします。「Figmaでモックアップをデザイン、プロトタイプのためにUXPinにコピーする」という両方の長所が得られます。

このワークフローには両方の長所があり、チームが製品と状況に最適なソリューションを導入することを推奨していますが、UXPinを使えば１つのツールで完結します。

UXPinはデザインおよびプロトタイピング ツールとして効果的であり、画像ベースのツールで可能な範囲を超えて UXを広げる機能を提供しています。

UXPinとFigmaでプロトタイプを作成するのが理に適っている理由

Figma、Adobe XD、Sketch などは静的なベクター グラフィックをレンダリングするため、デザイナーはコードを複製できず、複製する場合は多大な労力や回避策、追加のツールが必要になります

UXPin はコードベースのデザインツールです。これは、デザイナーがコードを扱うという意味ではなく、UXPin は HTML、CSS、JavaScript をバックグラウンドでレンダリングして、デザイナーにコードと同じ忠実性と機能を提供するということです。

そして、コードによる以下の４つの機能により、デザイナーは UXPin でより高度なプロトタイプを作成することができます。

１．ステート（状態）

UXPin のステートでは、１つのコンポーネントに対して複数のステートを作成できます。例えば、ボタンはユーザーのインタラクションによってトリガーされるさまざまなプロパティを含む複数のステートを持つことができます。

また、機能的なドロップダウンメニュー、ステッパー、カルーセル、アコーディオンなどの複雑なコンポーネントを作成することもできます。

２．インタラクション

デザイナーは、デザインツールの制限ではなく、コードに制約された複雑なUXPin のインタラクションを作成できます。また、UXPinには、没入感のあるプロトタイプ体験をデザインするためのトリガー、アクション、アニメーションも多数あります。

デザインチームは、「if-then」や「if-else」条件の条件付きインタラクションによって、ユーザーの入力やトリガーに反応する動的なプロトタイプを作成できます。

そしてデザイナーは、この Javascript のようなインタラクティブ性により、デザインの決定が UXにどのような影響を与えるかを確認し、改善すべき点を突き止めることができます。

このような現実的な相互作用により、ステークホルダーとエンジニアには、より生産的なフィードバックのプロセスやデザインハンドオフにするための説明が殆ど要らなくなります。

３．バリアブル（変数）

Figmaなどの大抵のデザインツールでは、フォームをテストするのは不可能です。なぜか？フィールドが入力ではなく画像だからです。

その点 UXPin では、フォームフィールドはまるでエンジニアが開発したかのように機能し、テキスト入力、チェックボックス、ラジオ、セレクト/ドロップダウン、複数選択、ボタンをすぐに使えます。

バリアブル（変数）を使うと、デザイナーはプロトタイプからユーザ入力をキャプチャし、アプリケーションの他の場所でそのデータを使うことができます。

例えば、サインアップ中にユーザーの情報を取得したり、個別化されたウェルカムメッセージを作成するために名前フィールドを使ったりできます。

４．Expression

UXPin の Expressionで、他のデザインツールの可能性をはるかに超えるプロトタイプが実現します。

パスワードやその他のフォームフィールドの検証、ユーザーの操作に基づいて更新されるショッピング カートのデザイン、動的なエラー メッセージの作成などができます。

そしてデザイナーは、ステート、インタラクション、バリアブルなどの他の UXPin機能が組み合わさると、 Expressionによって、プロトタイプや、コードと見分けがつかないユーザーフローを構築できるようになります。

このような機能やその他の高度な UXPin機能についての詳細は、UXデザインのインフルエンサーであるジェシー・ショウォルター氏によるYouTube のチュートリアルでぜひご覧ください。

Figmaのモックアップをインタラクティブな UXPinプロトタイプにする５つの理由

１．高忠実度（Hi-Fi）プロトタイプ

• Figma：美しく見えるベクター・モックアップであるが、実際の機能性や忠実さは再現されないため、デベロッパーやステークホルダーにとってはプロトタイプの解釈が大変になる。
• UXPin：コードのような忠実性と機能により、デザイナーは最終製品と区別できない没入型の動的なプロトタイプの体験を作成できる。‐ つまり、ドキュメントが要らなくなり、デザインハンドオフがスムーズになり、市場投入までの時間が短縮される。

Figma、Sketch、Adobe XD などが作成するものである、忠実度の高いモックアップと、見た目も感触も最終製品と同じ高忠実度のプロトタイプとの間には大きな違いがあります。

UXPin だと、プロトタイプがコードのようにユーザーのインタラクションに応答するため、プロトタイプの説明がほとんどまたはまったく必要ない、真の高忠実度の結果がもたらされます。

２．UI デザインと本当のプロトタイプのギャップを埋める

• Figma：Figma で UI デザインのアイデアをデザインおよび開発する。
• UXPin：Figma の限界を超え、UXPin で高度なプロトタイプを作成する。

Figma には、美しいデザインやモックアップを作成するための機能が備わっていますが、デザイナーはプロトタイプの段階で壁にぶつかってしまいます。

そこで UXPin の Figmaプラグインで、デザインチームは UXPin で忠実度の高いプロトタイプを作成するのに、両方のツールの長所を活用することができます。

UXPinでUIデザインの変更と反復を行うか、デザインと編集にFigmaを使って、プロトタイピングツールとしてのみ使うのかは、お任せします！

３．ユーザーテストの強化

• Figma：テストは基本的なクリック／タップのインタラクション、ユーザーフロー、ナビゲーションに限定される。
• UXPin：最終製品を正確に再現する没入型プロトタイプ

Figma のベクターベースの制約と限界は、正確なテストの妨げになります。デザイナーは、は基本的な対話性を実現するために複数のフレームを使わなければならず、多くのコンポーネントは再現できません。

一方、コードベースのデザインツールである UXPin を使うと、デザイナーはコードを１行も書くことなく、デベロッパーが構築できるものの実現可能性がある制限されたプロトタイプを構築できます。このような複雑で動的なプロトタイプで、UXは向上し、デザインチームはビジネスチャンスを特定するための貴重なインサイト得られます。

また、デザイナーは、UXPin プロトタイプを使ってテストするときに、重要なユーザビリティとアクセシビリティの問題も正確に指摘することから、それで UX負債が減り、より高品質なデザインプロジェクトの成果が得られます。

４．より速い反復（イテレーション）

• Figma：最終製品の動作を模倣するための複数のフレームとコンポーネント – 変更や再デザインは時間を食う。
• UXPin：レイヤーとステートを１つの画面で使い、数回のクリックで変更が可能。

Figma でのプロトタイプの課題の１つに、デザイナーが、コードのインタラクティブ性を模倣するのに複数のフレームやコンポーネントを作成しないといけないという点があります。またそのインタラクションは、ぎこちなく、直感的ではない上に、デザインや変更には時間がかかります。

UXPin では、デザイナーは「ページ」と「レイヤー」で作業します。複数のフレームやページを切り替える代わりに、１つのキャンバス上で作業し、プロパティパネルで変更を加えます。

また、このワークフローは、より直感的で、より速い反復を促進することから、デザイナーはより速く問題を解決することができます。

５．より円滑なデザインハンドオフ

• Figma：多くのドキュメント、デベロッパーとのやり取り、インタラクションを模倣したビデオ/GIF、他のツールへのリンク。
• UXPin：プロトタイプは最終製品のエクスペリエンスとインタラクティブ性を再現し、それによって長いドキュメントや追加ツールの必要性が軽減される。

デザイナーは、After Effectsなどのツールを使ってモーションやインタラクションを再現することが多いです。なぜか？デザインツールには忠実さと機能性がないからです。また、デザイナーは技術的な制約のためにエンジニアが再現できないトランジションやインタラクションを作成しますが、その際に複数のツールやファイルを切り替えるのは、混乱を招き、時間がかかり、エラーが増えます。

UXPin を使えば、コードを正確に模倣したコンポーネントやインタラクションをデザインできるので、デザイナーは追加のツールを使う必要がありません。また、プロトタイプが何をするものかを説明するためのビデオや GIF、行ったり来たりのやり取り、長ったらしい PDF は必要ありません。

そして、デザイナーは UXPin でプロトタイプに注釈を加えたドキュメントを作成できるため、エンジニアやステークホルダーは複数のファイルを切り替える必要はありません ‐ すべて一箇所に集約されています！それでデベロッパーやステークホルダーは、UXPinのプレビュー上のコメント機能を使って、質問したり、チームメンバーをタグ付けしたり、編集用のコメントを割り当てることができます。

現実的なプロトタイプやサポート用ドキュメント、連携が一箇所にあるため、デザインハンドオフがよりスムーズになってより摩擦が少ないものになります。

UXPin – エンドツーエンドのデザインソリューション

Figma でデザインし、UXPin でプロトタイプを作成することはできますが、それは、ツールが１つしか要らないのに２つ使うということになります！

UXPinの場合、コラボレーション、ワイヤーフレーム作成、情報アーキテクチャデザイン、モックアップ、ゼロからのコンポーネントデザインなど、Figmaと同等のデザイン体験を得られます！

UXPin のエンドツーエンドのデザインソリューションでは、デザインシステムの構築、管理、共有など、UXPin 内ですべて行うことができるため、デザイナーはツールを切り替える必要がありません。

そして使うツールが減ると、UX ワークフローが効率化されるだけでなく、コストが削減され、デザインリーダーは貴重なリソースを他に当てることができるようになります。

また、ステークホルダーに画像ベースのプロトタイプとそれに付随するドキュメントを読み解く時間や忍耐力がほとんどなくても、UXPin のプロトタイプは説明が少なくて済むため、ステークホルダーは最終的な製品体験を楽しむことができます。

そしてこの没入型体験は、デザインソリューションへの賛同を高めながら、ステークホルダーから有意義なフィードバックを引き出してくれます。

画像ベースのデザインの制限に別れを告げ、UXPinを使ってプロトタイプ、連携、デザインの成果上げませんか。

無料トライアルにサインアップして、UXPin がどのように製品デザインのワークフローに革命を起こして優れたUXを提供できるかをぜひご覧ください。

The post Figmaのデザイン をインタラクティブなプロトタイプに変える appeared first on Studio by UXPin.

ソフトウェアや Web開発には、初期コンセプトからデザイン、納品、QA、ライフサイクル管理まで、多くの役割と責任があります。UIデザインと UI開発 には、ユーザーがどのように UI（ユーザーインターフェース）と関わり対話をするかに影響を与える重要な役割があります。

そこで本記事では、UIデザインと  UI開発 の内容、これらの役割を支える人々、そしてデジタル製品を提供するためにどのように協力しているかを比較していきます。

主なポイント：

• UIデザインは製品のUI（ユーザーインターフェース）をデザインするプロセスであり、UI開発はそのデザインをプログラミングするプロセスである。
• UI デザインと UI開発は、ソフトウェア開発プロセスの対極にある。
• UIデザイナーとUIデベロッパーは、有用で、持続可能で、実現可能な製品を作るために協力する。

サクッと開発できるUIデザインを構築しませんか。UXPinのデザインエディターでReact、Storybook、npmのコンポーネントを使って、素早く制作できるプロトタイプを作成しましょう。詳しくは UXPin Mergeのページをぜひご覧ください。

UIデザインとは

UIデザインとは、UIの要素、レイアウト、インタラクション（ユーザーが見て、操作するもの全て）をデザインするプロセスのことをいいます。その要素には、画像、アニメーション、スライダー、テキストフィールド、ボタンなどが含まれます。また、UX（ユーザーエクスペリエンス）デザインと同様に、ユーザーのニーズとテストに基づいて決められます。

UIデザインで行うこと

UIデザイナーは、ユーザーが操作するデジタル製品やアプリケーションの視覚的要素をデザインする役割を担っており、全体的なUXの向上だけでなく、与えられたUI内でどのようなアクションが可能であるかを伝える、ユーザーに優しく見た目的にも美しいインターフェースを作成することに主に焦点を当てています。（例：ボタンのクリックやホームページへの移動、文字入力など）

UI デザイナーのスキルと責任

UIデザイナーは、UIデザインプロセスの責任者であり、その役割には以下が含まれます：

• 製品の美観：ブランディング、ビジュアルデザイン
• リサーチ：使用状況やユーザーの把握
• テスト：ユーザーにとってわかりやすいデザインであることの確認
• デザイン：プロトタイプ、モックアップ、インタラクションデザイン、アニメーション、ビューポートレイアウト（レスポンシブデザイン）の作成

UIデザイナーに求められる資質およびスキルセット

• ビジュアル面での創造性
• Webデザイン
• グラフィックデザイン
• デザイン原理およびデザイン思考
• ビジュアルデザインへの興味
• ユーザージャーニーとペルソナ
• ユーザーリサーチ
• タイポグラフィ
• 形と機能のバランス
• ユーザーのインタラクションと行動への注目
• タスク指向

UIデザインプロセスとは

UIデザイナーは、他のUX担当と同じデザイン思考プロセスに従いますが、フレームワークの中では以下のようにさまざまなことを行います：

• 共感：ユーザーの環境、動き、行動に焦点を当てる。
• 定義：ユーザーが目標を達成するために必要な各ステップに焦点を当てる。
• アイデア出し：ユーザーが製品をナビゲートするために必要な要素やコンポーネントについて見る。
• プロトタイプ：忠実度の高いプロトタイプのためのモックアップとインタラクティビティをデザインする。
• テスト：ユーザーがどのように製品を操作するかをテストし、実用的な質問をする。

さらに読む：UX デザイン vs UI デザイン その違いを把握しよう

UIデザイナーが使うソフトウェア

UIデザイナーは一般的に、他のUXデザイナーと同じデザインツールやソフトウェアを使い、そのツールで、UIのデザイン、プロトタイプ作成、テストを行います。

UIデザイナーは、最終製品のように見え、機能する忠実度の高いプロトタイプを作成することを目標としています。UXPinのようなコードベースのデザインツールで、UIデザイナーがデジタル製品のプロトタイプを作成し、テストする方法に革命をもたらしました。

UXPinの高度なプロトタイピング機能には以下のようなものがあります：

• ステート（状態）：１つのコンポーネントに対して、相互作用とシステム変更のための個別のプロパティを持つ複数のステートを作成する。
• 条件付きインタラクション：ユーザーやシステムのアクションに反応する Javascript のような「if-then」や「if-else」ルールで、動的なユーザー体験を作り出す。
• Variables（変数）： 例えば、ユーザーの名前入力からカスタマイズされたウェルカムメッセージを表示するなど、ユーザーの入力を保存し、そのデータに基づいてアクションを実行する。
• Expression：Javascriptのような関数を書いて、フォームのバリデーションや計算フォーマットなどの複雑なタスクを実行する。

１４日間の無料トライアルで、UXPin のこれらの機能やより高度な機能をぜひお試しください！

 UI開発 とは

UI開発 とは、クライアント向けのインターフェースをプログラミングするプロセスであり、UIデザイン同様に、UI 開発のプロセスには、画像、アニメーション、スライダー、テキストフィールド、ボタンなどのコードを書くことが含まれます。

UI デベロッパーとは

UIデベロッパーは、Web サイトやアプリケーションのビジュアルデザインの実装を担当します。UIデザイナーはインターフェースの全体的な LnF（ルック＆フィール）の作成に重点を置きますが、UI デベロッパーはインターフェースが Web上またはアプリケーション内で機能するようにコードを記述することで、そのデザインに動きなどを加えます。

UIデベロッパーのスキルおよび業務

製品や組織の構造によっては、UI開発の役割はフロントエンドデベロッパー、UXエンジニア、またはフルスタックエンジニアが担う可能性があります。その責務はエンジニアリングチームの構成によって異なりますが、以下のようなものがあります：

• UIコンポーネント開発
• UIメンテナンス
• スタイリングアーキテクチャ
• 実装
• 技術面での実現可能性
• バックログ管理
• パフォーマンス
• クエリのアーキテクチャ
• 検索エンジンの最適化

フロントエンド開発とバックエンド開発の違い

エンジニアは、プログラミングを以下のように「フロントエンド開発」と「バックエンド開発」の２つの分野に分けています。

• フロントエンド開発：HTML、CSS、Javascript を使った「クライアント向け」のインターフェースの開発に重点を置く。
• バックエンド開発： フロントエンドのインターフェースをデータベース、API、認証などに接続するためのサーバーサイドのコードを書き、プログラミング言語には、Java、Ruby、Python、Javascript などがある。

さらに読む（英語）：Front-End vs. Back-End: What’s the Difference?（フロントエンドとバックエンド： その違いとは？）

UI デベロッパーが使うソフトウェア

他のエンジニアと同じように、UI デベロッパーは IDE（統合開発環境）を使ってコードを調べたり書いたりします。また、最近の IDE には、Git、パッケージマネージャー、レポジトリ、API などのようなエンジニアリングツールとのインターフェースのための様々な拡張機能が備わっています。

さらに読む（英語）：The 7 Essential Tools for Frontend Web Development.（フロントエンド Web 開発に欠かせない７つのツール）

UIデザインと UI開発 

UIデザインと UI開発が定義されたことで、その分野がソフトウェア開発プロセスの対極にあることが明らかになりました。UI デザインはデザインプロセスで行われ、UI 開発はエンジニアリングプロセスで行われます。

UI デザイナーと UI エンジニアは別々の分野ですが、最終製品を成功させるために協力しないといけません。

また、UIデザイナーと UIエンジニアの役割がどんな組織にもあるわけではない点に注意することが重要です。

以下に、UI の役割と責任を果たす可能性のある職種を挙げてみましょう：

• UIデザイン：UX エンジニア、ビジュアルデザイナー、グラフィックデザイナー
• UI開発：フロントエンドデベロッパー、UXエンジニア/UX デベロッパー、フルスタックエンジニア

UIデザイナーと UIデベロッパーの協力体制

ここでは、UI デザイナーと UI デベロッパーがプロジェクトでどのように連携するかを示す一般的なワークフローを見てみましょう：

• UIデザイナーは、ユーザー、競合、市場、製品などを理解するために、様々な形の UX 調査からデザインプロジェクトを始めて、ユーザーの視点から問題を理解するために、ユーザー中心のデザイン（UCD）プロセスを用いる。
• UIデザイナーは、デザインプロセスの早い段階で UIデベロッパーとミーティングを行い、技術的な制限、デザインハンドオフの手順、ドキュメントの要件について話し合う。
• UIデザイナーは、他の UX デザイナーと協力して、UI、レイアウト、コンポーネントのデザイン、プロトタイプ作成、テストを行い、UI デベロッパーは、場合によってはデザインチームと協力して、複雑な UI コンポーネントをテストするための基本的なコードプロトタイプを構築することもある。
• デザインプロセスが完了すると、UI デザイナーはデザインのハンドオフのためにプロトタイプとドキュメントを準備する。
• UIデザイナーと UI デベロッパーは、デザインについて話し合い、デザインのハンドオフプロセスでエンジニアがすべてを正しく理解していることを確認するために会う場合もある。
• UIデベロッパーは、他のエンジニアリングチームと協力して、デザインを機能するコードに変換する。
• UIデザイナーは、デザインチームやプロダクトチームと協力し、最終リリースがデザイン仕様を満たしていることを確認する QA（品質保証）プロセスを完了する。

UIデザイナーと UIデベロッパーの連携の重要性

現代のソフトウェア開発は、卓越したUIデザインと開発に依存しています。

デザイナーは、製品がユーザーのニーズを満たしていることを確認し、UIとUIコンポーネントを徹底的にテストして、ユーザビリティとアクセシビリティの基準を満たしていることを確認します。

このプロトタイプとテストの段階がないと、ユーザビリティの問題が製品に影響を及ぼし、その結果、UXが落ち、顧客サービスや手直し、顧客喪失など、回避できるはずのコストがさまざまな面で発生してしまいます。

UIデベロッパーは、ソフトウェアのリリースを成功させるためにも重要な役割を果たします。最終的な UI がデザイン仕様を満たしていることを確認し、バグやパフォーマンスがないかコードをテストしないといけませんし、製品が長期にわたって完全性と一貫性を維持できるように、パッケージ、API、セキュリティなどのアップデートを含むコードの管理も担当します。

これを実現するには、デザイナーとエンジニアがソフトウェア開発プロセスを通じて協力し合うことが理想ですが、一般的な大規模組織ではサイロ化やコミュニケーション不足が問題になるかもしれません。

その際、多くの場合ではUIデザイナーと UIデベロッパーはDesignOpsやDevOpsを取り組むことで、部門間のギャップを埋めて、運用プロセスと連携を改善します。

UXPin Mergeでデザイナーとデベロッパーの連携を改善

ドリフト（摩擦）の課題

デザイナーとエンジニアが直面する課題のひとつに、以下のように「話す言語が違う」という点があります。

• デザイナー = 画像ベースの静的モックアップとプロトタイプ
• エンジニア = コード、ブラウザ、OS、データベースなど

お互いの専門分野について深い知識と経験がなければ、デザイナーとプログラマーが相手の限界や制約、その他の課題を理解するのは難しく、そのギャップを埋めるのは、組織が製品を時間通りで予算通りに成功裏に納品するために極めて重要です。

コードベースのソリューション

UXPin Mergeは、コードベースのデザインソリューションにより従来の UXワークフローに革命をもたらします。組織はレポジトリからコンポーネントライブラリをUXPinエディタに同期できるようになるので、デザイナーは完全に機能する UI要素とコンポーネントを使ってプロトタイプを構築できます。

Merge コンポーネントは、インタラクティブ性などのレポジトリ内のコンポーネントとまったく同じプロパティを保持するため、デザイナーはドラッグ＆ドロップするだけで UI を構築できます。

また、デザイナーが JSX や UXPin のプロパティパネルでコンポーネントをカスタマイズできるように、エンジニアはReact や Storybook の Args などのさまざまなプロップを設定できます。プロップに変更を加えるとJSX がレンダリングされ、エンジニアはコピー＆ペーストして開発を開始することができます。

そしてこのMergeを活用したワークフローは、UIデザイナーとUI ベロッパーが同じ言語を同じ制約で話しているため、連携と理解がより高まります。組織のコンポーネントライブラリにとって本当の「信頼できる唯一の情報源」ということです。

UXPinはまた、コード化されたコンポーネントのインポートと管理におけるデベロッパーの関与を軽減するツールである Merge Component Managerを提供しています。エンジニアへの依存が軽減されるということは、デザイナーがMergeをより速く立ち上げて実行できるということです。

「以前はデザインだけで２～３ヶ月かかっていましたが、今では、UXPin Mergeを使うことで、チームは同じ時間枠で製品をデザイン、テスト、納品することができます。「市場投入までの時間の短縮」は、UXPin Mergeを使って経験した最も大きな変化の一つです。」 エリカ ライダー（Paypal 社）‐ UX リード EPX 

UXPin Mergeのテクノロジーがデザインプロセスにどのような革命をもたらすかをぜひご覧ください。アクセスのリクエストはコチラから。

The post UI デザインと UI開発 の違い 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.

UX デザインフレームワークは、ユーザー中心で、一貫性があり、効率的なデジタル体験を生み出すための貴重なツールです。万能のソリューションではなく、さまざまなプロジェクトに適応できる柔軟なガイドラインです。

多くの組織やスタートアップ企業は、プロジェクトを成功させるために１つもしくはそれ以上の UX デザインフレームワークを採用しており、デザインチームはそのフレームワークを用いて意思決定を行い、問題を解決します。

主なポイント：

• UX デザインフレームワークとは、一貫性のあるユーザーに優しいデジタル製品、Web サイト、アプリケーションを作成するために、デザイナーが従う構造化されたアプローチのことである。
• UX デザインフレームワークでまとまりのある楽しい UX（ユーザーエクスペリエンス）が確保されながら、デザイナーは十分な情報に基づいたデザインの決定を下すことができる。
• デザインフレームワークで、リーンUX やダブルダイアモンドのようなプロジェクトの遂行ができるようになったり、フォッグ行動モデルやフックモデルを適用して特定の機能の成果を達成したりすることができる。

世界最先端のコードベースのデザインおよびプロトタイピングツールである UXPin を使って、製品開発プロセス全体のデザイン課題を解決しませんか。無料トライアルにサインアップして、UXPin の全機能をぜひお試しください。

デザインフレームワークとは

デザインフレームワークとは、デザインプロジェクトのためのツール、ワークフロー、プロトコル、プロセスのセットであり、それでチームは、問題の解決やプロジェクトの遂行のための体系的なアプローチを得られます。

デザインフレームワークは、新入社員のオンボーディングや責任の引継ぎに有用であり、新しいチームメンバーは、慣れ親しんだ、構造化されたプロセスに従うことで、自分がデザインプロセスのどの位置にいて、どのようにプロジェクトを完成させるべきかを知ることができます。

また、複数の部門横断的なチームが同じ製品に取り組む大規模な組織では、デザインフレームワークを使うことで、チームの連絡や連携が確保され、ワークフローや遂行において最高の品質と一貫性を維持することができます。

デザインフレームワークは、全員に特定の考え方や作業方法を強制するのではなく、チームを導くものであり、チームメンバーに何をすべきかを指示する代わりに、ソリューションを見出すための体系的な道筋を提供するものなのです。

デザインフレームワークが必要な理由

デザインフレームワークを使う主な利点には、以下のようなものがあります：

• 一貫性： プロジェクトのさまざまな部分にわたって、統一された認識可能なデザインを確保する。
• 効率： 確立された作業パターンを提供することで時間の節約になる。
• ユーザー中心主義： ユーザーのニーズと期待を優先し、より良い製品を生み出す。
• コラボレーション： デザインチーム、デベロッパー、ステークホルダー間のコミュニケーションを促す。
• 生産性： チームは計画的かつ一貫してプロジェクトを遂行できる。

UX デザインのフレームワーク９例

UX デザインのフレームワークは、デザインプロセスと製品開発に構造を提供しますが、以下のように、デザインチームが達成したい結果に応じて使うフレームワークがあります。

１．UCD（ユーザー中心デザイン）

出典：Interaction Design Foundation

UCD（ユーザー中心デザイン）は、エンドユーザーのニーズ、嗜好、行動をデザインプロセスの最前線に置くUX デザインのフレームワークであり、それを使う人にとって直感的で、効率的で、楽しい製品、サービス、システムを作ることを大前提としています。

ユーザー中心デザインの主要な原則と側面には、以下のようなものがあります：

• ユーザーへの共感： デザインプロセスは、ユーザーを深く理解することから始まる。デザイナーは、ユーザーのニーズや目標、ペインポイント、行動におけるインサイトを得るべくユーザーリサーチを実施する。
• ユーザビリティの重視： ユーザビリティは UCD の重要な側面であり、デザイナーは、製品を学びやすく、使いやすくし、ユーザーのエラーやフラストレーションを最小限に抑えることを目指す。そしてそれには、明確なナビゲーション作成などが含まれる。
• プロトタイプとテスト： デザイナーは、デザインプロセスの早い段階でプロトタイプを作成し、そのプロトタイプを実際のユーザーとテストすることで、デザインハンドオフの前に問題を特定する。
• 継続的改善： このアプローチでは、製品が発売された後でも、ユーザーからのフィードバックやニーズの変化に基づいて、継続的なモニタリングと改良を促す。

要するに、UCD とは、ビジネス上の目標を満たすだけでなく、より重要なこととして、それを使う人々のニーズや期待に応え、より良いユーザー体験をもたらす製品を生み出すことを目指す総合的なアプローチなのです。

２．デザイン思考プロセス

出典： IBM’s Renner Modafares

デザイン思考プロセスは、大抵の UX フレームワークやワークフローの基礎となっており、世界中の UX デザイナーが UX デザインを学ぶ際に学ぶフレームワークになります。

デザイン思考のプロセスは、以下の５つの段階からなる反復的なユーザー中心のフレームワークです：

• 共感：ユーザーが必要としているものを見つける
• 確定：解決したい問題を決める
• アイデア出し：ユーザーの問題に対するソユーリョンを開発する
• プロトタイプ：プロトタイプを作成する
• テスト：プロトタイプをユーザーやステークホルダーとテストする

さらに読む：デザイン思考 プロセスとは？

３．ダブルダイアモンド

出典：UX Collective

ダブルダイヤモンドは、デザインイノベーションに好まれる成果ベースのデザインフレームワークであり、チームメンバーがアイデアを開発して反復する連携と創造的思考を促します。

ダブルダイヤモンドのフレームワークには、以下のように２つのステージ（ダイヤモンド）と４つのステップがあります：

第１ステージ – 準備：

• 発見：UX チームは、ユーザーのニーズや問題を理解するために UX リサーチを実施する。そこでリサーチャーは、インタビューやユーザビリティ調査を通じてエンドユーザーと関わり、共感し、問題を発見する必要がある。
• 確定：チームは、ディスカバリーから得たインサイトをもとに、プロジェクトが解決すべき問題を確定して優先順位をつける。

第２ステージ – プロトタイプおよびテスト：

• 開発：UXチームは、さまざまなアイデア出しやプロトタイプの手法を用いて、ユーザーの問題に対するアイデアやソリューションを開発する。
• 遂行： チームは、エンドユーザーやステークホルダーとともにソリューションをテストしなければならず、そこで機能しないソリューションは却下し、機能するソリューションは反復して改善する。

４．フックモデル

出典：Webkul

ニール・エリアル氏は、「習慣形成的な製品を作る」ための UX デザインフレームワークとしてフックモデルを開発しました。このフレームワークは、顧客に価値を提供しながら、デザイナーが倫理的にプロジェクトにアプローチすることを奨励しています。

フックモデルには、以下の４段階のプロセスがあります：

1. トリガー：ユーザーが特定の行動を取るきっかけとなる外部または内部のトリガーを理解する。
2. アクション：ユーザーに取ってもらいたい行動を確定する
3. 可変報酬：ユーザーがアクションを完了したときに得られる、予想外のポジティブな報酬。
4. 投資：ユーザーに、製品により多くの時間を投資するインセンティブを与えることで、サイクルを繰り返す。

さらに読む：

• Hooked: How to Build Habit-Forming Products
• 優れたUXデザインを生み出す心理的トリック

５．リーン UX

出典：Plain Concepts

リーンUX とは、成果物よりも成果を優先する、協働的な UX デザインのフレームワークであり、デザイナーは、思い込みではなくデータを使って意思決定を行わないといけません。また、この方法論では、必要のない機能が削除されるため、より無駄のない問題解決型の製品が実現します。

リーンUX のフレームワークには以下の３つの段階があります：

• 思考：結果、仮定、ユーザーリサーチ、アイデア、メンタルモデル、スケッチ、ストーリーボード
• 作成：ワイヤーフレーム、UI デザイン、モックアップ、プロトタイプ（MVP：最小実行可能製品）、価値提案、仮説
• 確認：データおよびアナリティクス、ユーザビリティテスト、ステークホルダーとユーザーのフィードバックの分析。

さらに読む：

• リーン UX ：UXで効率性を最大化するためのヒント
• Lean UX vs. Agile UX – is there a difference?（英語版）

６．アジャイル UX

出典：UXmatters

アジャイル UX は、アジャイルソフトウェア開発と連携するために作られたデザインフレームワークであり、アジャイルソフトウェア開発と同様に、以下のような１２の指針があります。

1. CX（カスタマーエクスペリエンス）
2. 技術と社会の変化を利用する
3. リソースを有効活用した開発スケジュール
4. 適応力のある連携
5. 意欲的な個人を中心としたプロジェクトの構築
6. チームのチャンネルを超えた効果的なコミュニケーション
7. 成功のベンチマークとなる実用的なアプリケーションと高品質の UX
8. 持続可能な開発
9. 技術的な卓越性は相対的なものである
10. シンプルさ
11. 部門横断チーム
12. 適応力のある柔軟なチーム

さらに読む：

• How Agile Environments Revolutionize a Design Team’s Workflow?（アジャイル環境はデザインチームのワークフローにどのような革命をもたらすか？）
• The 12 Realistic Principles of Agile UX（アジャイル UX の現実的な12の原則）
• アジャイル 、 スクラム 、 カンバン – プロジェクト管理 手法３選を比較

７．BASIC フレームワーク

出典：Basic UX

BASIC UX とは、「使える製品のためのフレームワーク 」です。比較的新しいデザインフレームワークであり、現代の製品開発のためのインタラクションデザインガイドラインを提供します。

BASIC の頭文字は、以下の５つの原則に従っています：

B = Beauty – 美しさ

A = Accessibility – アクセシビリティ

S = Simplicity – シンプルさ

I = Intuitiveness – 直感性

C = Consistency – 一貫性

各原則の中には、成功に導くためにデザイナーが自問自答しないといけない一連の質問が以下のように含まれています。

Beauty（美しさ）:

• ビジュアルデザインは美しいか
• スタイルガイドに従っているか
• 高品質のビジュアルが使われているか
• 適切に配置されているか

Accessibility（アクセシビリティ）:

• 「誰でも」使えるか
• 規準に準拠しているか
• クロスプラットフォームに対応しているか

Simplicity（シンプルさ）:

• ユーザーの負担は軽減されているか
• 乱雑で繰り返しの多い文章はないか
• その機能は必要か

Intuitiveness（直感性）:

• 機能は明確か
• ユーザーは最初の指示がほとんどなくても目的を達成できるか
• ユーザーは更なる指示がなくても簡単にタスクを繰り返すことができるか
• ユーザーは結果や出力を予測できるか

Consistency（一貫性）:

• 製品は既存の UI パターンを再利用しているか
• デザイン言語、画像、ブランディングはデザインシステムと一貫しているか
• 適切なタイミングで適切な場所に表示されるか
• 製品は毎回一貫したパフォーマンスをしているか

組織は、このような質問を適応させたり、独自の質問を追加して、製品とそのユーザーに関連したものであることを確認するといいでしょう。

さらに読む：BASIC UX – A Framework for Usable Products.（BASIC UX – 使いやすい製品のためのフレームワーク）

８．UX ハニカム

出典：Researchgate

ピーター・モーヴィル氏の UXハニカム は、７つの原則を列挙した総合的な UXデザインのフレームワークであり、この７原則は、高品質な製品とユーザー体験を提供するために、各デザイン決定の指針となります。

UX ハニカムの７原則は以下の通りです：

1. 有用性： 製品はユーザーの役に立ち、ユーザーの問題を解決するものでないといけない。
2. 使いやすさ： 直感的で使いやすいデザインでないといけない。
3. 好ましさ： UI（ユーザーインターフェース）のデザインは、美的感覚に優れ、好ましいユーザー体験を提供するものでないといけない。
4. 見つけやすさ： 検索やナビゲーションが明確でわかりやすいものでないといけない
5. アクセス性： ハンディキャップのあるユーザーを含め、どんなユーザーでもアクセスできるデザインでないといけない。
6. 信頼性： ユーザーが製品やコンテンツを信頼できないといけない。
7. 価値： 最終製品は、ユーザーとビジネスに価値をもたらすものでないといけない。

９．フォッグ行動モデル

出典：UI Patterns

スタンドフォード大学の B・J・フォッグ氏が開発した「フォッグ行動モデル」は、行動や行為は以下の３要素が収束した結果であると示唆しています：

• モチベーション
• 能力
• トリガー

フックモデル と同様、デザイナーはフォッグ行動モデルで長期的に使用率とエンゲージメントを上げる製品を構築することができるようになります。フォッグは、「些細なステップ」が長期的な行動を発展させる最良の方法であることがよくわかります。

私たちの多くが経験したことのある素晴らしい例として、「デジタルゲーム」があります。最初のレベルは簡単で、プレイヤーに達成感を与えることで、さらなるエンゲージメントを誘発します。そしてプレーヤーが製品に関わる時間が長くなるにつれて、ゲームは徐々に難しくなっていきます。

さらに読む：

• Fogg Behavior Model（フォッグ行動モデル）
• Tiny Habits by B J Fogg（小さな習慣 by B J フォッグ）

UXPin によるエンドツーエンドの製品デザイン

UXPinは、高品質な製品を提供するためのツールと機能を備えたエンドツーエンドのデザインソリューションであり、UX デザイナーは、UXPin のコードベースのデザインツールを活用して、最終製品のような外観と機能を持つ忠実度の高いプロトタイプを作成できます。

また、プロトタイプとテストは、あらゆるデザインフレームワークの重要な要素であり、UXPin のビルトインデザインライブラリにより、デザインチームはデザインプロセス全体を通してアイデアをテストするための忠実度の高いプロトタイプを作成できます。

有意義なテストのフィードバック

コードベースのプロトタイプは、最終製品のように見え、機能し、ユーザビリティテストやステークホルダーから有意義で実用的な結果を生み出します。それで UX デザイナーは、ユーザーのニーズとビジネス目標の両方を満たすソリューションを見つけるために、アイデアを素早く変更し、反復することができます。

効率化されたデザイン・ハンドオフ

より高い忠実度と機能を備えた UXPin のコードベースのプロトタイプは、エンジニアがより正確かつ効率的に最終製品を提供できるよう、デザインのハンドオフプロセスを効率化する上で重要な役割を果たします。

UXPin のコードベースのデザインツールで、エンドツーエンドのデザインプロセスを強化しませんか。無料トライアルにサインアップして、UXPin の高度な機能をすべて体験し、顧客により良い UX を提供しましょう。

The post UX デザインフレームワーク – 一番便利なフレームワークとは？ appeared first on Studio by UXPin.

Adobe XD の代替ソフトの多さに圧倒されている方もいるのではないでしょうか？既存のワークスペースにコピーするのではなく、Adobe XD でのアップグレードをお探しですか？

本記事で、UXPinが最高のAdobe XD の代替ツールである理由と、コードベースのデザインプラットフォームを使用するメリットをご紹介します。

また、UXPin Mergeが、デザイナーとエンジニアのギャップをどのように埋めるのかをお話しし、デザインシステムのための「信頼できる唯一の情報源（Single source of truth）」を作成する方法についてもご紹介します。

主なポイント：

• Adobe XD は著名なベクターベースのデザインツールであったが、そのスタンドアロンバージョンは、新規購入者向けにはもう提供されていない。
• Adobe XD の代替案を探す際には、直感的な UI、プロトタイピング機能、デザインシステム、コラボレーション機能、費用対効果などを考慮すべきである。
• UXPin Merge は、従来のベクターベースのツールよりも高度なコードベースのデザイン機能があることから、優れた選択肢になる。
• 多くの Adobe XD 代替製品とは異なり、UXPin Merge は製品開発全般にわたる課題に対応することから、全ステークホルダーへのワークフローが効率化される。

デザインチームと開発チームを、プロトタイプ、デザインハンドオフ、アプリ開発の各段階で使用できるコード化されたコンポーネントである「信頼できる唯一の情報源（Single source of truth）」でつなぎませんか。詳しくはUXPin Mergeをぜひご覧ください。

Adobe XD とは

Adobe XD は、Adobe が開発および保全するベクターベースの UI/UX デザインソフトウェアであり、デザイナーがワイヤーフレーム、モックアップ、プロトタイプを作成するためのエンドツーエンドのソリューションです。

その注目すべき機能には以下のようなものがあります：

• ベクターデザインとドローイングツール： Adobe XD で、複雑なベクターデザインの作成と編集ができるようになり、ディスプレイのサイズに関係なくシャープな出力が保証される。
• リピートグリッド： デザインプロセスを効率化する機能。デザイナーは、リストやフォトギャラリーなどの要素を数回のクリックで複製できるため、面倒な反復作業が軽減される。
• プロトタイプ： デザイナーはアートボードをリンクし、アニメーションやマイクロインタラクションを追加してインタラクティブ性を模倣できる。
• 音声デザイン： Adobe XD は音声コマンドに対応してしていることから、音声UI のデザインや音声トリガーの統合ができる。
• レスポンシブなリサイズ： さまざまな画面サイズに合わせて要素を自動的に調整し、サイズを変更することで、あらゆるデバイスでデザインが確実に美しく見えることが保証される。
• デザインシステム： 現代のデジタル製品設計に欠かせない機能。デザイナーとエンジニアの間のギャップを埋めるかを基準に、デザインシステムの機能性を評価します。
• コラボレーションツール： Adobe XD は、デザイナーのためだけのものではなく、アプリ内のコラボレーションツールで、チームでリアルタイムにコメント、共有、共同編集ができる。
• 統合機能： 他の Adobe Suite アプリケーションや一部のサードパーティツールとシームレスに統合し、プロトタイプと最終製品のギャップを埋める。

Adobe XD はサービス終了？

SNS上の憶測に反して、Adobe は Adobe XDを廃止したわけではありません。新規購入者向けの単独のアプリケーションとしての提供は終了しましたが、既存顧客のサポートは継続されます。また、新規で Adobe XD にアクセスするには、Adobe Creative Cloud All Apps サブスクリプションの購入が必要です。

Adobe XD の代替製品での注目点

もしコアな Adobe XD ユーザーでしたら、同等かそれ以上のデザインツールを求めるはずです。ここでは、その際に欠かせない点を挙げてみましょう：

• ユーザーに優しい UI： デザインツールは複雑ではなく、シンプルなものであるべきであり、直感的なインターフェースは、デザインプロセスのスピードを上げ、習得しやすく、効率を上げるものである。
  
  
• プロトタイピング機能：
  • リアルタイムでのプレビュー： デザインの変更をリアルタイムで確認できる。
  • インタラクティブなプロトタイプ： インタラクティブな要素、マイクロインタラクション、アニメーションでプロトタイプに命が吹き込まれる。
  • 応答性： ツールは、最小限の労力でデザインの複数のビューポートを作成できないといけない。
    
• デザインシステム： 現代のデジタル製品のデザインに欠かせない機能であり、デザイナーとエンジニアの間のギャップを埋める能力によって、デザインシステムの機能を評価する。
  
• コラボレーション機能：
  • コメント： デザインについて直接意見を述べる。
  • 共有： プロトタイプを配布してフィードバックを得る。
  • リアルタイムのコラボレーション（連携）： 統合されたチャット機能により、デザイン チームはワークスペースを離れることなく連携できる。
    
• デザインハンドオフ： シームレスな移行は、デザインチームと開発チーム間の行き来を抑制することから、正確なスペック、アセット、コードスニペットを生成するツールを探すべきである。
  
• プラットフォーム統合： 統合機能により、アプリケーション間のジャグリングが減り、統一されたワークフローが促進される。
  
• 費用対効果： 優れたデザインツールだと予算は圧迫されない。高額でないが強固な機能があるソリューションを選ぶことで、かかる費用に見合った価値が確保される。

Adobe XDに代わるもの

Adobe XD、Figma、InVision のようなベクターベースのツールが長年デザインシーンを引っ張ってきましたが、UXPin のようなコードベースのプラットフォームへの顕著な移行が見られます。

UXPin Merge のテクノロジーにより、デザイナーは基本的なプロトタイプを超え、最終製品のように見える高度なコードベースのレプリカを作成することができます。また、Merge とコードベースのデザイン プラットフォームを使用する利点には次のようなものがあります：

• リアルでインタラクティブなプロトタイプ： UXPin のようなコードベースのツールは、最終製品をミラーリングし、それでデザイナーは、テストから高品質のインサイトを得ることができる。
• 動的要素： ベクターベースのツールの静的要素とは異なり、UXPin にはステート、スタイリング、ロジック、実データを持つライブコードの UI コンポーネントがある。
• シームレスなハンドオフ： デザイナーとデベロッパーは Merge を介してコードに基づいて同じ言語で会話し、それによってシームレスなハンドオフおよび少ない修正でよりスムーズなワークフローができる。
• 優れたパフォーマンス：Merge コンポーネントには、遅れや途切れのない複雑なインタラクションとアニメーションがあり、最終製品のエクスペリエンスを正確に再現する。
• デスクトップおよび Web アプリケーション： デザイナーは UXPin のデスクトップアプリケーションをオフライン（Windows および MacOS）または Web アプリケーションで使用でき、どちらの環境でも同等の UX（ユーザーエクスペリエンス）を得られる。
• すべての機能を内蔵: UXPin は、コンセプトから最終的な納品まで、デザイナーに必要な機能が全て備わったフルスタックデザインツールであり、プラグイン、エクステンション、その他のサードパーティ製アプリやサブスクリプションは必要ない。

UXPin の プロトタイプでの使用法

Merge は、UXPin のようなデザイナー向けのロゴブロックで、ドラッグ＆ドロップのプロトタイプ環境を作成します。また、各コンポーネントには、スタイリング、インタラクティブ性、コンテンツ、その他のプロパティがデザインシステムのレポジトリからプログラムされており、プロトタイプを始められる状態になっています。

そしてデザイン システム チームは、デザイナーがプロトタイプをより迅速に構築できるように、画面テンプレートを完成させるための基本的な UI 要素を含めることができます。また、接続がある API コンポーネントは、どれもデザイナーが UXPin で使うことができます。

デザイナーは、デザインシステムチームが React props（または Storybook統合のArgs）を使うことによって、テキストスタイル、サイズ、色、インタラクティブ性などのコンポーネントプロパティにアクセスできるようになります。

そしてデザイナーは、UXPin のデザインシステムライブラリからコンポーネントを取得し、プロパティパネルでそのプロパティを調整します。また、JSXモードに切り替えて、コードの表示や変更を行うこともできます。

MergeによるUXPinのテスト

このような完全にインタラクティブなプロトタイプで、プロトタイプの幅が広がり、それでデザイナーは、通常はデベロッパーからの技術的なインプットが必要な、複雑なインターフェースやユーザーフローの構築やテストができるようになります。

また、デザイナーは、プレビューと共有 のや UXPin Mirror の機能を使って、ブラウザ上でプロトタイプをテストでき、ステークホルダーにプロトタイプを表示するためのリンクを送信したり、UXPin のコメント機能を使って注釈を付けてフィードバックを共有したりできます。

「当社のステークホルダーは、UXPin を使ってとても早くフィードバックをしてくれます。 彼らにリンクを送れば、それで彼らは好きな時にプロトタイプを試し、UXPin を使ってプロトタイプに直接コメントを残してくれます。 UXPin のコメント機能は、コメントに対処したらフォローして「解決済み」としてマークできるので、素晴らしいです。」 エリカ・ライダー、プロダクト、UX、および DesignOps のソート リーダー。

デザインハンドオフでUXPinを活用するには？

Adobe UX やその他のベクターベースのデザインツールを使ったデザインハンドオフは、とても大変であることで知られており、多くの場合は摩擦を伴い、デザイナーがデベロッパーにモックアップやプロトタイプを説明しようとしたり、デベロッパーがデザインチームに技術的な制限を説明しようとしたりすることが多くなります。

UXPin Merge のテクノロジーだと、チームと部署がそれぞれまったく同じレポジトリからまったく同じコンポーネントライブラリを使うため、デザインから開発への移行がスムーズになります。そしてこの「信頼できる唯一の情報源（Single source of truth）」は、デザインハンドオフに必要な文書や説明が少なくて済むということになります。

エンジニアは、コンポーネントのレポジトリをプロジェクトにインポートして UXPin からインターフェースをコピーし、props または Args を使って同じコンポーネントプロパティを適用するだけです。

UXPinのデザインシステムでの使用法

UXPin には、デザインシステムの構築から、デザイナーとエンジニアが同じコンポーネントを使う Mergeテクノロジーを使った完全に統合されたUIライブラリまで、あらゆる成熟段階に対応するデザインシステムソリューションがあります。

Merge で、組織はレポジトリから UXPin のデザインエディタにUIライブラリを同期できるようになり、デザイナーは、デベロッパーが最終製品を開発するのと同じデザインシステムのコンポーネントを、デザインプロセスで使用できるようになります。

また、レポジトリへの変更は自動的に UXPin にプッシュされ、最新リリースがチームに通知されます。そして UXPin のバージョン管理では、デザイナーが新しいリリースに切り替えるタイミングを決めることができ、いつでも以前のバージョンに戻すことができます。

デザインシステムに対するこのコードベースのアプローチで、組織は本物の「信頼できる唯一の情報源（Single source of truth）」を得られます。チームはそれぞれ同じUIライブラリを使用し、強力な Merge の自動化によって、 1 つのリリースで全員の同期が保たれるため、コードとデザインを個別に更新する必要がありません。

UXPin のコラボレーション（連携）における使用法

UXPinのコメント機能は、チームが非同期で作業する現代のデジタル製品設計にピッタリです。 Slack と Jiraの統合により、部門を超えたチームの同期が保たれ、常に最新情報が更新されますからね。

コメント機能は UXPin 内のチャットアプリのように機能します。チームメンバーはコメントを割り当てることができ、アクションが完了したら「解決済み」としてマークすることができます。また、メール通知により、全員が最新情報を入手できます。そしてデザイナーは、ステークホルダーがアカウントを持っていなくても、UXPinで連携できるように彼らを招待できることから、彼らのアカウントを確保するのにお金を払う必要がなくなります。

UXPin Merge が最高の Adobe XD 代替ツールに勝る理由

Zeplin、Proto.io、Marvel、Figma、その他の Adobe XD 代替ツールでは、グラフィックデザイン、プロトタイプ、ツールではデザイナーのワークフローとUIデザインを最適化することに重点を置かれています。重要なステークホルダーやインタラクティビティのプロトタイプにはあまり重きをおいていません。

一方、UXPinとMergeテクノロジーにおいては、デザイナー、プロダクトマネージャー、エンジニア、DesignOps、DevOpsなどのエンドツーエンドのデジタル製品開発プロセスに多くのメリットをもたらします。

Adobe XDの代替製品は数多くありますが、UXPinはデザインと開発のギャップを埋めることで、製品開発の多くの課題を解決する唯一のプラットフォームとなります。

UXPin に切り替えることで、フルスタックの製品デザインソリューションでデザインと開発を速やかに同期できます。詳細とアクセスリクエスト方法については、こちらのページをぜひご覧ください。

The post Adobe XD 代替製品 – コードベースの 「UXPin Merge」 appeared first on Studio by 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.

 デザイン制約 は、どんな企業規模であろうとプロジェクトとその成果に少なからず影響を与えます。経験が豊富なデザイナーは、仕事を形作る「制約」について向き合い、うまく活かすことで真の創造性がもたらされることを認識しています。

このブログでは、シニアデザイナーにとって身近な課題であるデザイン制約について掘り下げます。

主なポイント

• デザイン制約とは、デザインプロセスで行われる創造的で技術的な決定に影響を与える制約のことをいう。
• 最初のステップは、制約を認めることであり、これらの制約がUXデザイナーに素晴らしいデザインの成果をもたらすことを制約していることを認めること。
• デザイン制約を理解することで、悪影響を最小限に抑える、または問題を完全に取り除くことができる。

UXPin Mergeでプロトタイピングの制約をなくし、デザイナーとエンジニアのギャップを埋め、優れたユーザー体験を提供しましょう。

UXPin Mergeに関する詳細およびアクセスリクエスト方法については、こちらのページをご覧ください。

 デザイン制約 とは

デザイン制約とは、デザインプロセスにおいて、内的要因や外的要因によって課される制限や制約のことです。この「制約」は最終製品に影響を与えるため、組織の全員が制約について認識し、毎回各プロジェクトの開始前にその制約についてしっかりと考えることが非常に重要です。

デザイン制約は大きく分けると以下のようなものがあります：

• 技術的制約：製品の技術スタックとエンジニアリングのチームによるもの
• 金銭的制約：部門予算やプロジェクト予算
• 法規制の制約：従う必要がある法律
• 組織の制約：文化、構造、方針、官僚主義
• 自主規制：各デザイナーのワークフローとクリエイティブな意思決定
• 才能の制約：デザイナーのスキルや経験、プロとしての欠点
• プロジェクト独自の制約：時間、予算、利用可能なチームメンバーなど、プロジェクトに関連する制約

これらをさらに詳しく調べ、チームメンバーやステークホルダーのデザイン制約への対処法について見ていきましょう。

１．技術的制約

技術的な制約は、デザイナーが創造的で革新的な限界をどこまで押し広げられるかを左右するため、デザインプロジェクトに大きな影響を与えます。

以下に技術的制約の例を挙げてみましょう：

• デバイスとOS（オペレーティングシステム）の制限：iOSとAndroidの制約、画面サイズ、処理能力など
• アクセシビリティの制約：音声コントロールとスクリーンリーダーがデザイン決定に与える影響
• 性能の制約：ユーザー帯域幅/インターネット接続、製品サーバー、および技術スタックの影響
• 統合とAPI：外部サービスからの制限とAPI要件
• 技術スタックの制約：フロントエンドとバックエンドの技術によるデザインプロセスへの影響

２．金銭的制約

金銭的制約は、人材、ツール、ユーザーリサーチ、プロジェクトスコープ、テクノロジーなど、デザインプロセスの多くの分野に影響を与えます。多くの人は金銭的制約を「障害」と見なす一方で、ブートストラッピングや回避策を通して創造的思考やデザインイノベーションが促されることがよくあります。

金銭的制約がデザインプロセスに与える影響には、以下のようなものがあります：

• 各分野（リサーチ、ワイヤーフレーム、プロトタイピング、インタビュー、テストなど）の範囲が制限される
• イテレーションとテストの回数が制限される
• デザイナーが使うツールが限定される
• デザインチームの規模とスキルレベルが決まる

３．法的および規制上の制約

法的制約は、UXプロジェクトに関してコンテンツとユーザーデータに最も影響を与えます。法律は国によって変わるため、デザイナーは法律顧問やステークホルダーからのアドバイスに頼ることになります。

法的制約がデザインに与える影響は以下のようなものがあります：

• プライバシー法：デザイナーが収集するデータ、収集方法、ユーザーへの法的通知、許可を得る方法などを規定する法律で、特に欧州連合（EU）の一般データ保護規則（GDPR）やカリフォルニア州消費者プライバシー法（CCPA）などがある。
• アクセシビリティに関する法律: デザイナーは、さまざまな障がいがあるユーザーのために法的に利用しやすいUI（ユーザーインターフェース）にする。（例：米国のADA（Americans with Disabilities Act ：障がいを持つアメリカ人法））
• 知的財産法：文字、画像、動画などのオリジナル作品の著作権。さらに、デザイナーは競合他社やブランドの知的財産、商標、その他の法的保護を侵していないかを考慮しないといけない。
• 業界独自の規制：金融や医療など、プライバシーやセキュリティに関する法律があり、ログインや認証の手順など、デザインに大きな影響を与える業界もある。

４．組織的制約

組織的制約とは、会社の他の部分によってデザインに課される制約を指します。多くは組織の価値観、文化、会社のビジョン、他部門との利害の競合に関係します。

組織的制約の例としては、以下のようなものがあります：

• 時間的制約：ステークホルダーが設定する締め切りは、デザイナーのデザインアイデアの調査やプロトタイプの作成、テストの実施法に影響を与えることがある。
• ブランドガイドライン：組織のブランドは、スタイルやメッセージの決定に影響を与える。
• マーケティングとビジネス目標：デザイナーは、「顧客のニーズ」と「組織の目標」とのバランスをとらないといけないことがよくある。
• デザインシステムの制約：利用可能なコンポーネント、デザイン原則、スタイルガイド、ガイドライン、デザインシステムガバナンスは、デザイナーが製品を作成する方法に影響を与える。
• 組織のサイロ化：連絡や連携がきちんとなされないと、進捗を妨げるサイロ化につながり、これによって重複作業、遅延、デザインドリフト、不整合、その他の摩擦につながることがよくある。
• デザインの価値：組織がUX部門をどのように認識しているかがリソースの配分や賛同に影響を与えてしまい、デザイナーができることが制限される可能性がある。

５．自主制約

デザイナー自身の制約としては、使用するデザインツール、タスクを完了するためにかかる時間、製品のデザインシステム使用の有無など、デザインプロセス中の選択肢やオプションに関連して生じます。

６．人材的制約

人材的制約とは、デザインチームが利用できる「スキル」と「スペシャリスト」に関するものです。管理者はお互いを補い合う人材を配置できるように、各デザイナーのスキルセットと専門知識を把握しておくことが重要です。人材的制約を理解することで、管理者は適切な人材を置いたり、特定のデザインプロジェクトのために専門業者を雇うタイミングを計ることができます。

７．プロジェクト特有の制約

プロジェクトの制約が、他の場合は存在しない、あるいは組織にとって稀なデザイン上の問題を引き起こします。例えば、デザイナーは慣れた時間枠よりも短い時間枠でプロジェクトを完了しないといけない可能性があると、望ましい結果を達成するのにワークフローを適応させたり、ツールを切り替えたりすることになります。

 デザイン制約  – その解決方法

多くの組織では、制約の克服はDesignOpsの仕事です。DesignOpsチームは、部門のアウトプットと組織の価値を最大化するために、このような制約や障害を軽減しないといけません。

この問題ベースのフレームワークで、組織が抱える最大の課題からデザイン制約を克服することができるでしょう。問題ベースのアプローチでは、具体的な問題とそれに関連する制約を解決することができるため、そのインパクトが大きくなります。

• 問題の定義：市場投入までの時間短縮や、デザイナーの生産性向上など、どのような課題を解決しようとしているか。
• 制約の特定：この問題に関連する制約、つまり予算、資源、時間、技術的な制約などをリストアップする。
• 制約の優先順位付け：どの制約が最も重大かを判断し、それに従って優先順位をつける。
• ソリューションのブレーンストーミング：適切な専門家、チームメンバー、ステークホルダーと会ってソリューションのブレーンストーミングを行い、可能性があるもののリストを作る。
• ソリューションの評価：各アイデアの長所と短所を検討し、実現可能性が最も高く、潜在的な影響が最も大きいものを決定する。
• ソリューションの選択：最良の結果をもたらすと思われるソリューションを選択し、実施するための計画を立てる。
• テストと反復：ソリューションの効果を測る KPI （重要業績評価指標）を作成し、結果を最適化するために時間をかけて微調整する。遠慮はせずに、パフォーマンスの悪いアイデアは放棄して新しいアイデアは反復する。

問題の特定：有効性 と 効率性

UXPinが主催したこちらのウェビナーでは、DesignOpsのエキスパートであるPatrizia Bertini氏がソリューションの結果を測るために実務者がどのように問題を解決するべきかについて説明しました。ここでは「有効性」と「効率性」の違いを認識することが不可欠であると主張しています。

有効性は、以下のような定性的なメトリクスを用います：

• 共感と継続的なユーザーエンゲージメント
• アイデア出しと実験のサイクルタイム
• チームのスキル構成（スキルマトリックス）
• デザインスキルの分布
• 部門横断的パートナーによるデザインの価値認識
• デザイナーの満足度と定着率

効率性は、以下のように数字、パーセンテージ、比率を用いて測定可能であり、定量化できます：

• ツールの ROI （コスト／エンゲージメント／アドプション）
• テストとプロトタイプのリードタイム（時間）
• 品質レビューの回数と種類
• チームの生産性（リソースの利用率）
• エンドツーエンドの納期（時間）

UXPin Mergeで制約を減らす

従来のデザインワークフローや画像ベースのツールは、デザイナーに多くの制約をもたらします。特にプロトタイプの忠実度や機能性は、以下のような多くの問題を引き起こします：

• ユーザーテストの範囲が限られる
• デザインプロセス中にユーザビリティの問題を発見できない
• 問題解決の機会が少ない
• ステークホルダーの理解度が低く、購買意欲に影響する
• ビジネスチャンスを特定する能力が低い
• デザイナーとデベロッパーの連携が不十分で、デザインのハンドオフが大変。

UXPin Mergeは、製品のコンポーネントライブラリをUXPinのエディタと同期させることで上記の問題やその他の問題を解決するします。デザイナーは、エンジニアが最終製品の開発で使用する同じUI要素をデザインプロセスで使えるようになります。

Mergeコンポーネントは完全にインタラクティブで、UXPin上でもレポジトリや最終製品とまったく同じように機能します。このインタラクティブ性によって、デザインチームはコンポーネント駆動のワークフローを利用できるようになり、プロジェクト範囲が拡大し、テストと反復が大幅にスピードアップします。

Mergeではデザイナーとエンジニアは共通の言語を使用することができるため、サイロや運用上の制約をなくします。Mergeを使ったハンドオフは摩擦がなく、エンジニアがすでに同じコンポーネントライブラリを持っているため、ドキュメントや説明が少なくて済みます。UXPinがJSXをレンダリングするので、エンジニアは、コピー＆ペーストだけでコンポーネントのプロップに適用できます。

また、テストにおいての制約も大幅に減ります。ユーザビリティテスト参加者とステークホルダーは、最終製品と同じようにプロトタイプを操作できるため、反復して結果を改善するための有意義で実用的な結果を得られるのです。

「UXPin Merge を使うことで、ステークホルダーからのフィードバックを非常に早く行えるようになりました。プロトタイプのリンクを共有するだけで、相手は空いてる時間で自由に閲覧できますし実際にプロトタイプを操作してもらえます。また、Comment機能を使用して相手からのコメントをもらうこともできます。もらったコメントを参考にして改善したら［解決済み］としてマークできるので、使いやすいです。」 – Erica Rider, UX Lead EPX – PayPal

UXPin Mergeのコードベースのデザインソリューションで、プロトタイプの制限をなくしませんか？

時間の制約が厳しい場合でも、反復作業をスピードアップして高品質なプロジェクトを実現できます。

詳細とアクセスリクエスト方法についてはこちらのページをぜひご覧ください。

The post ７つの デザイン制約 とその解決方法 appeared first on Studio by UXPin.

 デザインハンドオフツール を使用することで、デザインから開発へのスムーズな移行を促進させることができます。

エンジニアには、実用的なドキュメント、忠実度の高いプロトタイプ、効率的なコミュニケーションおよび連携向けの機能を提供します。

効果的なデザインハンドオフのプロセスがなければ、デザインと開発間のギャップを埋めるために多くの時間を費やしてしまいます。

コード化コンポーネントを使ってデザインすることで、ハンドオフのプロセスを効率化してみませんか？

UXPin Mergeでは、npm、Storybook、Gitレポジトリからコンポーネントをインポートして、エディタにドラッグ＆ドロップするだけで高度なプロトタイプを作成できます。

この技術についてさらに詳しく知りたい方は、こちらのページをぜひご覧ください。

１．UXPin Merge

UXPin Mergeは、ReactやStorybookコンポーネントで構築されたコードベースのHi-Fi（高忠実度の）プロトタイプをデザインしてハンドオフをすることができます。

この「信頼できる唯一の情報源（Single source of truth）」によって、デザイナーもエンジニアも同じUI要素で作業できるため、市場投入までの時間が大幅に短縮されます。

プロトタイプが完成すると、次にデザイナーはそれをエンジニアと共有します。

エンジニアはスペックモードを使って、ドキュメント、スタイルガイド、コメントを見ることができるだけでなく、開発段階で使用可能なコンポーネントのJSXコードをコピーして使用することができます。

ちなみに、UXPin Mergeは最初から完全にコード化されたコンポーネントを使ってデザインできるのでエンジニアとデザイナー間で伝達ミスが起きることはありません。

Mergeがデザインプロセスとハンドオフをどのように最適化できるかについての詳細は「デザインハンドオフ ーUXPin Mergeで実現することー」の記事をご覧ください。

２．Zeplin

Zeplinは、デザイナー、エンジニア、その他のチームメンバーが効率的に連絡・連携しやすくなる人気の デザインハンドオフツール です。

Jira、Slack、Trello、Microsoft Teamsなどのコラボレーションツールと統合可能です。

Zeplinを使うと、デザイナーは注釈を含むユーザーフローの作成と、エンジニアにコンテキストの提供が可能です。

スタイルガイドから色、テキストスタイル、スペーシング/レイアウト、デザイントークン、コンポーネントを保存することができます。

また、開発で使えるコードスニペット、その他のスタイリングが含まれているのも魅力ポイントです。

３．Marvel

Marvel は、Zeplinと同じくデザインハンドオフ機能がある人気のデザインツールです。

自動生成されたモックアップを使って、プロトタイプの作成・他のデザインツールからのインポートが可能です。

MarvelはモックアップからスターターコードとCSSを生成して時間を節約でき、デザインと開発のギャップを埋めることができます。

また、エンジニアは各コンポーネントのチェックとアセットのダウンロードができるため、連絡ミスやツール間の切り替えを回避できます。

４．Sympli

Sympli は、バージョン管理とデザインのハンドオフを目的としたツールなので、コンポーネントディレクトリのStorybookに相当する “デザイナーのような” 存在と言えるでしょう。

Sympliをプロトタイピングツールと統合し、UI要素やデザインシステムを同期させることで、要素の説明やコンテクストを加えるためにチーム間のレビューや共同作業が可能です。

また、エンジニアはスタイルガイド、スペックモード、スペックとアセットを参照して開発プロセスを開始できます。

さらに、Sympliにはモバイルアプリ開発用のXcodeとAndroid StudioのプラグインでIDE（統合開発環境）と同期できるのが最大の魅力です。

５．Avocode

Avocode は、開発チームのためのデザイン ハンドオフ ファイルを作成します。

また、Avocode の「ワンクリック」統合が、ダウンロード可能なアセット、スペックモード、１０種類のコード言語用のスニペットを生成することで、デザイナーには時間の節約になります。

そして、Avocode のデザインレビューでは、デザイナーは他のチームやステークホルダーを招待して、デザインの批評やフィードバックを行うことができます。それでデザイナーは、全員が更新を認識できるように、フィードバックを反復し、変更を再同期して新しいバージョンを作成できます。

なのでデザインチームは、Avocodeのレビュー機能を使って、矛盾点や修正点について話し合うことができます。

６．InVision

InVision は UXPin のような機能があるデザインツールであり、InVision Studioのデザインからのプロトタイプの作成や、他の一般的な画像ベースのデザインツールからのファイルのインポートなどができます。

Inspect は、デザインスペックとコードスニペットを自動生成する、InVisionのデザインハンドオフツールであり、デザイナーとエンジニアは、コメント機能で連絡をとって連携とフィードバックを一箇所で維持することもできます。

また、InspectのStorybook統合により、InVision はコードレポジトリにあるコンポーネントをエンジニアに通知し、それがライブラリを検索する時間の節約や、不慮の手戻りの予防になります。

そして、InVisionはコミュニケーションやプロジェクト管理タスクを同期するのに、Jira、Confluence、Trello などのソフトウェアとの統合もします。

７．Framer

Framerは、React コンポーネントを同期して編集するコードエディタを備えたレイアウトデザインツールです。

これはデベロッパーにとっては素晴らしい機能ですが、コードの知識や経験があまりないデザイナーには不向きです。

UXPinのようにプロパティパネルでコンポーネントのプロップを編集することはできないので、代わりにFramerのコードエディタでの変更を加える必要があります。

これもコードに慣れていない人にとっては理想的ではありません。

しかし、デザイナーはReactコンポーネントをプロトタイプやテストに使うことができ、他の一般的な画像ベースのツールよりも優れた忠実度と機能性が得られます。

また、Framerの高い忠実度と機能性によって、デザインのハンドオフがスムーズかつ効率的になり、エンジニアは、React コンポーネントからコードをコピーして、新しい製品やUIを構築することができます。

ただ、Framer のコードベースのデザインテクノロジーは、React製品には優秀ですが、UXPinの Storybook統合が提供する他の一般的なフロントエンドフレームワーク用の機能がありません。

８．Spectrr

Spectrr は、色、フォント、スペーシングなど、エンジニアがコンポーネントやレイアウトを検査するための自動注釈が付いたデザイン仕様ツールです。

デザイナーは、各コンポーネントのメモや、レスポンシブレイアウトの作成指示を含めることができます。そしてエンジニアは、Spectrr がプロジェクト用の完全なCSSファイルの生成もするため、開発を開始するための優れたスターターテンプレートを手に入れることができます。

９．Adobe XD

UXデザインやプロトタイピングツールとして広く使われていましたが、2023年に廃止されました。Adobe XDの共有モードを使って、デザイナーは仕様書やCSS のスターターコードなどをエンジニアに渡すことができます。

コメント機能はAdobe XDとJira、Slack、Microsoft Teamsなどのプロジェクト管理ソフトウェアと統合させて共同作業を行うことができます。

また、Adobe XDの共有モードでは、他のデザインハンドオフツールに比べて限られていましたが、Zeplinにデザインを同期することで、より多くの機能とより良い連携ができました。

１０．Figma

Figmaは世界中で最も人気のあるデザインツールの１つです。初期リリース時点では Sketchに似ていましたが、その後プロトタイプやテスト機能を提供できるように進化しました。

Figmaの共有機能によって、エンジニアは要素を検査し、Web、iOS、Android用のコードスニペットを生成することができます。

また、React、Flutter、Vue、Ember、Angular などのフレームワーク向けのコードを生成するために、サードパーティのプラグインのインストールもできます。

2023年現在、デザインプロジェクトに無料で「開発モード」が追加できるので、エンジニアはプロジェクトにアクセスして、コメント機能でフィードバックができるでしょう。

ちなみにUXPinは、従来の画像ベースのデザインツールのようなベクターファイルではなく、HTML、CSS、Javascript をレンダリングするコードベースのツールです。そのため、デザイナーとデベロッパーにとってドリフトが少なく、実際のデザインがイメージしやすいというメリットがあります。

デザインハンドオフが大変な理由

デザインハンドオフの最大の課題として、プロトタイプの忠実性と機能性があります。

デザイナーは、トランジションやアニメーション（例：GIFやビデオなど）のようなコードベースの機能を再現するために、さまざまなツールや方法を用いる必要があります。

非現実的な期待

技術的制約がないと、デザイナーや製品チームに非現実的な期待を抱かせてしまうかもしれません。

実際のプロトタイプには含まれていないことから、エンジニアはどのように組み合さっているかを確認するためにプロトタイプから外部ファイルにアクセスしたり、アニメーションを見てどのように組み合わされているかを確認する必要があります。

コードレンダリングに不十分な画像ベースツール

もうひとつの問題は、デザインのコードへの変換です。

多くの画像ベースのデザインツールには、CSSを含むHTMLテンプレートが自動生成できるプラグインやアプリケーションがあり、これで十分に思えるかもしれません。

しかし、実際のところ、このコードだけではデザインを完全には再現はできません。共通言語が異なることから、”ズレ” がでてきてしまうのです。

技術的制約 

デザインドリフトのもう一つの原因は、製品を表示するブラウザやデバイスのレンダリングエンジンです。

よく起きがちなケースとしては、モックアップから最終的なコードへの色やグラデーションでのドリフトが挙げられます。

多すぎるデザインハンドオフツール

ハンドオフではデザインファイル、プロトタイプ、ドキュメント、アセット、コラボレーションのためのツールが複数使用されていることがよくあります。

さまざまな場所やプラットフォームに分散していると、ハンドオフではミスやエラーが起こりやすくなってしまいます。

ここで紹介したのは、あくまでデザインと開発間の摩擦が起きやすい場面の一部の例であり、ハンドオフ経験者であればよくご存じかと思います。

しかし、ラッキーなことに、このプロセスを効率化できるデザインハンドオフツールがあります。

UXPin Mergeによるデザインハンドオフの改善

UXPin Mergeは製品開発フローにおけるすべての課題を解決できるオールインワンUXデザインツールです。

ツールの使用を１つにして、デザインワークフローを効率化し、完全に機能するプロトタイプの作成、連携の強化、製品のUXの向上を実現しましょう。

まずは14日間の無料トライアルでUXPinをお試しいただき、すべてがつながることで製品開発がどれくらい簡単になるかを実感ください。

UXPin Mergeのアクセスのリクエストはこちら。

The post ２０２４年に試すべき デザインハンドオフツール １０選 appeared first on Studio by UXPin.

 プロダクトデザイナー としてのキャリアをお考えですか？このガイドでは、必要なスキルや資格、人脈作り、キャリアアップに至るまで、覚えておくべきポイントをご紹介します。ビジネス目標とユーザーニーズを一致させ、魅力的な製品を作り上げ、進化し続けるプロダクトデザインの世界で活躍するための方法を見ていきましょう。

主なポイント：

• ワイヤーフレームから効果的なコミュニケーションまで、「ハードスキル」と「ソフトスキル」を混ぜて習得するのが、プロダクトデザインでの成功には不可欠である。
• デザインやコンピューター・サイエンスの正規教育は強力な基礎となるが、オンラインコースや独学の道もある。
• 業界のイベントやコミュニティを通じてネットワークを作り、メンターを見つけることがプロとしての成長の近道になることがある。
• プロダクトデザイナーのキャリアアップは、ジュニアから専門家、または管理職へと進むことが多く、それぞれの段階でさまざまなレベルの専門知識が要求される。
• 磨かれた履歴書とインタラクティブなポートフォリオがあれば、求人応募で際立つため、自分の経験をカスタマイズし、数値化できる実績をアピールすることに重点を置くといい。

世界最先端のプロダクトデザインツールを使って、インタラクティブなプロトタイプで他のデザイナーに差をつけましょう。無料トライアルにサインアップしてUXPinの機能を実際にお使いいただき、デザインスキルをさらに高めましょう。

 プロダクトデザイナー の仕事とは

 プロダクトデザイナー は、ユーザーの問題を解決するソリューションを戦略化・概念化して提供します。そしてビジネス目標とユーザーニーズを一致させ、市場調査から最終的な実行まで、製品ライフサイクルをナビゲートします。

また、プロダクトデザイナーは、ユーザーフローのマッピング、ワイヤーフレームの作成し、忠実度の高いプロトタイプの作成をし、ビジュアルだけでなく、デベロッパー、UX デザイナー、プロダクトマネージャーなどの部門横断的なチームと協力して、製品をアイデアから市場に送り出すこともよくあります。

プロダクトデザイン と UXデザイナーは同じか

製品のユーザビリティと機能性に主眼を置く UX デザイナーとは違って、プロダクトデザイナーはデザインプロセス全体を管理し、それは、UX（ユーザーエクスペリエンス）にとどまらず、UI（ユーザーインターフェース）のデザインや、多くの場合フロントエンド開発も含みます。

また、UX デザイナーが UX に焦点を当てるのに対し、プロダクトデザイナーは CX（カスタマーエクスペリエンス）全体を広く見渡します。ユーザビリティと収益性の最適化のために、顧客がどのように顧客ライフサイクルに入り、どのように顧客ライフサイクルから退出するかを理解しないといけません。

 プロダクトデザイナー の役割

以下のような主な責務で、プロダクトデザイナーがデザインプロセスにおいて全面的な所有権を持つことがわかります：

• 市場調査： ユーザーニーズと市場ギャップを特定し、それをデザイン戦略に反映させる。
• ワイヤーフレーム作成： プロジェクトのビジュアルおよびコンテンツ要素をガイドする基本的なレイアウト構造を作成する。
• プロトタイプ： 最終製品を視覚化するための忠実度の高いプロトタイプを開発し、ユーザビリティテストを実施する。
• ユーザーテスト： ユーザーインタビュー、ユーザビリティテスト、アンケートを実施し、デザインイテレーションのためのインサイトを集める。
• デザインハンドオフ： デベロッパーと調整し、ビジュアルアセットとコーディングのためのデザイン仕様を全て提供する。
• QA（品質保証）： 開発環境で実装されたデザインがデザイン仕様に確実に適合しているように確認する。
• 部門を超えた連携： 目標を合わせて統一された UX を提供すべく、プロダクトマネージャー、UX デザイナー、デベロッパーと協力する。
• ドキュメンテーション：デザイン仕様書やライブラリを作成および更新し、それによってチームメンバーが一貫してデザインを実施できるようにする。
• パフォーマンス指標： ユーザーエンゲージメントやコンバージョン率などの KPI（重要業績評価指標）を監視し、デザインのインパクトを測る。

 プロダクトデザイナー に必要なスキル

ハードスキル

• スケッチとワイヤーフレーム： デザインのアイデアをサッと視覚化するスケッチテクニックを習得している。
• プロトタイピングツール： UXPin、Figma、Adobe XD、Sketch など、忠実度の高いプロトタイプのためのデザインツールに精通している。
• コーディング： HTML、CSS、JavaScript の基礎知識で、インタラクティブなプロトタイプを作成でき、デベロッパーとのコミュニケーションを強化する。
• デザインシステム：スケーラブルなデザインシステムを構築および維持する方法を理解している。
• ユーザーリサーチ： ユーザーインタビュー、アンケート、ユーザビリティテストを実施できる。
• データ分析： 分析データを解釈し、情報に基づいたデザイン上の意思決定を行うスキル。
• レスポンシブデザイン： さまざまな画面サイズに対応する UI のデザインに精通している。
• ビジュアルデザイン： タイポグラフィ、カラーセオリー、グリッドシステムなどの UI デザイン要素を使いこなせる。

ソフトスキル

• コミュニケーション： デザインの選択肢を明確に説明し、ステークホルダーを説得する能力。
• 問題解決： 問題を特定し、実用的な解決策を考案する卓越した分析力。
• 協調性： 部門横断的なチームでシームレスに働き、集団的な意見の価値を理解している。
• 時間管理： 品質を犠牲にすることなく、複数のプロジェクトと納期のバランスをとる。
• 共感力：ユーザー中心のデザインのために、ユーザーのニーズ、モチベーション、ペインポイントを理解している。
• 適応力： 変化を受け入れ、必要に応じて新しいツールやプロセスをサッと採り入れる。
• 細部へのこだわり： どんなデザイン要素も見逃さず、洗練された最終製品に貢献する。

 プロダクトデザイナー になるのに必要な資格

プロダクトデザイナーになるには、さまざまな道があり、正規の教育を受けて学位を取得することもできますし、オンラインのリソースやコースを利用した独学も可能です。

正規教育

• グラフィック・デザインの BFA（美術学士号）： デザイン原理とビジュアル・コミュニケーションの基礎を学ぶ。
• インタラクションデザインの学士号： インタラクティブなデジタル製品のデザインに重点を置く。
• デザインにおける MFA（美術修士号）： さらに専門性を高め、競争力を身につけたい人向け。
• コンピューターサイエンスの学士号： プログラミングと開発に関する基礎的な理解を深め、デジタル製品のデザインをより効果的に行うことができる。

オンラインのデザインコースおよびワークショップ

• Coursera：プロダクトデザインに関する大学やカレッジのコースを提供している。
• Udemy： 特定のデザインツールやテクニックに関する短期間で実践的なコースに特化している。
• General Assembly：UX とプロダクトデザインに特化した集中ブートキャンプを提供している。
• Interaction Design Foundation：よりアカデミックなコースのための会員制プラットフォーム。
• IDEO： デザイン思考の組織の大手であり、様々な製品やデザイン関連のコースを提供している。

独学

プロダクトデザインのスキルを磨くのに役立つ本を以下にいくつか挙げてみましょう：

• スティーブ・クルーグ著「Don’t Make Me Think」
  （日本語版：超明快 Webユーザビリティ ―ユーザーに「考えさせない」デザインの法則）
  Webデザインにおけるユーザビリティの入門書。
• ドナルド・ノーマン著 「Design of Everyday Things」
  （日本語版：誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論）
  優れたデザインの基本原則を解説。
• アリステア・クロール, ベンジャミン・ヨスコビッツ著「Lean Analytics: Use Data to Build a Better Startup Faster」
  （日本語版：Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)
  商品と市場の適合性とデータ主導のデザインに関するインサイトを提供。
• ニール・イヤール著「Hooked:：How to Build Habit-Forming Products」
  （日本語版：Hooked ハマるしかけ 使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール）
  心理学とデザイン原理を融合させ、習慣的なエンゲージメントを生み出す製品をデザインする方法を伝授。

 プロダクトデザイナー のキャリアアップ

典型的なプロダクトデザイナーのキャリアパス

• ジュニア・プロダクトデザイナー： 一般的に、学校を卒業したばかり、または２年未満の経験者の出発点となり、主に指導下でデザイン業務を遂行する。
• 中堅プロダクトデザイナー： ３～５年程度の経験を積んだ中堅デザイナーは、より複雑なプロジェクトを担当し、専門性を高める。
• シニア・プロダクトデザイナー： ５～８年の経験を経て、デザインプロジェクトの指揮や後輩の指導、戦略的な決定にも関われるようになる
• リード・プロダクトデザイナー： 少なくとも８～１０年の経験が必要。大規模プロジェクトをリードし、デザインチームを監督することも多い。

プロダクトデザインにある専門分野

• UXスペシャリスト： ユーザーリサーチ と エクスペリエンスデザインを深く掘り下げ、アナリティクスやユーザー行動を熟知していることが求められる。
• UIスペシャリスト： 配色、タイポグラフィ、全体的な美しさなど、製品の視覚的要素に焦点を当てる。グラフィックデザインの経験があると有利。
• フロントエンド開発： コードを書くなど、技術的な側面を専門とするプロダクトデザイナーもおり、HTML、CSS、JavaScript の熟練したスキルが求められる。最新の製品開発には、React、Vue、Angular などのフロントエンド・フレームワークのスキルが含まれる。
• インタラクションデザイナー： 考え抜かれた動作で魅力的なインターフェースを作るのが専門であり、人間の心理や行動に対する深い理解が求められる。

プロダクトデザインのリーダーシップやマネジメントの役割とは

• デザインマネージャー： デザイナーチームの管理、プロジェクトの監督、上層部への報告を行い、多くの場合は、デザインスキルとマネジメントの専門知識の融合が求められる。
• デザインディレクター： 組織全体のデザイン戦略の設定と実行に責任を担い、経営陣の一員であることが多い。
• プロダクトデザイン副責任者： デザインに特化したトップレベルの経営陣の一人であり、リーダーシップと様々なプロダクトデザイン業務における豊富な経験と実績が求められる。
• コンサルタント／アドバイザー： 長年の専門知識を持つプロダクトデザイナーの中には、企業やスタートアップ企業のコンサルタントとして、プロダクトデザイン戦略の策定を支援する人もいる。

プロダクトデザイナーとしてネットワークを築き、メンターを見つける方法

ネットワークの機会

• 業界会議および会合： デザインに特化したイベントに参加して、業界のプロフェッショナルと出会い、見識を深める。自分の興味やキャリアの目標に沿ったカンファレンスに参加すると、最大限の効果が得られる。
• オンラインフォーラムとグループ：業界別の LinkedInやSlackのチャンネルなど、専門的なオンラインコミュニティに参加し、有意義なディスカッションに参加して知識を得たり、人脈を作ったりする。

プロダクトデザインのメンターを見つける

メンターは、業界の見識や実践的なアドバイス、教科書には載っていない貴重なフィードバックを提供してくれます。実社会の課題を通して導いてくれることで、速やかな成長が実現します。

既存のネットワーク、同窓会、LinkedIn の中で検索してみましょう。ADPList もメンター探しのお役立ちリソースです。相手の仕事に対する尊敬の念を示し、メンターシップに何を求めるかを明確に説明した、よく練られたメッセージを遠慮なく送ってみましょう。

プロダクトデザインの仕事に就くには

以下に挙げるプロダクトデザイナーの履歴書戦略は、Dribbble から拝借しました：

• 職務経歴書を見直し、不足している点を洗い出す： 職務経歴書に記載されている条件を満たすように履歴書を調整することで、より際立った履歴書を作成することができ、履歴書テンプレートに記載されていない特定のスキルや経験が見つかるかもしれない。
• 履歴書の形式（年表形式 か 職務経歴書形式 か）を選ぶ： 採用担当者は、キャリアの成長を示すために年代順の履歴書を好むが、エントリーレベルのポジションを狙うのであれば、学歴とスキルに焦点を当てた機能的なレイアウトの履歴書がいいと思われる。
• つまらなく思えるようなものにしない ‐ 自分のデザインスキルをアピールする： 標準的なPDF や Word 文書では、プロダクトデザイナーとして目立つには不十分。多くのプロダクトデザイナーは、プロフェッショナルな Web ベースのポートフォリオ（作品集）を使って、自分のスキルや経験をアピールしている。
• メトリクスを使う：デザインプロセスを主導した、またはデザインプロセスに大きく貢献したプロジェクトを紹介し、影響力を示すために、定量化可能な指標を使う。

UXPinのインタラクティブなプロトタイプで注目を集める

UXPinのインタラクティブなプロトタイプで、自身のプロダクトデザインスキルをアピールしましょう。多くのプロダクトデザイナーは、Figma や Sketch のような一般的な画像ベースのツールを選びますが、このようなプラットフォームには、基本的なプロトタイプを超える機能や特徴がありません。

その点、UXPinはコードベースのデザインツールで、最終製品のように見える完全にインタラクティブなプロトタイプを作成する機能を備えています。インタラクティブなプロトタイプへのリンクを履歴書に添付すれば、採用担当者に好印象を与えて、関心を持ってもらえる可能性が高まります。

UXPinの洗練されたツールと機能性で、一歩先を行く製品デザインスキルを身につけませんか？無料トライアルにサインアップして、インタラクティブなプロトタイプを作成しましょう。

The post これだけは知っておきたい！ プロダクトデザイナー になるには 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.