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

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

コードに触れることなく、コードベースのインターフェースを作成しませんか。関数コンポーネントをドラッグ＆ドロップでレイアウトできる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.

何百ものプログラミング言語がある中で、UX デザイナーやプロダクトデザイナーにとって、どれを理解してどれを学ぶべきなのかの判断が大変になることがあります。また、コードを学ぶのは UXデザイナーの仕事に欠かせないというわけではありませんが、技術的な制約の理解や、開発チームとの連携の向上につながることがあります。

そこで本記事では、UI/UX デザイナー向けの６つのプログラミング言語と、コーダーが１つを使う理由について説明します。そしてプログラミング言語やフロントエンドフレームワーク、コンポーネントライブラリの違いと、それらがデザインプロジェクトにどのような影響がもたらすのかについても見ていきます。

UXPin Mergeによって、コンポーネント駆動型プロトタイプにより、デザインプロジェクトをより高いレベルへと押し上げることができます。この画期的なUXテクノロジーへのアクセス方法と詳細については、こちらのページをぜひご覧ください。

プログラミング言語とは

プログラミング言語は、デベロッパーが Web サイトやアルゴリズム、デジタル製品を書くために使うコードであり、それぞれのプログラミング言語には、独自のマークアップ、ルール、構造、パッケージ・マネージャーなどがあります。

数百ものプログラミング言語がありますが、そのほとんどはプロダクトチームが触れることはないでしょう。ちなみに、重要なコーディング言語のリストを絞り込みましたので、これらをさらに調べたい場合には何から手を付ければいいかがわかります。

プログラミング言語が製品開発プロセスにもたらす影響

プログラミング言語は、製品の技術的制約を決定し、UX（ユーザーエクスペリエンス）のデザインプロセスを含などの製品開発に大きな影響を与えます。

デザインチームはその制限を理解していないと、プログラマーが構築できないソリューションや機能のデザインに時間を無駄に費やすことになるリスクがあります。

プログラミング言語は、最終的に UX に影響を与える他の製品開発の決定にも以下のような影響を与えます：

• 市場投入までの時間
• バックエンドの技術インフラ（予算とパフォーマンスへの影響）
• エンジニアの人材（人材の確保とコスト）
• APIと統合による機能性／拡張性

プログラミング言語とフロントエンドフレームワークの比較

「プログラミング言語」と「フロントエンドフレームワーク」をの識別は重要です。例えば、Javascript はプログラミング言語ですが、React、Angular、Vue はすべて Javascript のフレームワークです。

フレームワークはプログラミング言語を使って構築され、それによってソフトウェアエンジニアはオートメーションやツール、ライブラリ、機能、テンプレート、セッション管理などを得られ、ゼロからコーディングするよりも効率的に Web サイトやアプリケーションを開発することができます。

コンポーネントライブラリとは

コンポーネントライブラリは、コードのスキルが限られている人々にとって、さらなる混乱が加えられることになります。

コンポーネントライブラリは、エンジニアが UI（ユーザーインターフェース）の構築に使う既製の UI 要素を備えたデザインシステムのコードコンポーネントです。一般的な例としては、Google の Material Design UI に基づいて構築された React コンポーネントライブラリである MUI が挙げられます。

コンポーネントライブラリは、デザイナーにとっての、デザインツールで使われるベクターベースのグラフィック要素を集めた UIキットに当たります。それでもいまいちピンとこないであれば、こちらの記事でデザインシステム、パターンライブラリ、スタイルガイド、コンポーネントライブラリの違いが説明されています。

UX デザイナーが出会うプログラミング言語

これは、デザイナーはその背後にある個々のプログラミング言語よりも、フロントエンド フレームワーク（通常は Javascript ベース）やコンポーネントライブラリに遭遇する可能性が高いので、答えにくい問題です。これまで学んだように、これらはまったく別のものなのです。

なので、以下の２つのカテゴリーを作りました：

• プログラミング言語
• フロントエンドフレームワーク

プログラミング言語

ここでは、UX デザイナーがキャリアの中で遭遇する可能性の高い１つのプログラミング言語を見ていきます。

1. HTML

HTML とは HyperText Markup Language の略で、Web ブラウザで使われるマークアップであり、Web サイトや Web アプリの構築では、全エンジニアが学ばないといけない基礎的な言語です。フロントエンドフレームワークを使うか使わないかはさておき、Web ブラウザは常に HTML をレンダリングし、スタイリングやインタラクティブ性のために CSS や Javascript もレンダリングします。

UX デザイナーとして基本的な HTML を学ぶことは、フロントエンドのコーディングの基礎を理解する上では決して悪くありません。

2. CSS

CSS（Cascading Style Sheets）は、色、レイアウト、フォントなどでコンテンツをスタイル設定するのに使われるスタイルシート言語です。CSS がなければ、HTML によってレンダリングされる基本的なスタイルプロパティを備えた  Web サイトはどれも同じように見えるでしょう。

CSS は比較的わかりやすく、UI デザインに大きな影響を与えるため、UI デザイナーにとって非常に重要なもう一つの言語です。

3. Javascript

Javascript は、Web サイトや Web アプリケーションのもうひとつの中核となるインターネット言語であり、Web 開発において、HTML や CSS と並んでインタラクティブ性と機能性を提供することを主に担います。

また、Javascript は、React、Vue、Ember、Angular など、多くのフロントエンドフレームワークにも広く使われており、企業はこのようなフレームワークを使って、日々使われている Web アプリやモバイルアプリの多くを構築しています。

4. Java

Javascript と混同されがちですが、Java はソフトウェア大手のオラクルによって管理されているプログラミング言語で、主にエンタープライズアプリケーションの構築に使われており、スマートウォッチ、冷蔵庫、スマートTV、ウェアラブルなど、多くのハードウェアデバイスの動力源にもなっています。

5. PHP

PHP は、広く使われているコンテンツ管理システムである WordPress を支えるプログラミング言語として最もよく知られています。また、SNS の 一大勢力が React を開発する前は、初期の Facebook を支えたオリジナルの言語でもありました。

6. Python

Python もまた、Meta が Instagram のために使っている人気のフロントエンドプログラミング言語です。この言語は、無駄のないコードとあらかじめ組み込まれたアルゴリズムライブラリにより、AI（人工知能）や ML（機械学習）アプリケーションにも広く使われています。

Web デザインに最適な言語は？

Web デザインに便利なストレートスタックを以下で見てみましょう。

• HTML（Hypertext Markup Language）： 会社情報、製品/サービス、サインアップフォームを表示するセクションなど、Web サイトの構造を提供する。
• CSS（カスケーディング・スタイル・シート）： CS Sを使って HTML 要素をスタイル化することによって、Web サイトが視覚的に魅力的でまとまりのあるものになる。
• JavaScript： サインアップフォームのクライアントサイドのバリデーションに JavaScript を使って、ユーザーが有効なメールアドレスなどの必要な情報を確実に入力できるようにする。また、スムーズなスクロール、インタラクティブなアニメーション、通知の表示など、UX（ユーザーエクスペリエンス）を上げるのに JavaScript を使うこともできる。
• PHP（ハイパーテキスト・プリプロセッサ）または Node.js： サインアップ情報を収集および保存するバックエンド機能には、PHP または Node.js のいずれかを使うことができる。PHP は簡単で、フォーム送信の処理やデータベースとのやりとり、メールの送信によく使われ、対する Node.js は、よりモダンでスケーラブルなバックエンドソリューションを提供できる。
• SQL (Structured Query Language)： 集めたサインアップ情報を保存するデータベースとのやり取りには SQL を使う。

このスタックを使えば、メールとサインアップを効果的に集めるシンプルで機能的な企業 Web サイトを作成できます。まずは HTML と CSS を使ってレイアウトとスタイルをデザインし、JavaScript を使ってクライアントサイドのバリデーションとインタラクティブ性を実装して、最後に PHP または Node.jsと SQL を使ったデータベースを使って、サインアップデータを収集および保存するためのバックエンド機能をセットアップします。

フロントエンドフレームワークとは

本記事では、Web やモバイルアプリケーションでよく使われる４つの Javascript フレームワークに焦点を当てていきます。

そしてこのフレームワークは、UXPin Merge とも互換性があります。UXPin Merge は、デザイナーがデザインシステムから既製の UI コンポーネントを使って、完全に機能するプロトタイプを構築できるようにする技術です。詳しくは Merge のページをぜひご覧ください。

1. React

React は、Web アプリケーションとモバイルアプリケーション（iOS および Android）を開発するための一般的な Javascript フレームワークです。‐ ただし、組織では通常、後者に React Native が使われます。 また、コンポーネントベースのマークアップとクロスプラットフォーム アプリケーションを作成する柔軟性により、世界中の製品開発で人気の選択肢となっています。

2. Ember

Ember は Web アプリケーションを構築するための Javascript フレームワークであり、Netflix、Square、LinkedIn、Twitch など、多くの人気アプリで Ember が使われています。

3. Angular

Google によって開発および維持されている Angular は、クロスプラットフォームアプリケーションの構築向けの広く使われているフレームワークであり、このフロントエンドフレームワークを使っているプラットフォームのほんの一部を挙げると、PayPal、GMail、Upwork、Forbes の Web サイトがあります。また、Angular のすぐに使えるインタラクティブ性と機能性により、このフレームワークは複雑なアプリケーションに人気があります。

4. Vue

Vue は、シングルページの Web アプリケーションを構築するための Javascript フレームワークです。HTML を包含することができるため、HTML、CSS、Javascript のコーディングスキルがある人にとって習得しやすいフレームワークとなっており、優れたパフォーマンスと、アプリケーションを拡張するための包括的なエコシステムもあります。

プログラミング言語を使うメリット

デザインやプロトタイプのプロセスでプログラミング言語を使うことは珍しいことではなく、デザイナーはコードを使ってライブデータのプロトタイプを作成し、それで最終製品のユーザー体験を正確に再現することができます。

そしてこのようなコードプロトタイプにより、デザイナーは最終製品と同じ忠実度と機能性で機能をテストできるため、より質の高い結果とフィードバックが得られます。

ただ、プロトタイプとテストにコードを使う際に、デザインプロセスに時間がかかったり、貴重なリソースではあるけれどプロジェクトのコストが増えてしまうフロントエンドデベロッパーや UX エンジニアのスキルが要ることなどの問題があります。

なので、組織は複雑なユーザビリティの問題を解決するのにコードプロトタイプを準備したり、大体はリソースを節約するのに単一の画面やユーザーフローを構築します。

UXPin Merge – コードをレンダリングするデザインツール

UXPin Merge のようなコードベースのデザインツールを使えば、デザイナーはコードを一行も書かずに（コードを書く場合と）同じ結果を得ることができます。Mergeでは、デザインチームがレポジトリから UXPin のエディタにデザインシステムを同期できるため、デザイナーとエンジニアはデザインおよび開発プロセスで同じ UI 要素を使うことができるのです。

Merge は React、Vue、Ember、Angular など、多くの一般的なフロントエンドフレームワークで動作します。デザイナーは他のデザインツールでこのようなコンポーネントを使いますが、それはデザインシステムによって定められたステート、アニメーション、およびプロパティがあらかじめ用意されています。

より速やかなプロトタイプ、よりよい連携

コンポーネント駆動型のプロトタイプは、デザイナーが UI のエレメントを一からデザインするのではなく、UI を構築することだけに集中するため、画像ベースのデザインよりも圧倒的に速くなります。

そしてこの「信頼できる唯一の情報源（Single source of truth）」により、みんなが同じ言語を話して同じ制約内で作業するため、デザイナーとデベロッパーの連携が強化されます。また、Merge でのデザインハンドオフはシームレスで、エンジニアに同じコンポーネントライブラリがあるため、ほとんど存在しません。UXPin  からのデザインを一致させるだけですからね。

拡張可能（スケーラブル）

Merge だと、パターンによるコンポーネントライブラリの拡張と成熟がしやすくなります。デザイナーは複数の要素を組み合わせて、新しい UI コンポーネントやパターンを構築でき、デザインシステムに必要なものがない場合は、UXPin の npm 統合を使ってオープンソースライブラリからコンポーネントをインポートし、新しいパターンを構築できます。

テストの強化

Mergeを 使うことで、デザインチームは最終的な製品体験を正確に再現する没入型のダイナミックなプロトタイプを作成し、ユーザーテストやステークホルダーからの有意義なフィードバックを得ることができます。

デザインチームはステークホルダーにプロトタイプへのリンクを送り、UXPinのコメント機能を使って実用的なフィードバックを受け取ることができます。また、ステークホルダーは、特定のチームメンバーにコメントを割り当てることもできます。

「UXPin を使うことで、ステークホルダーはかなり速やかにフィードバックを提供できるようになります。また、UXPinを使うことで、プロトタイプに対して直接コメントを提供することができます。」Erica Rider, PayPal – Senior Manager for UX – Developer tools and platform experience at PayPal

UXPin Merge を使うと、デザインチームはプログラミング言語の習得や、プロトタイプ中のエンジニアとの共同作業を行ったりしなくても、コードの恩恵を受けることができます。この画期的なテクノロジーと、それがエンドツーエンドの製品開発プロセスをどのように改善するかについて、UXPin Merge のページでぜひ詳しくご覧ください。

The post 【UI/UX デザイナー向け】プログラミング言語とフレームワークガイド 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.

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

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

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デザイナーは、ビジネスゴールやデザインの調整、プロセスの最適化、ユーザーのニーズに合った製品をつくることが求められます。そのためには、チームや部門、ステークホルダーといかに効率的に連携できるかが肝心です。

効率的に連携できることで、デザイナーのネットワーキングスキルが向上し、優れたUX（ユーザーエクスペリエンス）が実現できることから、組織でのUXの重要性が明確になります。

UXPinでインタラクティブで高度なプロトタイプを作成して、製品開発プロセスの部門横断的なコラボレーションの効率化と連携を強化しましょう。

また、UXPinで作った高忠実度なプロトタイプをチームで共有し、１つのツールだけでデザインハンドオフを行うことができます。

機能やプランに関しての詳細は、こちらのページをご覧ください。

UXデザイナー向け「 部門横断型 連携 」の重要性

製品開発がますます複雑化するなかで、一貫性のあるユーザー中心の体験を提供するには、UXデザイナーと組織、チームの連携が鍵になります。

また、連携がうまく取れることによって、デザインをビジネス目標の整合、プロセスの効率化、ユーザーのニーズや期待に応えることができる “良い製品” につながります。

組織内の「効果的」な連携における目標と利点：

• 製品開発の加速：上手く連携しているチームは業務効率化、市場投入までの時間短縮、ユーザーの要求に対する応答性の向上が実現する。
• イノベーションの強化：多様な視点によって創造性を生み、革新的なソリューションにつながる。
• より良い意思決定：複数のステークホルダーからの意見を聞くことで、より良い結果を出すことができる。デザイン上での問題の削減、手戻り防止につながる。
• より高い適応性：ユーザーのニーズや市場環境の変化に効果的に対応し、製品の一貫性と競争力を維持することができる。
• 従業員のエンゲージメントの向上：連携によって当事者意識や仲間意識、仕事への満足感が育まれ、生産性の向上や離職率の低減につながる。

組織構造が 部門横断型 連携に与える影響

以下で、典型的な４つのUXチームの構造と部門横断型 連携における影響です：

1. 一元型：他のチームと接する機会が少なく、サイロ化に繋がる可能性がある。デザイナーが各プロジェクトや部門固有の要件や制約を理解しづらくなることがある。
2. 組込型：：デザイナーが特定のプロジェクトや部署に集中しすぎるあまり、組織のより大きなデザイン目標や一貫性が見失われる可能性がある。
3. 分散型：デザインチームが組織内に分散してる場合、作業調整やデザインの一貫性の維持がしにくい。潜在的なズレや矛盾を引き起こす可能性がある。
4. 契約型：（派遣などの）契約によって雇われているデザイナーだと、組織内のリソース、知識、コミュニケーションチャネルに同じレベルでアクセスできない場合がある。社内チームやステークホルダーとの効果的な連携がしづらい。

デザイナーの連携相手とは？

成果を上げてイノベーションを促進させるには、UXデザイナーは組織のさまざまなステークホルダーとの連携が必要です。

そのうえ、効果的な連携を行うために製品開発プロセスにおける各役割の貢献度を理解することが不可欠です。

UXデザイナーの主な連携相手は以下の通りです：

• プロダクトマネージャー：デザイン目標を製品戦略、優先順位、ビジネス全体の目標と整合させる。
• デベロッパー：技術的な制約や可能性を考慮しながら、デザイン実装が正確かつ効率的であるよう緊密に連携する。
• マーケティング部門：ユーザーデータを充実させ、ターゲットを絞ったインパクトのあるマーケティングキャンペーンを作成するために、連携してユーザーリサーチ、ペルソナ、ユーザージャーニーを行う。
• セールス部門：顧客のニーズ、好み、ペインポイントに関する貴重なフィードバックとインサイトを集め、デザインの意思決定に活かす。
• カスタマーサポート部門：ユーザーとのやりとりを活かして問題に対処し、製品体験の向上に使えるフィードバックを集める。
• QA（品質保証）部門：製品発売前に、デザインがユーザビリティ、アクセシビリティ、性能の基準を満たしているか確認する。
• 幹部ステークホルダー：デザインの目標、進捗、結果を伝えることで組織の意思決定者の賛同と支持を得る。

 部門横断型 連携におけるDesignOpsの影響

DesignOps（デサインオペレーション）とは、組織のデザインプロセスとワークフローを効率化する戦略的アプローチであり、デザインチーム、ステークホルダー、その他の部門間のリソース、ツール、コミュニケーションを最適化します。

DesignOpsを導入することで、組織では創造性、革新性、効率性をサポートできる連携環境が育まれることから、デザインチームは高品質でユーザー中心の製品を確実に提供できるようになります。

DesignOpsによるコミュニケーションとチームワークの向上

DesignOpsは、連携のための明確なチャンネル確立や期待値の設定、役割と責任を明確にすることによって、コミュニケーションとチームワークを促す重要な役割します。

DesignOpsの目的としては、プロセスの標準化、効果的なコラボレーションのためのツールの提供、デザイン目標とビジネス目標の整合、そしてデザイナー、デベロッパー、ステークホルダー間のギャップを埋めることです。

これらによって、部門横断チームが円滑に連携できるようになり、より良い意思決定、製品の品質向上、イノベーションの拡大につながります。

DesignOpsによる連携の促進

DesignOpsを効果的に実行するには、組織はまず現在のデザインプロセスを評価して非効率な部分を特定し、連携のための明確な目標を設定しないといけません。

次に、効果的な連携をサポートするのに必要なツール、プロセス、コミュニケーションチャネルをまとめた計画を作成します。

ここには、チームワークと連携を促すための定期的な機能横断的会議、デザインレビュー、ワークショップなどが含まれます。

さらに、組織はプロジェクトのタイムライン、製品品質、従業員満足度などのKPI（主要業績評価指標）の追跡によって、DesignOps 導入がうまくいっているかをモニタリングする必要があります。

DesignOpsのアプローチを継続的に改良・調整することで、組織は製品の成功を促すコラボレーション文化を築くことができるのです。

部門横断チームにとってのデザインシステムの役割

デザインシステムで連携を効率化する方法

デザインシステムは、一元化された、包括的で一貫性のあるガイドライン、コンポーネント、パターンのセットを提供することで、  部門横断型 チームの連携が効率化されます。

また、デザイン言語を共有することで、デザイナー、デベロッパー、その他のチームメンバーが一体となって効率的に作業することができます。

これによって、意思疎通の行き違いがなくなり、反復作業も減らすことができます。

また、デザインシステムは製品やプラットフォーム間で一貫したUXを提供し、統一されたブランドアイデンティティを構築します。

デザインシステムを活用することで、チームはブレーンストーミング、イノベーション、問題解決に集中することができ、より良い成果とUXをもたらすことにつながります。

組織内のデザインシステムの確立と維持

デザインシステムを構築する際には、機能横断的なチームの参加が非常に重要です。

このような連携のアプローチにより、デザインシステムは全ステークホルダーのニーズを確実に満たし、ビジネス目標に沿うことができます。

まずは既存のコンポーネント、パターン、ガイドラインをドキュメント化することから始め、デザイナー、デベロッパー、その他のチームメンバーから意見を聞きながら、反復的なプロセスで改良していくのがいきましょう。

デザインシステムを導入したら、その効果を継続的に評価し、フィードバックを取り入れ、組織の進化するニーズに適応させることで、最新かつ適切な状態を維持することが非常に重要です。

メンテナンスと定期的なアップデートを優先することで、デザインシステムは部門横断型チームの連携に対応し、製品を成功に導く貴重な資産であり続けることができるのです。

デザインプロセスの様々な段階での連携

研究・発見

「研究・発見」の段階では、UXデザイナーはステークホルダーや専門家と連携し、プロジェクトに関する重要な情報を集めないといけません。

この連携によって、ユーザーニーズ、ビジネス要件、業界トレンドに関する貴重なインサイトが得ることができます。

また、ユーザーや他のチームと関わることによって、デザイナーは問題点、改善の機会、解決策の可能性を見出すことができます。

オープンなコミュニケーションを育み、多様な視点を積極的に取り入れることで、デザイナーはデザインプロセスを通じて、情報に基づいた意思決定を行うための強固な基盤を築くことができるのです。

デザインとプロトタイプ段階

「デザインとプロトタイプ」の段階においてまとまりのある機能的な製品を作るには、UXデザイナー、デベロッパー、その他のデザインチーム間の効果的な連携が不可欠です。

共に作業することによって、チームは技術的な制約や実現可能性を考慮しながら、ビジネス目標やマーケティング戦略に沿ったデザインコンセプトを実現することができます。開かれたコミュニケーションチャネル、定期的なデザインレビュー、共有ツールによってスムーズな連携ができるようになることから、チームはデザインアイデアの反復、潜在的な問題への対処、全体的な UXの改良ができるのです。

ユーザーテストと検証

最終製品が確実にユーザーのニーズと期待に応えるようにするには、「ユーザーテスト・検証」の段階が非常に重要です。この段階でユーザー、テスター、プロダクトマネージャーと連携することで、UXデザイナーは必要なフィードバックを集め、改善のための領域を特定することができます。

ステークホルダーと積極的に関わることで、デザイナーはフィードバックをプロトタイプに反映させ、修正の優先順位をつけ、データに基づいたデザインの意思決定を行うことができます。このような協力的なアプローチにより、最終的にはユーザーとビジネスの目標に沿った、よりユーザー中心の成功する製品を生み出すことができるのです。

デザインハンドオフとスムーズな連携

効果的なデザインハンドオフの重要性

デザイン段階から開発段階へのスムーズな移行を実現するには、効果的なデザインハンドオフが不可欠です。ハンドオフがうまく行われることによって、意思疎通のすれ違いが最小限に抑えられ、プロジェクトの遅延が減り、不要な手戻りを防ぐことができます。

デザイン仕様を明確に理解することで、UXデザイナーとデベロッパーはより効率的に連携でき、ユーザーのニーズを満たし、ビジネス目標に沿ったより質の高い製品を生み出すことができるのです。

ハンドオフを成功させるためのベストプラクティス

デザインハンドオフを成功させるために、デザイナーとデベロッパーは連絡と連携を促すベストプラクティスを採用すべきです。

デザインコラボレーションプラットフォームやバージョン管理システムなどのツールやテクノロジーを活用することで、ハンドオフプロセスが効率化され、エラーの可能性を下げるといいでしょう。

さらに、カラーパレット、タイポグラフィ、レスポンシブレイアウトなど、デザイン仕様に関する明確なドキュメントとガイドラインがあれば、デベロッパーは意図したデザインを正確に理解して実装できるようになります。

このようなベストプラクティスに従うことで、チームはハンドオフプロセスの全体的な効率と効果を大幅に上げることができるのです。

デザイナーとデベロッパーの強固な関係を築く

製品開発プロセスにおいて、連携をうまくいかせるには、デザイナーとデベロッパーの良好な関係構築が不可欠です。

オープンなコミュニケーション、相互尊重、共感を育むことで、デザイナーとデベロッパーは互いの視点、制約、目標をより理解することができるでしょう。

また、定期的なミーティング、意思決定の共有、共同での問題解決は、チームメンバー間の信頼と親密さを築き、よりまとまりのあるいい製品に繋がります。

このような関係に投資することで、組織で 部門横断型 の連携を促す環境が作られ、最終的にユーザーとビジネスの成果を上げることができるのです。

効果的な 部門横断型 チームのためのヒント

• チームメンバーとの信頼関係構築：チーム構築の活動に参加し、各メンバーの役割、強み、課題を理解するよう努め、協力的な環境を育みましょう。
• オープンなコミュニケーションとフィードバックを促す：最新情報を共有や、課題についての話し合い、および建設的なフィードバックの提供のためにチームメンバーとの定期的なミーティングやタッチポイントを設けることで、透明性と継続的な改善という文化を育みましょう。
• コラボレーションツールやソフトを活用する：Trello、Slack、UXPin のコメント機能などのプロジェクト管理、コミュニケーション、デザインコラボレーションツールを活用して、ワークフローの効率化、コミュニケーションの向上、誰もが関連するUXリソースへの自由なアクセスを実現しましょう。
• 連携力を継続的に高める：連携、連絡、チームワークに焦点を当てたワークショップ、ウェビナー、会議に参加し、多様なチームと効果的に仕事をして、多様なワークスタイルに適応する能力を高めましょう。
• UXとユーザーを提唱する：ユーザーリサーチの結果、インサイト、成功事例をチームやステークホルダーと共有し、ユーザー中心のデザインの重要性に対する認識を高め、ビジネス目標達成におけるUXの価値を実証しましょう。

UXPin Merge – 至高のコラボレーションツール

UXPin Mergeは、デザインシステムとフロントエンド開発のギャップを埋めることで、デザイナー／デベロッパーの連携を促進します。

このギャップを埋めることで、UXPin Mergeでは誰もが「同じ言葉を話し」、デザインシステムと製品のコードによって定義された同じ制限と制約の中で作業できるので、より良いコラボレーションを促します。

UXPin Mergeの「信頼できる唯一の情報源（Single source of truth）」で、製品開発のプロセスを効率化し、チームの連携を強化してみませんか？

詳細とアクセスリクエスト方法については、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.

デザイン会社の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.

組織がデザインプロセスを効率化し、連携を強化しようと努力する中で、DesignOpsは『デザイン目標』と『ビジネス目標』を一致させるための基盤としての役割を果たします。

UXPinは最近、３人の DesignOps エキスパートによるウェビナー「Strategies for Building Resilient DesignOps Practice（レジリエントな DesignOpsプラクティス構築のための戦略）」を開催し、そこでは貴重なインサイトと戦略が得られました。

ウェビナーでは、以下の３人の業界専門家によるパネルディスカッションが行われました：

• Salomé Mortazavi氏：SiriusXM社の DesignOpsおよびデザインシステム担当シニアディレクター
• Meredith Black氏：豊富な経験を持つDesignOpsコンサルタント
• Adam Fry-Pierce氏：Google社のUXリーダーシップ担当チーフスタッフ

知識が豊富なこの三方からユニークな視点と経験がもたらされ、DesignOpsにおける課題と機会について議論されました。

UXPinの「信頼できる唯一の情報源（Singoe source of truth）」で、効率的なタスク管理とワークフローを実現します。アクセス方法については、Merge のページをぜひご覧ください。

デザインチームの真のニーズを突き止める

レジリエントな DesignOps のプラクティスを構築するには、デザインチームの真のニーズを理解し、それに対処することが非常に重要です。デザインチームが直面する基本的な課題の１つに、デザインと全体的なビジネス戦略との整合性の欠如があり、この不整合はデザインプロセスを阻害するような、非効率性やコミュニケーションのギャップ、そしてリソース制約につながってしまいます。

共通のビジョン作り

デザインチームのニーズに対応するための極めて重要なステップは、共通のビジョンの作成であり、このビジョンの共有には、デザインチームの目標をビジネスの幅広い目標と一致させることが含まれます。組織内でのデザインの役割について共通の理解を確立することで、チームはより結束して効果的に働くことができるのです。

デザインチームのビジョンのステートメントの作成についてはこちら。

ワークフローの効率化

デザインチームをサポートするもうひとつの重要な側面は、ワークフローの効率化です。デザインチームは、断片化されたプロセスによるボトルネックや非効率によく遭遇します。そこで DesignOps が、ワークフローを効率化することで効率性を上げ、連携しやすい環境を促進することで、デザインチームがこのような課題を克服できるよう支援します。

デザインシステムの導入

デザインシステムの導入は、コミュニケーションギャップやリソースの制約に対処する効果的な方法です。デザインシステムは、さまざまなデザインプロジェクト間で一貫性を保つことができるような一連の基準とガイドラインを提供し、それによってチームメンバー間のより良い連絡と連携が促進されます。

ロードマップと成熟度モデルの整合性

ロードマップを成熟度モデルと整合させることは、デザインプラクティスの現状評価や改善領域の特定などのデザイン計画のプロセスにおいて有益です。デザインチームは、ロードマップを成熟度モデルと整合させることで具体的なマイルストーンと目標の達成に焦点を当てた取り組みを行うことができますからね。

こちらもチェック： UXPin Merge 顧客事例『Iress』：デザインツールの再想像

DesignOps のプラクティスを適切なサイズにする

DesignOpsのロードマップを組織の成熟度モデルと整合させるなど、デザインチームの特定のニーズと成熟度に合わせて運用を調整するには、DesignOps のプラクティスを適切なサイズに調整することが非常に重要です。

成熟度モデルの使用

効果的なアプローチの１つは、デザインリーダーシップチームが集まって定性的な課題やニーズ、目標について議論することによって、成熟度モデルを中心にDesignOpsロードマップを調整することです。成熟度モデルで、重点領域の概要や、テーマの特定および優先順位付けができるようになります。この調整によって、確実にDesignOpsが組織の成熟度に沿った具体的なマイルストーンと目標の達成に重点的に取り組めるようになります。

記事を読む：DesignOps の成熟度確認のためのチェックリスト

企画におけるインクルーシブデザインの提唱

もうひとつの重要な側面は、組織の企画（プランニング）のプロセスにおけるインクルーシブデザインの提唱です。デザインが主要な企画要素として認識されていないことがあるため、この認識を変えるにはデザインチームによる提唱が必要です。デザインを提唱してその価値を示すことで、DesignOps が組織の企画と意思決定プロセスにおいて、確実にデザインが重要な考慮事項となるようにすることができるのです。

内部統制とチームの成長

組織の目標に合わせるだけでなく、デザインチームのニーズに社内で焦点を合わせることが重要となります。この連携には、チームがどのように成長できるかの評価やデザイナーに開発の見通しを示す方法が含まれます。また、デザイナーが同じタイプのプロジェクトで行き詰まることもあり、彼らの成長と発展に貢献する多様な機会を提供することは非常に重要です。

デザインチームワークに関する電子書籍を読む： DesignOps First Pillar: How We Work Together.（DesignOps の第一の柱：協働の方法）

重要な部門横断的パートナーシップの特定と確立

DesignOps がうまくいくには、重要な部門横断的パートナーシップの確立が不可欠です。このようなパートナーシップによって、デザイン業務は確実に組織内の他のチームや部門の目標やインセンティブと一致できるようになります。

目標と動機の理解

部門横断的パートナーシップを確立するための重要な側面のひとつは、パートナーの『目標』と『動機』を理解することであり、さまざまなチームや部門には、それぞれの行動の原動力となる明確な目標と動機があることを認識することが非常に重要です。

この「目標」と「動機」を理解することで、DesignOps は他のチームの取り組みと連携し、共通の組織目標に向かって取り組むことができます。そしてこの連携は、DesignOps が確実により広範な組織目標と統合して、単独で運営されることがないようにするのに欠かせません。

緊急性と重要性のバランス

部門横断的なパートナーシップを確立する上でもうひとつ重要なことは、緊急性と重要性のバランスをとることです。文化を構築し、デザイナーをつなげることに力を注ぐのは重要ですが、緊急性が優先されることが多いことを認識しておくことも極めて重要です。DesignOps は、効率性を確保しながら、デザイン組織の価値を上げることに重点を置かないといけないのです。

DesignOps の規模および範囲

機能横断的なパートナーシップを確立する際には、さまざまなチームの固有のニーズを評価し、そのニーズを満たすための DesignOps の適切な規模と範囲を決定するなど、DesignOps の規模と範囲の考慮も不可欠です。

出だしに余裕を持ってチームや組織のニュアンスを理解することで、どのような種類のサポートやリソースが必要かを特定することができます。この体系的なアプローチによって、DesignOps は組織固有のニーズに合わせて確実に調整されるのです。

測定とインパクト：DesignOps のROIを説明する方法

インパクトを測り、DesignOps の ROI （投資収益率）を示すことは、組織内でその役割を説明し、デザインと部門横断チームに価値をもたらす重要な側面に焦点を当てるのに非常に重要です。

インパクトへの焦点

DesignOps を測る上で欠かせない側面の１つは、インパクトへの焦点です。DesignOps の実践者は、すべてをやり遂げたいという衝動を抑え、代わりに最も重要なことに集中しないといけません。DesignOps チームの規模とインパクトは必ずしも一致しないことを認識しておくことが重要であるため、低コストでも見返りの大きい取り組みに集中することが非常に重要です。

土台作り

DesignOps にレイヤーを追加する前に、デザインと部門横断チームの価値を促進する本質的な側面に焦点を当てることによる、強固な基盤構築が必要です。この土台を築いて組織からの賛同が得られたら、DesignOps が提供する中核的な価値を損なわないように注意しながら、追加のレイヤーを追加し始めることができるのです。

内部拡張と乗数

緊縮財政の時代には、創意工夫を凝らして取り組みの規模を拡大することが極めて重要です。これは必ずしも人員を増やす必要はありませんが、DesignOps に関心のあるマネージャーやリーダーとの提携が必要になる場合があります。また、同様にこれらに関心のあるデザインリードの機会を引き出すことにもつながるかもしれません。このような内部乗数は、必ずコストを増やすというわけではなく、取り組みを強化させることができるのです。

デザイナーの DesignOps 参加

DesignOps を拡張するもう１つのアプローチとして、デザイナーの DesignOps への参加があります。多くのデザイナーは、気づかないうちにすでにDesignOps 活動を行っているかもしれません。このようなデザイナーにDesignOps での役割を割り当てることで、組織はデザインへの理解を通して、 DesignOps の価値を上げることができます。

スコープの影響：コストセンターと収益源 – 管理範囲内のメトリクス

DesignOps の影響をスコープする際には、コストセンター（原価中心点）と収益源を通してビジネスニーズに焦点を当てることが不可欠であり、このスコープには、機能横断的な強固なパートナーシップの確立や、DesignOps の管理範囲内のメトリクスへの注力が含まれます。

ビジネスニーズへの焦点

ビジネスに価値をもたらす重要な側面を特定し、その側面に取り組みを集中させることは、影響範囲に不可欠です。DesignOps にできることがたくさんある一方で、ビジネスに最も大きな影響を与えるものに集中することが、最も大きな価値と ROI を生み出すということを認識しておくことが重要です。

部門を超えたパートナーシップの確立

強力な部門横断的パートナーシップを確立するということは、エンジニアリング、製品、技術プログラムマネージャなど、組織内の他の部門や機能との関係を築くということです。このようなパートナーシップにより、DesignOps は組織の広範なゴールと連携で、達成につながることができるのです。

投資としての人間関係

機能横断的なパートナーと個人的な関係を構築することで、DesignOps は他部門や機能の目標やニーズをよりよく理解できるようになり、DesignOps の管理範囲内のメトリクスに焦点を当てながら、調整して取り組むことができます。

時代の変化への対応

DesignOps は、たとえ緊縮財政の時代であっても、回復力性（ レジリエント ）があり、成長と発展の機会を模索することで、変化に機敏に適応できないといけません。柔軟で、回復力があることでDesignOps は世の中が変化しても、ビジネスに価値をもたらし続けることができるのです。

DesignOps × ChatGPT含む生成系AI

DesignOps のコンテクストでは、AI（人工知能）や ChatGPT のような生成系モデルは、デザインプロセスを大幅に効率化し、生産性を上げてくれます。その方法を以下に挙げてみましょう：

ルーティンタスクの自動化

AI はデザインプロセスにおけるルーティンワークや繰り返し作業を自動化し、それによってデザイナーはより複雑でクリエイティブな作業に集中できるようになります。例えば、DesignOps の実務者は、AI を使って、事前に確定されたルールやガイドラインに基づいて、デザインアセット生成、UI（ユーザーインターフェース）コンポーネント、さらにはレイアウト全体を自動化することができます。

迅速なプロトタイプ

生成系 AI モデルは、特定の入力に基づいてデザインコンセプトを生成することで、迅速なプロトタイプを支援することができます。AI を活用することで、デザインのアイデア出しやコンセプト開発の段階のスピードが大幅上がり、デザイナーはより短時間で幅広いアイデアを検討することができるのです。

ユーザー調査とデータ分析

AI は、ユーザー調査やデータ分析の支援もします。例えば、AI はユーザーの行動データを分析してパターンや傾向を特定し、デザインの意思決定に有益で貴重なインサイトを提供することができます。また、DesignOps は 、ユーザーテストを実施してフィードバックを集めることでユーザーの反応を集めて分析するような、時間のかかるプロセスを AI を使って自動化することもできます。

連携の強化

ChatGPT のような AI モデルは、アイデアを生み出し、フィードバックを提供し、様々なタスクを支援する仮想チームメンバーとして機能することで、連携を改善することができます。そしてこの AI アシスタントは、特に遠隔地や分散した作業環境において、デザインチームの効率性と生産性を上げることができます。

UXPin Merge テクノロジーでデザインワークフローのギャップを埋め、デザイナーとデベロッパーの連携を強化してみませんか？組織全体で「信頼できる唯一の情報源（Single source of truth」）を持ち、ドリフト排除、市場投入までの時間短縮、１つのツールで負債の最小化を実現しましょう。詳細は こちらのページをご覧ください。

The post レジリエント な DesignOps – 実践のためのヒント appeared first on Studio by UXPin.

新しいプロジェクトの開始時に企業が考えることの一つとして、「コンポーネントライブラリを採用するか、ゼロから始めるか 」というのがあります。メリット・デメリットの比較検討が必要であり、プロジェクトの範囲と優先順位の考慮も必要です。 その際に最も人気のあるコンポーネントライブラリの1つがMUIで、GoogleのMaterial Design UIを最初にモデル化された包括的なReact UIライブラリです。

今回はMUIについてみていきましょう、なぜMUIを使いたいのか、他のコンポーネントライブラリとの違いは何か、そして次のプロジェクトのデザインの始め方ついてお話します。 コードでデザインってどんな感じだろう、と思ったことはありませんか？

UXPin Mergeは、コードコンポーネントをレポジトリからUXPinのエディタに同期させる画期的な技術です。この強力なツールにより、デザイナーは一行のコードも書かずに、きちんと機能するコードベースのプロトタイプを作成することができます。Merge の詳細と、次のプロジェクトのためのアクセス要求方法についてご覧ください。

また、UXPinのトライアルでは、コードコンポーネントを使ったデザインがどんな感じか試すことができ、トライアル中にMUI 5キットを用意していますので、MUIを間近で体験することができます。14日間の無料トライアルに登録して、MUIをぜひご利用ください。

MUI とは

MUIは、デザイナーやデベロッパーがReactアプリケーションを構築するのに使えるUIコンポーネントの巨大なライブラリです。このオープンソースプロジェクトは、コンポーネント作成のためのGoogleのガイドラインに従っており、基礎的なUI要素と高度なUI要素のカスタマイズ可能なライブラリが備わってます。 また、MUIはReactのテンプレートやツールを販売しており、プロジェクトに合わせて微調整できる既成のユーザーインターフェースがあります。

MUI のような コンポーネントライブラリ を使う理由

デザイナーは、新製品の開発や既存プロジェクトの機能追加にUIキットを使用することがよくありますが、これらのライブラリにより、デザイナーは必要なコンポーネントをドラッグ＆ドロップして、さっとインターフェースのデザインができます。

MUIコンポーネントライブラリを使用する7つの理由を探ってみましょう。

1. 市場投入までの時間を短縮

競争の激しい今日のテク環境において、市場投入までの時間は、企業が常に最適化を求めるメトリクスとなっています。コンポーネントライブラリを利用することで、デザイナーやデベロッパーは、すぐに使える徹底的にテストされたUI要素で、大きな幸先のいいスタートを切ることができます。

デザイナーは、要素をドラッグ＆ドロップしてユーザーインターフェースを構築し、製品やブランドの要件に合わせてコンポーネントをカスタマイズすることができます。

デザインチームは、UIコンポーネントをゼロから構築してテストすることに煩わされることなく、優れたカスタマーエクスペリエンスのデザインにより多くの時間を費やすことができ、市場投入までの時間が大幅に短縮されます。

デザイナーがプロトタイプの作成、テスト、反復を速くできるため、ユーザビリティテストはずっと速くなります。テスト中にユーザーインターフェースがうまく機能しない場合は、膨大なライブラリからその場で変更を加え、参加者やステークホルダーから即座にフィードバックを得ることができます。

デザインハンドオフでは、エンジニアはコンポーネントライブラリをインストールし、プロトタイプやスタイルガイドからの変更をコピー＆ペーストすることで、ゼロから始めることなく製品を開発することができます。

2. 信頼できる唯一の情報源（Single source of truth）

信頼できる唯一の情報源（Single source of truth）の維持は、デザインシステムのガバナンスにおける最大の課題の1つです。製品チーム、UXデザイナー、およびデベロッパーが、同期していないデザインシステムを使用していることは珍しいことではなく、その結果、エラーや再作業が発生し、DesignOpsは大きな課題に頭を抱えることになります。

MUIのコンポーネントライブラリを使用することで、デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成しながら、こういった課題を大幅に減らすことができます。デザイナーとエンジニアは別々のデザインシステム（デザイナーは画像ベース、エンジニアはコードベース）を持つことになりますが、MUIは彼らに同じスタートブロックを提供します。

UXPinのコードベースエディターでMergeを使用すると、デザイナーとエンジニアは同じデザインシステムのコンポーネントを単一のレポジトリで同期して使用します。レポジトリが更新されると UXPin に同期され、デザイナーに変更点が通知されます。Reactコンポーネント ライブラリにはGitを、その他の一般的なテクノロジーにはStorybookを使用してMergeを接続できます。

3. デザインの一貫性

一貫性は、ユーザーエクスペリエンス、信頼の構築、ブランドロイヤリティには欠かせません。同じUIコンポーネントを使用することで、デザイナーは一貫性を高め、エラーや手戻りを最小限に抑えることができます。

4. 拡張性

拡張性もまた、製品デザインの重要な要素です。ゼロからデザインシステムを構築する場合、デザイナーは製品をスケールアップする前に、新しいコンポーネントのデザイン、プロトタイプの作成、テストが必要です。

MUIの包括的なUIライブラリにより、デザイナーはプロトタイプに必要なコンポーネントを検索して、すぐに拡張することができ、エンジニアは、MUIから同一のReactコンポーネントをコピー＆ペーストし、デザイナーの仕様に合わせてカスタマイズできます。

MUI Xには、データグリッド、日付ピッカー、チャート、ページネーション、フィルタリングなど、複雑な製品をより速く拡張するためにチームが使用できる高度なReactコンポーネントのライブラリが含まれています。

5. 容易なメンテナンス

MUIのようなコンポーネントライブラリには、コンポーネントのインストール、使用、更新、カスタマイズのための詳細なドキュメントが付属しています。デザイナーやエンジニアは、このフレームワークを使って企業のデザインシステムの維持ができ、ガバナンスシステムやプロトコルを簡単に確立することができます。

また、MUIには、あるバージョンから次のバージョンへの移行のためのハウツーガイドもあるので、企業はMUIがアップデートをリリースするたびに、最新のUIスタイル、テクノロジー、トレンドを利用できます。

6. アクセシビリティ

デザインシステムを設定した経験のある方は、すべてのコンポーネントがアクセシビリティ基準をクリアするのに必要な時間と費用をご存知でしょう。MUIのデザイナーは、WCAD 2.0のアクセシビリティ・ガイドラインを満たすようにコンポーネントをデザインすることに細心の注意を払い、研究者やデザイナーの負担を軽減しています。

ただし、アクセシブルなコンポーネントを用いてインターフェースをデザインする場合でも、ナビゲーションやユーザーフローをテストして、製品全体がアクセシビリティの基準を満たしていることの確認が必要であることに留意することが重要です。

7. スキルの強化

MUIのオープンソースコンポーネントUIライブラリは、スタートアップ企業や若い起業家が新製品を開発する際に、特に教育、指導、技能伝授を受けられない発展途上国において、その能力が発揮されるようにします。

また、チャリティ団体、非営利団体、NGOなど、製品やツールを開発したいがデザインシステムに投資する予算がない場合にも、このライブラリーは非常に有益です。 誰でもMUIの優秀なデザイナーやデベロッパーのスキルを活用し、フォーチュン500社で使用されているのと同じコンポーネントライブラリを使用して、洗練されたデジタル製品を開発し、グローバル市場で競争することができます。

MUIが他の コンポーネントライブラリ と異なる点

GoogleのMaterial Design UIは、間違いなく世界で最も優れた、最も包括的なデザインライブラリの1つであり、MUIは、Material Designの上に構築することで、それに匹敵するReactコンポーネントライブラリを提供します。

MUIはTheming機能で簡単にカスタマイズでき、ライブラリのドキュメントも充実しているため、多国籍企業や製品アイデアを持つ一人のデベロッパーでも製品の構築が可能です。 MUIは非常に広く使われているため、デザイナー、研究者、デベロッパーからなる大規模なグローバルコミュニティが存在し、指導やサポートを受けることができます。

Reactが最も人気のあるフロントエンドフレームワークの1つであるという事実も加わり、MUIは魅力的なコンポーネントライブラリとなっています。

興味深い事実と数字

ここでは、MUIの興味深い事実と数字をご紹介します。 注：MUIの統計は上昇を続けており、これは、2022年1月時点のものです。

• MUIは、Googleと差別化するために名称を変更することにして、2014年にMaterial UIとしてスタートしましたが、多くの人がMaterial UIはGoogleの製品だと思い込んでいるようでした。
• MUIには2,200人以上のオープンソースの貢献者がいます。
• GitHubで73,700スター以上獲得しています
• MUIが実施した2020年調査の回答者1,488人のうち、35％のデベロッパーが従業員5人以下の企業で働いていました。
• 調査では、27％のデベロッパーがエンタープライズ・アプリケーションにMUIを使用し、20％が管理者用ダッシュボードにライブラリを使用しています。

UXPinのMUI5キット

UXPin MergeのMUI統合で、UI Reactコンポーネントでプロトタイピングの力が発揮されます。 MUIは、きちんと機能するコードコンポーネントでのデザイン作成をサポートします。信頼できる唯一の情報源（Single source of truth）により、デザイナー、デベロッパー、製品チームなどは、エラーや摩擦を減らし、より効果的にコラボレーションを行うことができます。 忠実度が高いほど、参加者とステークホルダーから有意義なフィードバックを得られるような、より良いユーザビリティ・テストとなります。

その結果、全体的なユーザー体験が向上し、ビジネス価値が高まります。 UXPinのMUIキットの詳細と、この画期的なコードベースのデザイン技術へのアクセスをリクエストするための申し込み方法についてご覧ください：UXPinのMUIライブラリ：より速くデザインする。

UXPin Mergeによるコンポーネントライブラリの同期

UXPin Mergeで、Gitレポジトリ、Storybook、またはMUIからコードコンポーネントを同期し、実際のコードで完全に機能する高忠実度のプロトタイプの構築ができます。 メニュー、フォーム、タブ、データテーブル、日付ピッカー、アコーディオンなどの複雑なUIコンポーネントは、UXPinのコードベースエディタに機能が搭載されており、デザイナーは、ユーザーインターフェースの構築に必要なMUIコンポーネントをドラッグ＆ドロップします。

標準的な画像ベースのデザインツールと同じように、コンポーネントのプロパティパネルを調整することができます。 UXPin Mergeの優れた点は、デザイナーがコードベースのコンポーネントを使用してデザインするのに、新しいスキルセットを学んだり、コードの書き方を知る必要がないことです。

ワークフローは変わりませんが、プロトタイプの忠実度と機能性が大幅に向上します! デザイナーが Merge を使用せずに UXPin を使用する場合でも、ステート、Javascriptのようなインタラクション（条件付きインタラクションを含む）、変数、エクスプレッション、オートレイアウトなど、コードベースの高度な機能を利用できます。

The post MUI とは？MUIについて何を把握すべき？ appeared first on Studio by UXPin.

UXエンジニアは、現代のソフトウェア開発チームにおいて重要な役割を担っており、デザインと開発の間の連携を強化するためのスキルと言語を持ち合わせています。

UXエンジニアは、大抵は部門を超えたチームで働き、デザイナーとエンジニアの間を明確にしてサポートする役割を担っています。UXエンジニアとデザイナーが協力して、デザインのアイデアを機能コードに変換することで、分野間のギャップが埋まり、フロントエンドエンジニアとバックエンドエンジニアは、このコードを基盤として最終製品を開発します。

​​UXPin Mergeにより、デザインと開発の間のギャップを埋めることがこれまでになく簡単になりました。デザイナーの皆さん、コードコンポーネントをUXPinのデザインエディタに同期して、完全に機能するプロトタイプを構築しましょう。無料トライアルにサインアップして、無料の MUI 統合により Merge をお試しください。

UXエンジニアとは？

UXエンジニアは、UIエンジニアまたはUI/UXエンジニアとも呼ばれ、UXデザイナーとUXデベロッパーのハイブリッド的な位置づけになりますが、一般的には、デザイン思考やデザイン原理を理解したフロントエンドのデベロッパーです。

UXエンジニアは、デザインチーム、エンジニアリングチーム、またはその中間で、デザインと開発の橋渡し役として働き、通常は、レイアウト、ボタン、リンク、その他のインタラクティブなコンポーネントなど、UI要素の構築と最適化を行うフロントエンド開発を専門としています。

UXエンジニアは、静的なデザイン要素をインタラクティブなコードコンポーネントに変換する、デザインシステムを扱うことが多いです。

UXエンジニアのスキルセットと業務内容

「UX Engineers: What We Are」内で、UXエンジニアのブライリー・サンドリン氏は、UXエンジニアの職責をグラフィックで表現しています。

UXデザイナーが行う：

• UXリサーチ
• アセット作成・管理
• ワイヤーフレーム作成

UXエンジニアとUXデザイナー両方が行う：

• アイデア出し
• デザインテスト
• 再デザイン

UXエンジニアが行う：

• プロトタイピング
• UIコンポーネント開発
• UIメンテナンス
• スタイリングのアーキテクチャ

UXエンジニアとフロントエンドエンジニア両方が行う：

• 実装
• 技術的実現性
• バックログ管理

フロントエンドエンジニアが行う：

• パフォーマンス
• クエリのアーキテクチャ
• 検索エンジンの最適化

UXエンジニアは、デザインプロセスや原則に関する知識と理解を持ち、フロントエンドのプログラミングの高い能力が備わってなければいけません。ここでは、ソフトウェア開発プロセスにおけるUXエンジニアのスキルや責任について説明します。

UXエンジニア にコードは必要か

はい、UXエンジニアはコーディングの方法を知っておかければならず、最低でもHTML、CSS、Javascriptといった主要なフロントエンドのプログラミング言語についての高い能力が必要です。

フロントエンド開発 – HTML、CSS、Javascript

UXエンジニアの主な業務はフロントエンドの開発であり、他のフロントエンド開発と同様、HTML、CSS、Javascriptに関する高い能力と経験が求められます。

製品によっては、React、Angular、Vueなど、特定のフロントエンドフレームワークの経験を求める企業もあります。

パッケージ管理

プログラミング言語によっては、Node.jsプロジェクトで使用されるNPM（Node Package Manager）やYarnなどのパッケージマネージャの操作法を知っておかなければいけません。

バージョン管理（Git）

フロントエンドの開発は、常に変化し、進化しています。UXエンジニアは、Gitなどのバージョン管理システムを使って、変更と更新を管理し、バージョン管理によって、他のプログラマーと同時にプロジェクトに取り組むこともできます。

デザイン思考

UXエンジニアがデザイナーと連携するには、デザイン思考プロセスの理解が不可欠であり、エンドユーザーへの共感や、UXデザインの原則の理解が必要です。

ユーザーインターフェース（UI）デザインとインタラクションデザイン

UIデザインとインタラクションデザインは、UXエンジニアにとって重要なスキルです。UXエンジニアは、デザイナーと協力してアイデアを出し合い、プロトタイプを機能コードに変換します。UXエンジニアはユーザーインターフェースをデザインしませんが、デザインファイルをコードに変換するため、UIデザインの原則を理解しておかないといけません。

ヒューマンコンピュータインタラクション（HCI）

ヒューマンコンピュータインタラクション（HCI）は、インタラクションデザインと似ていますが、デザインの原則よりもコードに重点を置いており、UXエンジニアの仕事は、デザイナーのプロトタイプを基にした、直感的なフロントエンド体験の構築になります。

デザインシステム

UXエンジニアは、デザイナー、リサーチャー、その他のエンジニアからなる、職域を超えたチームと共にデザインシステムに携わることが多く、デザインファイルから新しいコンポーネントを構築する役割を担っています。

デバッグとテスト

UXエンジニアは、リリース前にフロントエンドのバグを発見して修正する責任を担っていることから、デバッグとテストは、UXエンジニアの重要な作業の一部といえます。又、UXエンジニアは、コードのプロトタイプを作成してデザイナーやエンジニアに提示します。

デザイナーがプロトタイプがデザインと一致していることを確認し、UXエンジニアと一緒に働くデベロッパーがベストプラクティスや命名規則などを確認しながらコードをチェックします。

UXエンジニアは、このようなコードプロトタイプを構築することで、デザインのハンドオフプロセスを効率化し、エンジニアが最終製品を開発するための基盤を構築しています。

ナビゲーションと情報アーキテクチャ

UXエンジニアは、画面、モーダル、ページをつなぐ役割を担っているため、ナビゲーションと情報アーキテクチャを理解しておかなければいけません。

レスポンシブデザイン

レスポンシブデザインは、フロントエンドの開発において非常に重要であり、UXエンジニアは、CSSメディアクエリを使って、モバイル、タブレット、デスクトップなど、複数の画面サイズやデバイスに対応したブレイクポイントの設定が必要です。

ワイヤーフレームとモックアップ

UXエンジニアは必ずしもワイヤーフレームやモックアップを作るわけではありませんが、これらのデザインのコードへの変換が必要です。

UXエンジニアは、上記で挙げた必須スキルとは別に、デザインチームとの連携のために、以下の基本的なデザイン原則を理解しておかなければいけません：

• ビジュアルデザイン
• ユーザビリティテスト
• UXリサーチ
• ユーザージャーニーマップ

UXエンジニアの実際の仕事内容

UXエンジニアの担当は、組織や製品によって異なりますが、通常はデザインプロセスとエンジニアリングプロセスを行き来して仕事をし、4つのステージにUXエンジニアのプロセスが定められます：

1. アイデア出し
2. デザイン
3. 構築
4. テスト

1. アイデア出し

UXエンジニアは、ユーザーリサーチャーやデザイナーと協力して、ユーザビリティの目標の確定や、解決策のブレインストーム、初期デザインの技術的な実現性についての助言をします。

アイデア出しの段階では、ブレインストーミングとアイデアのスケッチが非常に重要であり、UXエンジニアは、アイデアがどう働くかや製品の技術的制約の範囲内であるかどうかについて、技術的なインサイトを提供します。

アイデア出しの段階でUXエンジニアがいれば、デザイナーやリサーチャーはエンジニアリングの能力を超えたソリューションを回避できるため、企業の貴重な時間を節約することができるのです。

2. デザイン

UXエンジニアは、ワイヤーフレームや低忠実度のプロトタイピングからモックアップや高忠実度のプロトタイピングまで、デザインプロセスで積極的な役割を果たし、デザインシステムを使う場合は、デザイナーと協力してUXPinなどのツールでコンポーネントのライブラリをデザインします。

UXエンジニアは、デザイナーのデザインのハンドオフのためのデザインファイル、ドキュメント、プロトタイプの準備をサポートする役割を担っており、デベロッパーに言葉や指示を確実に理解させ、デザイナーとエンジニアのコミュニケーションを円滑にします。

3. 構築

UXエンジニアは、静的なデザインをコードに変換する役割を担っています。役割はレイアウトやUI要素に及び、データ統合、API、パフォーマンス、分析などのその他のフロントエンド開発はエンジニアリングチームに任せます。

UXエンジニアは、開発段階を通じてエンジニアリングチームと協力し、意図したとおりにデザインを実行します。

4. テスト

UXエンジニアは、デザイナーと密接に協力して、デザインプロセスでのアイデアのテストや、ソリューションの開発、エンジニアと協力してコードのバグの特定や修正をします。

UXエンジニア になるには

大手の企業でUXエンジニアとして就職したい場合、通常、コンピュータサイエンス、ヒューマンコンピュータインタラクション（HCI）、またはUXデザインのいずれかの学位が必要とされます。

UXエンジニアになる方法はいくつかあります：

• UXデザイナー：HTML、CSS、Javascriptなどのプログラミング言語と、Git、Chrome Developer Tools、NPM/パッケージマネージャ、コマンドラインなどのフロントエンドスキルの習得が必要
• フロントエンドデベロッパー：フロントエンド開発からの移行が、UXエンジニアになるための最も一般的なルートであり、フロントエンドデベロッパーは、UXエンジニアに必要なほとんどのスキルをすでに持っているが、さらにUXデザインのプロセスや原則の習得が必要
• プロダクトデザイナー：プロダクトデザイナーからUXエンジニアへの道もまた、単純明快であり、プロダクトデザイナーは、デザイン思考を仕事に応用し、ほとんどがプロトタイプを作るための基本的なプログラミングスキルを持つ

UXエンジニアもまた、多様なツールキットを使って仕事をします。デザイナーとデベロッパーの2足のわらじを履いているため、デザインツール、DevOps、デベロッパー用ツールキットを熟知しておかなければいけません。ここでUXエンジニアのツールをチェックしましょう。

UXエンジニアの多くはデザインシステムを扱う職種であるため、高収入のUXエンジニアを目指すのであれば、デザインシステムの知識と経験が不可欠です。

UXエンジニアの給与

Glassdoorによると、2022年の米国におけるUXエンジニアの平均給与は116,625ドルです。

UXPin MergeによるUXエンジニアリングワークフローの最適化

UXPin Mergeで、UXエンジニアがデザイナーやデベロッパーと1つのツールで連携できるようになり、レポジトリからUXPinのデザインエディタにコンポーネントを同期させることにより、デザイナーとエンジニアが同じUI要素で作業できるようになります。

UXエンジニアがプロトタイプをコーディングする代わりに、UXデザイナーはUXPinでコンポーネントをドラッグ＆ドロップして完全に機能するプロトタイプを構築することができます。また、デザイナーはUXPinのプロパティパネルでコンポーネントを編集し、これにより、UXエンジニアがコピー＆ペーストで変更できるようJSXを簡単にレンダリングすることができます。

UXエンジニアがレポジトリに加えた変更は、自動的にUXPinのデザインエディタに同期され、デザイナーは新しいコンポーネントで作業することができます。この信頼できる唯一の情報源（Source of truth）により、UXエンジニアは毎回プロトタイプを一から構築するのではなく、コードにわずかな調整を加えるだけで済み、市場投入までの時間が大幅に短縮されます。

UXPin Mergeでは、デザイナーとエンジニアがすでに同じ言語で会話しているため、デザインのハンドオフが効率的であり、UXエンジニアは、レポジトリからスターターコードを使用してUIを開発した後、フロントエンドおよびバックエンドのデベロッパーに引き継いで最終製品を完成させることができます。UXPin Mergeのリクエストはこちらから。

The post UXエンジニア って具体的にどんな人？ appeared first on Studio by UXPin.

今や、コンテンツライティングとは何かを知っている人は多いかもしれませんが「UXライティング 」についてはどうでしょう？プロダクトデザインチームにおけるこの新しい役割は、非常に重要なものとなっています。

今回は、UXライティング の基礎、デザインチームやプロダクトチームの中での役割、そして優れた UXライティングの原則をご紹介します。

UXライティング とは

UXライティング（ユーザーエクスペリエンスライティング）とは、ユーザーインターフェースを含む、ユーザーと接するすべてのタッチポイントで、ユーザーフレンドリーなコピーを作成するプロセスです。これは単なる装飾的な文章ではありません。UXコピーは、ユーザーに情報を提供し、導き、促し、行動を起こさせるものであり、正式なプロダクトデザインプロセスの一環として作成された場合にのみ、効果的に機能するものです。インタラクティブなUXデザインにおける優れたコピーは、製品を成功させる鍵のひとつである優れたユーザーエクスペリエンスを生み出すのに役立つのですから、それだけで重要な役割を果たすようになったのも不思議ではありません。

UXライターの仕事とは

UXライターは、ソフトウェア、ウェブアプリケーション、モバイルアプリケーションなど、デジタル製品全体で使用されるマイクロコピーを作成します。これらのコピーは、メニューラベル、ボタン、コールトゥアクション、確認メッセージ、エラーメッセージ、セキュリティノートなどです。UXライターは、ユーザーが特定の結果を得るために、何を、なぜすべきかを理解できるようなコピーを作成します。UXライティング（ユーザーエクスペリエンスライティング）とは、ユーザーインターフェースを含む、ユーザーと接するすべてのタッチポイントで、ユーザーフレンドリーなコピーを作成するプロセスです。これは単なる装飾的な文章ではありません。

長い間、デジタル製品のマイクロコピーを書くのは、ソフトウェア開発者やグラフィックデザイナーでした。当時、UXライティング は過小評価され、贅沢なものと考えられていました。その結果、製品内のマイクロコピーは一貫性がなく、ユーザーを混乱させることが多く、また、文法ミスやスペルミスが多いこともありました。すべてに秀でた人はいません。ソフトウェア開発者やデザイナーも例外ではありません。特に、製品のことを知り尽くしている彼らにとって、ユーザーに共感することは難しいのです。

UXライターがしてはいけないことは

UXライターの役割を、テクニカルライター（テクニカルライティングを担当し、ユーザーエクスペリエンスではなく、わかりやすさと正確さを重視する）、コンテンツストラテジスト（コンテンツ戦略、つまり大規模なコンテンツを計画し、必ずしもコピーを書かない）、情報アーキテクト（情報アーキテクト、つまり持続可能な情報構造と分類を構築する）、コンテンツマーケティングコピーライター（リードを引きつけ、顧客に変え、顧客を維持するためのマーケティングコピーを書く）と混同してはいけません。

デザイン・プロダクトチームでの UXライティング

UXライターはUXチームのメンバーであり、そのためUXリサーチの実施や共同作業を行うことが期待されます。UXコピーとUXデザインチームは、最終製品の機能性、ユーザビリティ、アクセシビリティを向上させるオプションを発見するために協力します。その結果、デザインプロセスを効率化し、より多くのユーザーを惹きつける優れたデジタル体験を開発することができるのです。

UXライターは、製品開発者と緊密に連携して、ロジックの抜けやインターフェースの混乱を指摘し、開発中の最終製品に影響を与えます。UXライターはまた、マーケティング、法務、ビジネスデベロップメントなど、組織内の他のチームと協力して、コピーがブランドボイスに沿っているか、製品のUVPを強化しているか、会社に迷惑をかけていないかを確認します。

UXコンテンツの種類

UXコンテンツの具体的な種類は、デジタル製品によって異なりますが、一般的には以下のようなものがあります：

• 初めてのユーザーのオンボーディング
• メニューラベル、フォームフィールドラベル、リスト
• ボタンやコールトゥアクション（CTA）の表示
• 設定ラベル
• 文脈上のヘルプとツールチップ
• 確認メッセージ
• エラーメッセージ
• セキュリティノート
• 製品内マーケティング（例：ポップアップ広告)
• チャットボットの会話シナリオ
• 法的通知と免責事項

UXコピーライティング の原則

優れたUXライティングとは、すっきりとした目的のあるラインで、一語一語を大切にすることです。余分なものや冗漫さは敵です。そのため、UXライティングを「詩を書くこと」に例える人もいます。しかし、優れたUXライターは次のようなことも求められます:

• 製品の機能だけでなく、それがエンドユーザーの生活をどのように改善し、楽にするのかを知っていること。エンドユーザーとそのニーズやウォンツに共感することが、UXライティングを成功させる鍵となります。

• 製品で何ができるのかを伝え、その方法を論理的にわかりやすく案内する。
• 製品のフローを批判的に見て、ユーザーの質問を予測し、積極的なヘルプでユーザーのフラストレーションを先取りし、タスクをガイドする。
• また、必要に応じて、複雑なプロセスを簡単なステップに分解しましょう。UXのコピーは、必要な情報や要求された情報だけを伝えるべきです。
• ブランドボイスを使用し、可能な限り製品のユニークバリュープロポジション（UVP）を強化することで、競合製品との差別化を図ります。
• ブランドボイスを使用し、可能な限り製品のユニークバリュープロポジション（UVP）を強化することで、競合製品との差別化を図ります。

まとめ

ご覧の通り、経験豊富なUXライターを起用することは、製品デザインの全体的な品質を向上させる鍵となります。ユーザーインターフェイスのマイクロコピーは、ユーザーが目的を達成するためにあることを忘れないでください。そしてこれこそが、最終的にあなたのデジタル製品に多くの顧客をもたらすのです。

UXチームの作業を改善する方法を探しているなら、UXPinを試してみてはいかがでしょうか。UXPinはクラウドベースのデザインツールで、UXライターとUXデザイナーがリアルタイムでコラボレーションすることを容易にします。実際のデータをデザインに取り込むことも可能です。14日間の無料トライアルで使い心地を確認してください（購入の義務はありません）。

The post UXライティング とは何でしょう appeared first on Studio by UXPin.

ヒューリスティック評価とは、一連のユーザビリティ原則に基づいてユーザーインターフェースをレビューすることです。

デザインプロセス全体を通してユーザビリティの問題を明らかにし、公開前に問題箇所を修正できることで、開発時間を大幅に節約することができます。

ヒューリスティック評価は、3～5人のユーザビリティの専門家がインターフェイスを検証し、ガイドラインに基づいて潜在的な問題を浮き彫りにしていきます。

この記事はNextUXのAndrew Coyleによって書かれました。NextUXはWebベースのビジュアルコミュニケーションツールを提供しており、チームがWebプロジェクトのフィードバックや方向性を示すのに役立ちます。

Jakob NielsenとRolf Molichは、90年代のヒューリスティック評価のパイオニアです。 ユーザー ・インターフェース・デザインのためのユーザビリティ・ヒューリスティックは、今日でも指針となっています。そのため、彼らの10のヒューリスティックについて学び、ヒューリスティック評価の方法について理解を深めることをお勧めします。

デザイナーとしての経験を通じて、私はウェブプロジェクトのレビューで使用するヒューリスティックスを明確にし、改善してきました。UIを評価する際には数え切れないほどのバリアブルやベストプラクティスを考慮しますが、ここで紹介する5つの原則は私自身がデザインを評価する方法をよく使用しています。

UXPinを使用して最終製品のように見える高度なプロトタイプをデザインしてみましょう。UXPinを使うことで、漠然としたアイデアを他のチームメンバーと共有可能で高機能なプロトタイプに簡単に変換することができます。14日間の無料トライアルはこちらまで。

ユーザーに自分の居場所を知らせる

 ユーザー はインターフェイスの中で自分がどこにいるのかを常に把握し、行きたい場所に移動する方法を理解する必要があります。アプリやウェブサイトでは、わかりやすいナビゲーションとサインマーカーを設置しましょう。また、デザインをインタラクティブにすることで、最終的に何が問題になるのかを徹底的にチェックします。

例：段階的なフローに進捗や状態を示す表示を追加し、説明的なヘッダーを用意して、どこにいるのか、次に何があるのかを伝える。

ルールの例外：ゲームのように、 ユーザー が現在地や次の段階を発見することで娯楽や価値を得られる場合。

ユーザーインターフェースに一貫性のあると美的なものにする

 ユーザーインターフェースを構成する要素やフローにおいて一貫性は不可欠です。

例： 一部のボタンに文語体を使用し、他のボタンにタイトル語体を使用しているデザインがあったとします。これではスタイル上の理由がない限り、一貫性が高いとは言えないでしょう。

見る人によってもちろん異なりますが、私は異なるデザインスタイルを使う場合、全体的なビジュアルに関しての魅力はあまりないかと思います。バランス、シンメトリー、ヒエラルキーなどの視覚的な原則をどのように使うかによって、普遍的なデザインを作ることができます。

例：不必要なボーダーやドロップシャドウなどの視覚的なノイズが多いインターフェイスだと、見た目の美しさを低下させてしまい、かえってユーザビリティを低下させてしまいます。

「読む」「待つ」「覚える」を減らす

残念なことに、デジタルの世界では人々の注意力は極めて低いものです。ユーザーが何かを読んだり、待ったり、記憶したりすることに頼ってはいけません。不必要なテキストは省き、スキャンしやすいようにデザインしましょう。

ユーザーが短期的な記憶に頼らなくてもいいように、できるだけ自動化しましょう。

例：特定のプロセスやインタラクションのロード時間が長いアプリの場合、待ち時間の負担を軽減するために、残り時間を示す楽しいロードアニメーションを追加することを検討します。

例:アプリの設定プロセスが複雑な場合、 ユーザー が説明書を読んだり要件を記憶したりすることを前提にしてはいけません。代わりに、長いセットアッププロセスを、簡潔で文脈に沿った情報を持つ短いステップに分割します。

エラーを防ぎ、行動を可逆的にする

アプリケーションに安全策を講じ、明確なコミュニケーションをとることで、エラーの可能性を減らすことができます。

例：

1. 不用意な削除を減らすために、重要なデータの削除をより手際よく行う。
2. 削除プロセスに特別なステップを追加し、ユーザーが自分のアクションの結果を確実に把握できるようにします。
3. 重要なアクションを元に戻す機能を追加する。

経験豊富な ユーザー に対応し、新しい ユーザー にも対応

複雑さや選択肢の多さで新しいユーザーを圧倒してはいけません。できるだけ早くユーザーが使いこなせるように、初めての使用感を提供すること。

強力なアプリケーションを使いやすくするために、経験豊富なユーザーの能力を制限してはいけません。頻繁に使用するユーザーが目的を達成し、ニーズを可能な限り早く解決できるように、オプション性とカスタマイズ性を提供する。

例：ユーザーインターフェースに表示されるアクションにキーボードショートカットを追加する。新しいユーザーはキーボードショートカットを知らなくても操作できますが、経験豊富なユーザーはショートカットを使うことでより早く操作できます。

ユーザビリティの原則を使用してプロダクトデザインを改善する

エンドツーエンドのデザインツールをお探しなら、ぜひUXPinを実際に使ってみてください。デザイン、イテレーション、プロトタイプの完成を10倍速くします。気になった方は、14日間の無料トライアルをこちらからお試しください。

The post ヒューリスティック評価 – 指針となる5つのユーザビリティ原則 appeared first on Studio by UXPin.

UXの世界は常に成長し、進化し続けていおり、特定のタスクや研究に対応するための新しいUXでの役割または部門が生まれています。 

UXアーキテクトとUXデザイナーは何が違うのか？また、デザインプロセスを改善するために、会社ではこの2つのポジションを満たす必要があるのでしょうか？

ここでは、UXアーキテクトの仕事内容や、UXデザイナーとUXアーキテクトの役割や責任の違い、重複する部分などをご紹介します。この記事の最後に、UXチームが効果的にコラボレーションするためにUXPinがどのように役立つのかを簡単に説明します。

UXPinは、UXデザイナーとUXアーキテクトがより良い製品体験をデザインするためのコラボレーションツールです。UXPinの14日間無料トライアルに今すぐお申し込みください！

UXアーキテクトとは？

ユーザー・エクスペリエンス・アーキテクトとは、基本的に、製品やデザインをハイレベルな視点で見ることができるUXのスペシャリストです。UXアーキテクトは、ユーザーや市場の綿密な調査に基づいて、構造や流れに関心を持ちます。

そのために、UXアーキテクトはリサーチチームと密接に連携したり、自らリサーチを行うこともあります。このリサーチによって、UXアーキテクトは、ユーザーが製品をどのように使用するかについて十分な情報を得た上で判断し、それに基づいて情報アーキテクチャを構成します。

UXアーキテクトの責任を簡単に説明します：

• 製品がユーザーのニーズを満たすようにする
• 情報が整理され、簡単にアクセスできるようにする
• ユーザビリティやアクセシビリティの問題を解決する

コンテンツの整理

UXアーキテクトは、コンテンツやアセットを作成するのではなく、ユーザーにとって最適なコンテンツを整理して配置します。この整理は3つのカテゴリーに分類されます：

• コンテンツインベントリ—製品に含まれるすべてのデジタルコンテンツのリスト。
• コンテンツのグループ化—製品のコンテンツを整理するための論理的な構造で、異なる情報の関係性やそれらがどのようにつながっているかを定義します。
• コンテンツ監査—製品のコンテンツを定期的に見直し、更新が必要なものや新しいコンテンツが必要かどうかを判断すること。

UXアーキテクトは、各ページのコンテンツを整理し、タイトル、小見出し、リンク、ナビゲーションをどこに追加するかを決定し、ユーザーが探しているものを見つけやすくする必要があります。

階層構造、サイトマップ、ナビゲーション

情報アーキテクチャとは、製品やウェブサイトの階層、サイトマップ、ナビゲーションなどを整理するものです。これらの重要な要素が、アプリやウェブサイトの使いやすさやアクセスのしやすさを決定します。

• サイトマップ – アプリやWebサイトの全てのページのこと。
• 階層 – ページのコンテンツを重要度の高い順に並べる方法。
• ナビゲーション – ユーザーがアプリやWebサイト内をどのように移動するかを示すもの。

社内でのワイヤーフレーム作成とローフィデリティプロトタイピング

UXアーキテクトは、社内のUXチームが製品やWebサイトをデザインする際の参考資料として、ワイヤーフレームやローフィデリティプロトタイプを作成します。

UXチームはこれらのモックアップをデザインのためだけに使用し、通常はユーザビリティスタディやステークホルダー間での共有には使用しません。

UXデザイナーとは？

UXデザイナーとは、デザインとリサーチの役割を包括する幅広い用語です。しかし、UXデザイナーとUXアーキテクトの比較では、デザイナーはユーザーインターフェースの設計を担当します。最終的に、UXデザイナーは製品を使いやすくします。

UXデザイナーは、UXアーキテクトが作成したワイヤーフレーム、プロトタイプ、アーキテクチャーの指示を受けて、それを実際の製品に仕上げます。また、UXデザイナーはUXリサーチャーと協力して、どのようなフォント、色、ボタン、その他のデザイン要素を使用するかを決定します。

ペルソナ開発

UXデザイナーは、初期のリサーチとユーザーペルソナの作成を担当します。大規模な組織では、専任のユーザーリサーチャーやチームがいるかもしれませんが、UXデザインの役割を果たしていることに変わりはありません。

ユーザーペルソナは、ユーザーの属性情報、動機、欲求、潜在的な反応などをUXデザイナーに伝え、これらのユーザーニーズに対応したユーザーインターフェースを設計します。

ワイヤーフレーム、モックアップ、プロトタイプ

UXデザイナーは、初期のユーザーリサーチとUXアーキテクトの情報アーキテクチャをもとに、製品のページやフローのワイヤーフレームやモックアップを作成します。

研究チームは、これらのハイフィデリティ・プロトタイプを使用してユーザビリティ・スタディを行い、ユーザーが最終製品をどのように操作するかを学びます。

ユーザーテスト

専門のリサーチチームを持たない企業では、UXデザイナーが必要なユーザビリティ・スタディを行います。UXデザインの重要な部分であるこのテストは、ユーザーが最終製品をどのように操作するかについて、UXデザイナーに貴重なフィードバックをもたらします。

UXデザイナーは、ユーザビリティスタディの結果をもとに、ユーザーエクスペリエンスを向上させるためにデザインを調整します。

UXアーキテクトとUXデザイナーの主な相違点

UXアーキテクトとUXデザイナーの最も大きな違いは、UXアーキテクトは大局的に見るのに対し、UXデザイナーは細部にこだわることです。

UXアーキテクトはナビゲーションやユーザーフローを重視し、UXデザイナーは各画面やページのユーザーインターフェースやインタラクションを作成します。

UXアーキテクトもUXデザイナーもリサーチを行いますが、UXアーキテクトはユーザーがどのような機能やコンテンツを必要としているかを考えます。一方、UXデザイナーは、ユーザーがこれらの要素をどのように操作するのかを知りたいと考えています。

UXアーキテクトとUXデザイナーの役割をまとめると、以下のようになります。

• UXアーキテクト – ユーザーは誰で、何を必要としているのか？
• UXデザイナー – ユーザーは誰で、そのニーズをどのように満たすのか？

UXアーキテクトとUXデザイナーの連携について

多くの企業、特に中小企業では、UXデザイナーがUXアーキテクトの役割を担っていることに注意する必要があります。

これらの役割が分かれている場合、UXデザイナーはインターフェイスとインタラクションに焦点を当てるため、しばしばUIデザイナー（ユーザーインターフェイスデザイナー）と呼ばれます。

UXアーキテクトは、デザインに焦点を当てるのではなく、情報アーキテクチャに特化したUXのスペシャリストです。

UXアーキテクトとUXデザイナーは、コンテンツに関して緊密に連携します。UXデザイナーはコンテンツの詳細に焦点を当て、UXアーキテクトはコンテンツをどのように構成するかを決定します。このことを正しく理解するためには、デザイナーとアーキテクトが密接に協力する必要があります。

UXアーキテクトとUXデザイナーの典型的なワークフロー

以下のワークフローは、UXアーキテクトとUXデザイナーの責任の分担を示す大まかな概要です。

1. プロジェクトは、建築家が物理的な構造物を設計するのと同じように、UXアーキテクトが市場やユーザーリサーチを分析し、プロジェクトに必要なものやコンテンツの構成を決定することから始まります。
2. UXアーキテクトは、UXデザイナーが構築プロセスを開始するための青写真（ワイヤーフレームとプロトタイプ）を作成します。
3. UXデザイナーは、ユーザーリサーチとUXアーキテクトの設計図を分析し、各ユーザーインターフェースのデザインを開始します。
4. UXデザイナーは、ステークホルダーやユーザビリティ・スタディのために、ワイヤーフレーム、モックアップ、ハイフィデリティ・プロトタイプを作成します。
5. ユーザビリティスタディでは、UXアーキテクトは、ユーザーがどのようにコンテンツにアクセスし、製品内を移動するのかを知りたいと考えています。UXデザイナーは、ユーザーが各画面上の要素やコンテンツをどのように操作するのかを確認します。
6. 製品が発売されると、UXアーキテクトの仕事は、正確で最新のコンテンツを確保することです。また、アクセシビリティの問題にも目を配り、適宜アップデートを提案します。UXデザイナーは、UXアーキテクトの提案を受け、インタラクションデータを分析して、各画面を最適化し、ユーザーに最適なサービスを提供します。

あなたの会社には、UXアーキテクトとUXデザイナーが必要ですか？

UX/UIデザイナーとUXアーキテクトの役割を分けることで、製品やWebサイトの品質と効率を向上させることができます。

小規模なプロジェクトや資金力のあるスタートアップでは、専任のUXアーキテクトに十分な仕事がないかもしれません。ここで重要なのは、UXデザイナーがUXアーキテクトの役割を果たすことができるということです。

プロジェクトの規模が大きくなると、情報アーキテクチャが複雑になり、管理に時間がかかるようになります。このような場合、プロジェクトの成功にはUXアーキテクトの存在が欠かせません。

代理店は一般的に少人数のチームで仕事をしていますが、クライアントのために複数のアプリやWebサイトを制作することも少なくありません。UXアーキテクトがいれば、UXデザイナーに必要な情報を伝え、すぐに構築を開始できるので、生産性の向上につながり、技術的な生産ラインを作ることができます。

企業は、UXアーキテクトが必要かどうかを判断するために、いくつかの質問をしてみましょう:

• UXデザイナーはレイアウトや情報アーキテクチャの構築にどのくらいの時間を費やしているのでしょうか？
• これらの作業は制作の遅延を引き起こすのでしょうか？
• ユーザビリティ調査において、ユーザーはナビゲーションの問題で苦労することが多いですか？
• 品質と効率の向上から得られる利益に比べて、専任のUXアーキテクトのコストはどのくらいですか？
• 御社の製品では、ユーザビリティやアクセシビリティの問題が頻繁に発生しますか？
• 誰かが製品のコンテンツを監視していますか？古いコンテンツや使用されていない製品機能を定期的に見つけていますか？

UXPinがUXチームの生産性を向上させ UXPinは、UXチームが共同でより良い製品を作るための強力なデザインツールです。UXアーキテクトはUXPinを使用してレイアウト、ワイヤーフレーム、ローファイプロトタイプを作成し、ガイダンスとコンテキストのためのコメントを付けることができます。

UXデザイナーは、これらの情報をもとに、美しい画面やインターフェースを設計し、モックアップを作成して関係者に提示したり、ユーザビリティ・スタディに使用したりすることができます。

14日間の無料トライアルを提供

14日間の無料トライアルでは、UXチームが効果的にコラボレーションし、顧客のためにより良い製品を作るためにUXPinがどのように役立つかをご覧いただけます。ぜひコードベースデザインの世界をご体験ください！

The post UXアーキテクト とUXデザイナー、その違いは？ appeared first on Studio by UXPin.

プロトタイプが完成しましたか？それでは、作成したデザインを開発チームに送ってコードに変換してもらいましょう！

…しかし、ここで疑問が浮かびます。そもそも、「デザインからコード（Design to Code）」という流れで行うのは、本当にベストな手順なのでしょうか？

これについて考える前に、もう一つの方法として「コードをデザイン（Code to Design）」に反映させ、コード化されたUIコンポーネントで作業する方法もあります。

本記事では、「Design-to-Code（デザインからコード）」と「Code to Design（コードからデザイン）」のワークフローについてメリット、デメリットを含めて説明し、実際に企業が実践しているユースケースをいくつかご紹介していきます。

「Code to Design」のテクノロジーを体験してみませんか？UXPin Mergeで、デザインと開発での「信頼できる唯一の情報源（Single source of turth）」を活用しましょう。UXPin Mergeについて詳しく見る。

Design-to-Code

「Design-to-Code」は、典型的な製品開発プロセスを表しています。デザイナーはデザインツールやプロトタイピングツールを使ってUI（ユーザーインターフェース） をデザインし、デベロッパーに渡してコード化してもらいます。

長年にわたり、「Design-to-Code」のプロセスは進化してきましたが、「デザイン」と「開発」の間には、まだ大きなギャップがあります。デザイナーは今でも静的なUIを作成し、エンジニアはそれをコードに変換しないといけないのです。

静的なUIは忠実度や機能性に欠けるため、デザインチームはデザインやプロトタイプが何をするものなのか、ドキュメントや注釈、説明を含めないといけません。

ツールにインタラクティブ性がなく、多大な時間とリソースが必要なことから、多くのデザイナーがアニメーションやトランジションのデモにGIFやビデオを使っています。それによって、デザインファイルやドキュメントを断片化し、デベロッパーやステークホルダーにとってわかりにくいものとなってしまいます。

詳しくは、「デザインツールはイメージベースからコードベースへ」の記事でご覧ください。

「Design-to-Code」の利点

デザイナーとエンジニアにとって「Design-to-Code」のプロセスは、それぞれが使い慣れたツールやワークフローを使って馴染みのある言葉を用いて作業することができることから、両者にとって。

デザインツールは、使いやすさとスピードを重視して作られており、経験豊富なデザイナーは、画像ベースのデザインツールを使って、画面モックアップを本当に速く作成することができます。

「Design-to-Code」の限界

残念ながら、「Design-to-Code」は実際のところ、利点よりも制限の方が多いため、多くの企業がデザインプロセスの改善に模索しています。

デザインと開発間のズレ

現在の「Design-to-Code」でのワークフローでは、忠実度と機能性が大きな制約となっていることから、画像ベースのプロトタイプでは最終製品のように見えたり機能はしません。デザイナーは、プロトタイプを説明する文書や注釈、会議を行ったとしても、エンジニアが期待に応えてくれないと不満を抱いてしまうかもしれません。逆に、エンジニアはデザイナーに技術的な制約をうまく伝えづらいため、そこに摩擦が生じてしまいます。

デザインシステムの課題

高品質のデザインシステムであっても、「Design-to-Code」は、ハンドオフ、スケーラビリティ、成熟度の面で課題が生じてしまい、デザインシステムチームは、以下の２つのデザインシステムの管理が必要です：

• デザイナー向けのUIキット
• デベロッパー向けのコンポーネントライブラリ

さらに、両方のシステムに関するドキュメントの維持が必須です。

このワークフローを「信頼できる唯一の情報源（Single source of truth）」として表現するのは誤りです。これについて、ドイツに本拠を置くソフトウェア開発会社のdotSourceがこちらの記事（英語の記事です）で以下のように指摘しています：

「デザインシステムのリリースの多くは、少なくとも以下の３か所のアップデートが必要になるでしょう：

• デザインシステムのコードベース（コンポーネントライブラリ）
• デザインチームのUIキット(デザインツール)
• デザインシステムのドキュメント

各 UIコンポーネントに対して、「信頼できる唯一の情報源（Single source of truth）」が「３つの 信頼できる情報源」になると、直感に反しているように見え、エラーを増加させてしまいます。デザインシステムの更新プロセスと技術が一致していないと、1つの変更に3箇所の更新が必要になるため、チームは冗長な作業で行き詰まることになってしまいます。”

重複作業

エンジニアは、デザインの最終版を手に入れたら、それをコードに変換させなければいけないため、デザインをコードに反映させる必要がない場合よりも、はるかに長い時間がかかってしまいます。

Code to Design

「Code to Design」は、UXPinがMergeの技術を使って独自に開発したワークフローです。

デザイナーは、使い慣れたUIや機能のあるデザインツールを引き続き使いますが、デザインはベクターグラフィックスではなく、本番環境へリリースする前のコードをレンダリングします。

多くのデザインツールはプラグインや拡張機能でこのシステムを再現しようとしていますが、エンジニアがそのコードを使えることはほとんどありません。MergeはデザインシステムのリポジトリからUXPinにコンポーネントを同期させるので、コードはエンジニアが自分で書いたものなのでそのまま使うことができます。

そしてデザイナーは、エンジニアが開発時に使うのと同じコンポーネントライブラリをデザインプロセスで使います。

「Code to Design」の利点

信頼できる唯一の情報源（Single source of truth）

「Code to Design」は製品開発の多くの問題を解決しますが、最も大きな利点は、「真の 信頼できる唯一の情報源（Single source of truth）」、つまり全員が同じレポジトリから同じコンポーネントライブラリを使う点です。レポジトリに変更があると、自動的にUXPinに同期され、デザインチームに更新が通知されます。

Mergeのバージョン管理により、デザインチームは以前のリリースに変更し、選択したときに既存のプロジェクトの更新のみをすることができます。

デベロッパーは、UXPinの Storybook統合を使っていたら、リリースごとにドキュメントを同時更新します。この「信頼できる唯一の情報源（Single source of truth）」は、DesignOpsでの多くの課題を解決し、それによってチームメンバーが重要なタスクに集中することができます。

「Code to Design」のワークフローのもうひとつの大きなメリットは、そのデザインハンドオフのしやすさです。エンジニアはコンポーネントライブラリのパッケージをインポートしてコンポーネントを追加し、UXPinからJSX コードをコピーし、開発を完成させます。

コンポーネント駆動型のプロトタイピング

Mergeコンポーネントは、レポジトリと同じプロパティとインタラクティブ機能でUXPinに表示されます。各コンポーネントのプロップ（Storybookでは Args）はUXPinキャンバス上のプロパティパネル（Propaties Panel）に表示されるため、デザイナーは色、ステート、サイズなどを含むデザインシステムに従って変更を加えることができます。

このような既製のUI要素を用いて、デザイナーがコンポーネントとパターンをドラッグ＆ドロップするだけで、完全に機能するプロトタイプを構築するコンポーネント駆動型の迅速なプロトタイピングが実現するのです。

デザインドリフトがない「究極の一貫性」

既成のコンポーネントによって、誰でも同じ制限および制約のある同じUIライブラリを使うため、矛盾がなくなります。

デザイナーは、UXPinのプロパティパネルで利用可能なプロパティによってのみ要素を変更することができます。オーバーライドがないため、変更の可能性がないことから、結果としてドリフトが発生しません。

ガバナンスの向上

この制限により、ガバナンスとデザインシステムの整合性が上がります。デザインシステムチームはレポジトリを絶対的に管理していることから、新しいパターンやコンポーネントを普及させるためには、誰もが正しい手順を踏まなければなりません。

拡張性と成熟度

Merge は、チームメンバー全員が同じコンポーネントライブラリを使い、ゼロからのデザインや開発を行わずに製品をリリースすることで、最高のデザインシステム成熟度を提供します。この技術を使うことで、組織は「Design to Code」のワークフローに従うよりも、大幅に早くこのレベルの成熟度を達成することができるのです。

全員が単一のコードベースを使用することで、技術や市場の変化に応じたデザインシステムの拡張がしやすくなります。また、デザインシステムチームが新しいコンポーネント、パターン、テンプレートをレポジトリに追加すると、製品開発チーム全体ですぐに利用できるようになります。

検証の質を向上

「より良いプロトタイプ」は、「より良い検証」ということであり、デザイナーは、最終的な製品体験を正確に表現するプロトタイプによって、デザインプロセスにおいてより多くの問題を解決し、より良い機会を見出すことができます。

ユーザビリティ調査の参加者やステークホルダーは、最終製品と同じようにそのようなプロトタイプを操作することができ、それによって有意義なフィードバックやデータに基づく実用的なインサイトに繋がります。

制限事項

「Code to Design」にはコンポーネントライブラリが必要

「Code to Design」は、コンポーネントライブラリでのみ機能します。組織内でデザインシステムがない場合は、オープンソースのUIライブラリの活用も可能です。たとえば、PayPal の社内製品開発チームではカスタマイズされた MicrosoftのFluent UIデザインシステムを使用しました。

デザイナーはMergeの npm統合を使って、npmレジストリで利用可能なオープソースライブラリからコンポーネントをインポートすることもできます。この方法には技術的なスキルは必要なく、その代わり、デザイナーは Merge コンポーネントマネージャー機能 を使って UI要素をインポートまたは管理を行うことができます。

デザイナーとエンジニアの連携

「Code to Design」では、デザイナーとエンジニアのより密接に連携する必要がありますね。ほとんどの組織には、デザインシステム専門のチームがあるので、これは標準的なガバナンスの手順とあまり変わらないでしょう。

柔軟性が低い

コードベースのデザインシステムは、デザイナーが素早く組み立てられるUIキットに比べると柔軟性に欠けてしまいます。デザイナーは、一度デザインツールにアップロードされたコンポーネントの変更や操作が制限されている、もしくは全くできません。この柔軟性の低さは、デザインシステムのガバナンスと整合性のうえでは必要ですが、革新性と創造性を制限してしまうという意見もあるかもしれません。

UXPinは他のデザインツールと同様に機能するため、デザイナーは新しいアイデアやパターンを開発し、チームメンバーに提案することができます。UXPin のパターン（Patterns）機能では、既存のデザインシステム要素を組み合わせたり、オープンソースライブラリをインポートして、新しいコンポーネントや、パターン、テンプレートを作成することができます。

このように、「Code to Design」は、デザイナーがオープンソースのライブラリの良い部分を活用して新しいパターンを開発できるため、創造性と革新の機会が増えるでしょう。

「Code to Design」を採用している企業

UXPinの「Code to Design」ワークフローは世界の様々な規模の企業に採用されています。ここでは、実際に「Code to Design」を実践しているユースケースを３つご紹介します。

PayPal

PayPalでのUXチームは、「Code to Design」のワークフローへの切り替えで、製品開発プロセスに革命を起こしました。２０１９年に切り替えて以来、PayPalの製品チームは、デザインドリフトや不整合もなく、８倍速くリリースを提供できるようになりました。さらにPayPalの新しい製品開発プロセスでは、部門外のコラボレーションも改善され、全員がUXに責任感を持つようになりました。

また、Mergeで PayPalのプロトタイプと検証の質も改善され、ユーザビリティテスト参加者とステークホルダーからのフィードバックもより良いものになりました。

「UXPin Mergeの大きな影響の1つは、高忠実度のプロトタイプを作成できるようになったことです。最終製品がどのように見えるか、UXやインタラクティブ性に関して、デザイナー、経営陣、ディレクター、デベロッパーを含む全員がより確信を持てるようになり、ステークホルダーからより質の高いフィードバックを得られるようになりました。」- Paypal 社 UX Lead EPX、エリカ・ライダー氏

TeamPassword

TeamPasswordは、競争の激しいパスワード管理市場で事業を展開する、５名からなる（２０２３年２月現在）スタートアップ企業です。TeamPasswordにはUXチームがなく、エンジニアが新しいリリースのプロトタイプとテストを行う必要があります。

Mergeに切り替える前は、TeamPasswordのエンジニアが各プロトタイプを開発していたこともあり、リソースが限られた企業にとっては時間のかかるプロセスでした。そこで２０２２ 年、TeamPasswordはUXPin Mergeに変更し、カスタムMUIのデザインシステムを同期させました。

「Code to Design」のワークフローに変えてからは、TeamPasswordの市場投入スピードは劇的に改善され、製品に使い勝手の問題や矛盾がなくなり、それによって企業の競争力が高まりました。

革新的な「Code to Design」のソリューションで「Design-to-Code」のワークフローを改善しませんか？詳細はMerge のページをぜひご覧ください。

The post 「Code to Design」か「Design to Code」どっちがいい？ appeared first on Studio by UXPin.

新しいデジタル製品を市場に送り出すことは、間違いなくやりがいのあることです。自分たちの努力が、満足したリピーターやROIという形で返ってくることほど、チームのモチベーションを高めるものはありません。とはいえ、常に太陽と虹が出ているわけではありません。発売を成功させるための道のりは、製品開発のリスクに満ちた、厳しく困難なものです。

しかし、良いニュースもあります。デジタル製品のデザインで遭遇する可能性のある課題を認識し、準備しておけば、製品開発プロセスに大混乱をきたすことはありません。

そこで私たちは、10人の専門家に、製品開発における課題をどのように解決したのか、その経験を語ってもらいました。ここでは、その結果をご紹介します:

10人の専門家が語る、製品設計における最重要課題とその解決方法

まずは、（おそらく）最も一般的な課題である、お客様のニーズやペインポイントに確実に対応することから始めましょう。そこで、CondoblackbookのSep Niakan氏とTop Mobile BanksのTommy Galagher氏に、それぞれの見解を伺いました。ここでは、彼らの意見をご紹介します:

1. お客様のペインポイントを特定する

​​

Sep Niakan、 Condoblackbook マネージングブローカー

お客様の痛みの問題を見極めることは、商品開発の初期段階から最優先されるべきです。お客様のニーズに基づいて、お客様のニーズを直接表す明確な商品目標を設定することができるはずです。これは当然のことのように思えるかもしれませんが、多くの企業は正反対のことをしています。つまり、製品が発売された後に消費者調査を行うのです。お察しのとおり、これは非常に後ろ向きで、コストも時間もかかる戦略です。製品テストは、開発の早い段階から始め、ずっと続けていくべきです。定期的に徹底的なテストを行うことで、お客様があなたのビジネスや製品に何を求めているのかを正確に把握することができるのです。

Top Mobile Banksの創業者であるトミー・ギャラガー氏も、製品開発の中心は顧客であるべきだと考えている。

新製品を開発しようと思っても、顧客のペインポイントを把握していなければ、失敗してしまいます。消費者のロイヤリティーがなければ、お金も出てこないし、それが会社の破滅につながります。定義された目標を持たずに運営されている企業、顧客が支払う準備ができているかを理解していない企業、顧客の要求に優先順位をつけられない企業は、すべて企業の失敗の要因となります。

すでに製品を発売している企業が、最初から研究を行うことを選択したとしても、かなりのコストがかかります。そのため、製品の開発が大幅に遅れるだけでなく、効果のない発売によってモラルや潜在的な市場シェアに水を差すことにもなりかねません。

製品の構想から製造までの開発プロセスにおいて、製品のテストと実験を確実に行う。多くのビジネスは、製品を設計することから始まり、それをどうやって売るかを考えます。製品の最終的な成否は、お客様にかかっています。お客さまが喜んで支払ってくれるものは何か、お客さまのニーズを満たすものは何か。製品が本格的に発売されるのを待つのではなく、開発プロセスの中で研究、実験、テストを行うべきである。

2. 目先の要求と長期的な目標のバランスをとること

Robert Johansson, imgkits CEO & テックエキスパート

私が遭遇した製品開発のリスクのひとつは、目先の要求と長期的な目標のバランスが取れていないことです。製品開発において、短期的な要求と長期的な目標のどちらにどれだけの資金を投入すべきかを判断するのは難しいことです。試作や研究などの先行投資は怖いものですが、大局的に考えることが大切です。製品開発で手を抜くと、長期的にはビジネスに大きなダメージを与えることになります。

3. 創造性の欠如

Garth McAlpin,  Classic Architectural Group デザイナー、ディレクター、ナショナルフルフィルメント

製品開発において、チームにとって最大の課題の一つは、クリエイティブブロックに直面することです。新しい革新的なアイデアを生み出すことは難しい作業であり、どんなにクリエイティブな人でも、時には障害を感じることがあります。これは、お客様のニーズに関する洞察力の欠如、組織のお役所仕事、製品開発チームとマーケティングとの間の非同期性などが原因で起こります。私も昨年、チームでこの課題に直面し、自分のキャリアの中で最も困難な局面のひとつとなりました。

クリエイティブ・ブロックを克服し、アイデア創出を再開するために、私は組織全体に「アイデア・バスケット」を設置しました。各社員には、現行製品についての意見や、新製品に求める機能やサービスについての意見を出してもらいました。最初のうちは、誰もが気後れしたり躊躇したりして、反応は鈍かった。しかし、私たちはこれを部門間の競争に変えました。優勝した部署には、チームの夕食代としてボーナスが支給されることになったのです。数日のうちに数多くのアイデアが集まりました。

これらのアイデアは、私の製品開発チームのインスピレーションとなりました。同僚の意見を読むことで創造性が刺激され、いくつかのアイデアを修正して実現可能な新製品を生み出すことができたのです。アイデアが採用された社員には、その努力が認められた。

4. アイデアの生成

Robert Johnson, Sawinery 創設者

すべてはアイデアから始まります。しかし、アイデアを生み出すのはそれほど簡単なことではありません。考慮すべき要素が山ほどあり、非常に困難な作業となります。このような障害を克服するために、すべてのチームはブレインストーミングを行い、さまざまな視点からアイデアを収集する必要があります。そうすることで、チームはそれぞれのアイデアを簡単に評価することができますし、あるアイデアを別のアイデアにつなげて、高い可能性を持つものを生み出すこともできます。

Darshan Somashekar, Spider Solitaire Challenge. 創設者 & CEO

コンセプト生成の初期段階から設計、実装に至るまで、製品の競争戦略やコストニーズの管理に関しては、様々な製品やソフトウェア開発企業が多くの挫折を経験しています。複雑な設計仕様や機能要件の中に、いくつかの売れる機能が埋もれてしまい、予想される競争力に対応できないということがよくあります。同様に、ソリューションが運用されると、時間の利用や運用コストに関する重要な要件に適用されます。お客様から見て特定のレベルの競争力を目指しても、収入が得られないことがあります。

家を新築するのと同じように、開発して発売した後の製品アーキテクチャの微調整は難しい。既存の製品から始めるのか、それとも最初から始めるのかをしっかり把握しておきましょう。最初から始める場合は、不可能ではありませんが、時間とコストがかかります。

5. 適切なチームを編成する

Mike Dragan,  Oveit COO

製品の開発は共同作業であることは言うまでもありません。だからこそ、最高の製品開発チームを編成することが非常に重要なのです。このチームは社内で結成することもできますが、外部の専門家チームと協力することが有益であると考える企業もあります。製品開発やプロジェクト管理を成功させるためには、マーケティング、販売、製品発売の計画を明確にすることが、社内・社外を問わず重要です。

6. 適切な製品アーキテクチャの構築

Jason McMahon here, Bambrick デジタルストラテジスト

優れた製品アイデアを市場に投入できないのは、製品管理プロセスを適切に整理・定義できていないことが大きな原因です。最初のブレーンストーミングでは、プロダクトオーナーの存在なくして成果は生まれない。たとえプロダクトオーナーがいたとしても、コンセプト段階を超えるための手順が十分に確立されていなければ、大半のアクションは起こせません。プロダクトオーナーは、技術的に優れているだけでなく、顧客満足度、収益性、発売時期など、製品の主要な目的を遵守する必要があります。

新製品をリリースする際には、プロダクトマネジメントが不可欠です。あなたとあなたのチームが同じ見解を持ち、目的が明確であることを確認してください。戦略を立て、明確な目標を設定し、新製品のために受け入れられる最低利益率を決定しなければなりません。顧客の反応を良くするために、マーケティングプラン、販売計画、発売戦略、コールトゥアクションなどを明確にしましょう。

7. 製品ビジョンの適応

Michael Varga, Creative Navy UX Agency シニアデザイナー 

プロジェクトが進むにつれて、製品のビジョンを適合させるのはますます難しくなります。ゲームの後半になって、確立したビジョンに挑戦する側面を発見することもあります。多くの人は、この新しい洞察を無視して矛盾を合理的に解消したり、「これを発売する必要がある」と言って当初の設定通りに進めることを正当化したがります。これらの反応の核心は脆弱性にあります。人々は、（プロダクトマネージャーとして）失敗すること、間違っていること、世間知らずや近視眼的だと思われることなどを恐れています。この恐怖心は、「自分の価値は、自分が知っていることやコントロールできることにある」という誤った印象に根ざしています。優れたプロジェクトマネージャーは、自分がすべてを知っていると思っていても、実はまだ何も知らないことを知っています。デザインプロセスはシステマティックではあるものの、曖昧さに悩まされます。できるだけ多くの有益な情報を見つけ出し、それにうまく対応することができる人が、市場をリードする製品を生み出すのです。デジタル製品の分野では、勝者がすべてを手に入れることができます。素晴らしい製品があれば、それまでの100種類の凡庸なバージョンに費やした時間を取り戻すことができる。

8. リモートチームとの非同期作業

Carey Fan, ChessKid CEO

私たちは、完全に遠隔地にいるデザインチームと、複数のタイムゾーンをまたいで非同期に仕事をしなければならないという課題に直面している、疑似スタートアップです。私たちは小規模なので、スクラップしなければなりません。つまり、私たちのチームは複数の帽子をかぶっているのです。例えば、iOSデベロッパーのリーダーであるGuersonは、プロダクトデザイナーの顔も持っています。彼には優れたデザインの勘があります。彼にプロダクトのオーナーシップを与えることで、より頻繁にリリースできるようになりました。Guersonが製品デザインの多くの重要な改善を指揮したことで、私たちのChessKidアプリは、500件以下のレビューしかなかった低評価から、17,000件のレビューで4.7の評価を得ることができました！

また、オープンな文化を構築する必要があります：Win-Win-Win。製品の改良や大きな機能のアイデアは、組織内のどのレベルからでも生まれてきます。誰からでも製品の意見を聞くことができる文化を持つことで、社員はより製品に愛情を注ぐようになります。その愛情と情熱は、ユーザーにも伝わっています。毎日のように、子供たちから「今までに経験したことのない最高のオンラインチェスです」などの声が寄せられます。最終的には、スケーラビリティ、スタッフ、そしてお客様にとっての勝利です。チェックメイト!

9. 効果的なワークフロー管理

Nathan Gill, Epos Now チーフプロダクトオフィサー  

製品開発における最も一般的な問題と課題の一つは、リーダーがワークフローを適切に管理できないことです。チームが効果的に連携していなければ、最終製品のスピードと品質に支障をきたすことになります。プロダクトマネージャーは、チームの全員が同じ考えを持つことの重要性を理解する必要があります。チームのすべてのメンバーと同時にオープンにコミュニケーションをとり、コンフリクトがあればすぐに解決する必要があります。

エポスナウでは、ワークロードを効率的に管理するために、Trelloという素晴らしいツールを使っています。プロダクトマネージャーは、製品を取り巻く業務を整理することができます。チームは一元化されたダッシュボードで作業を行い、タスクと期限を完全に把握することができます。これにより、個人が責任を持ち、全員が即座にコミュニケーションを取ることができます。

プロダクトデザインの課題に取り組む – PayPalにおけるTPX DesignOps 2.0

上記のような課題は中小企業に多く見られるものですが、企業ではどのようにして大規模な遠隔協力やワークフローに取り組んでいるのだろうかと疑問に思われるかもしれません。

その好例が、PayPalのDesignOps 2.0と呼ばれるアプローチです。彼らのユニークな方法論については、UXPin Merge – PayPal のウェビナーをご覧ください：

とりわけ、PayPalがどのようにしているかを学ぶことができます：

• 従来の製品設計・開発モデルへの挑戦
• 速さ、品質、およびコミュニティを優先する
• UXPin Merge を使用して明確なガイドラインを作成し、デザイナーと開発者間の協力関係を改善する、などが紹介されています。

まとめ

この記事でご紹介したように、デジタル製品の開発中には、チームが直面する製品設計上の課題がいくつかあります。私たちからのアドバイスです。まず第一に、古典的なことわざにもあるように、他人の失敗から学ぶことです。次に、デザイナーと開発者が協力して作業を進めるために、適切なツールを使うことです。ここでUXPin Mergeのようなソリューションが活躍します。デザイナーが既存のコードコンポーネントを使用することで、製品開発プロセスを通じて開発者とシームレスにコラボレーションすることができます。

最後に、この記事を今後の参考のために保存するか、デザイナーと共有することをお勧めします。ここで得られたアドバイスは、製品開発の大きな助けとなることでしょう。

The post 10人の専門家が語る、製品開発の課題とその解決方法 appeared first on Studio by UXPin.

 デザインプロジェクト管理 は、クリエイティブディレクション、UXデザイン、DesignOps、デザインリーダーシップなど、いくつかの主要な UX 機能をまとめて成功に導くものです。

本記事では、 デザインプロジェクト管理の規律、マネージャーのスキル、関連ツール、そして開始から最終納品までの５つのステージについて見ていきます。

UXPin Mergeを使ったクオリティが高くインタラクティブなプロトタイプで、デザインプロセスでより良い結果を得ませんか。他のデザインツールとは一味違うこの技術の特徴をぜひご体験ください。Mergeのページをご覧になりたい方はコチラ。

 デザインプロジェクト管理 とは

 デザインプロジェクト管理 は、デジタル製品開発プロジェクトのデザインプロセスをまとめ、リソースの配分、業務委任、目標設定、ステークホルダーへの報告など、プロジェクトに関連する機能を果たします。

 デザインプロジェクト管理 の機能は従来のプロジェクト管理と似ていますが、マネージャーは効果的なプランと戦略の実行のために、デザイン思考、UX リサーチ、UX（ユーザーエクスペリエンス）の原則を理解していないといけません。

デザインプロジェクトマネージャーに必要な５つのスキル

以下に、デザインプロジェクトマネージャーにあるべき必須スキルを５つ挙げます。

１．UXデザイン

UX デザインは、通常のプロジェクトマネージャーに対して、デザインプロジェクトマネージャー特有のスキルの１つであり、この知識があることによって、現実的なロードマップとプロジェクトのタイムラインの確定や、リソースの効果的な配分、さらにはチームメンバーの適材適所で割り当てができるようになります。また、このような UX デザインのスキルで、デザインプロジェクトマネージャーはステークホルダーとのコミュニケーションが取りやすくなります。

UX デザインのスキルは、業務で身につけることも、UX デザインの学位を取得して正式に身につけることも可能です。

２．技術面の理解

デザインプロジェクトマネージャーはコードを学ぶ必要はありませんが、製品のフレームワークや技術的な制限についての基本的な理解は持ち合わせていないといけません。技術的なスキルがあれば、エンジニアリングチームやステークホルダーと協力したり、納期が遅れた場合の影響をデザイナーにきちんと説明ができるようになりますからね。

３．コミュニケーション

デザインプロジェクトマネージャーには、組織のあらゆるレベルのチームメンバーとの連絡や連携が取れるような、優れたコミュニケーション能力が必須です。また、デザイナーとエンジニアのコミュニケーションギャップを埋めるために、デザインミーティングや部門横断的なミーティングを円滑に進める必要があり、UXと技術に関する基礎知識の重要性が再認識されます。

適切なツールがあれば、連携は円滑になり得ます。関連記事：Top Design Collaboration Tools.

４．リーダーシップ

リーダーシップは、どのようなプロジェクトマネジメントの役割においても重要な要素です。デザインプロジェクトマネージャーは、厳しい納期で大変な仕事をこなすために、プロジェクトチームのメンバーを動機付け、指導しないといけないようなことが多々ありますし、プロジェクト内の衝突を解決するのに不可欠な役割を果たすため、公平な調停役としてチームから尊敬される存在でないといけません。

５．リソース管理

デザインプロジェクトマネージャーは、プロジェクトの期日、成果物、予算、チームメンバーに対して責任を担い、計画通りに物事が進まない場合に、このようなリソースを管理する方法を理解し、不測の事態を想定した是正措置を行わないといけません。

プロジェクトマネジメントのフレームワークと手法をデザインする

 デザインプロジェクト管理 のフレームワークは、通常のプロジェクトマネジメントとあまり大きな違いはありません。ここでは、デザインプロジェクトでよく使われるフレームワークを５つご紹介します。

１．アジャイル開発

アジャイル開発は、より短い計画サイクルや、市場、製品、技術などの変更、WIP（ワークインプログレス）、漠然としたプロジェクト目標に柔軟に対応できる反復型のプロジェクト管理手法です。アジャイルは、この柔軟性のおかげで、新しい技術やトレンドがプロジェクトの方向性を左右するデジタル製品開発においてよく使われています。

２．スクラム

スクラムは、複雑なプロジェクトを消化しやすい短期的な目標やスプリントに分割するアジャイルフレームワークです。スプリントは２～４週間で、チームは１つの問題を繰り返しながら、最適な解決策を探します。

３．カンバン

カンバンは、列やセクションを持つカンバンボードを使ってプロジェクトとそのタスクを可視化する透明なフレームワークであり、通常は以下の３つのカラムがあります：

• やること
• 進行中（WIP：ワークインプログレス）
• 完了

チームメンバーは、各セクションの開始と終了を繰り返しながら、タスクを移動させていき、場合によっては、プロジェクトマネージャーによって「レビュー中」「QA（品質保証）」「バックログ」などの列が追加されることもあります。

４．Lean UX

Lean UX は、特定の問題解決のために、デザインプロセスで多くの実験を行うことに焦点を当てた、共同成果ベースのフレームワークであり、デザイナーは、「あったらいいな」的な機能ではなく、最大限の価値を提供するソリューションを提供する必要があります。

５．ウォーターフォール開発

ウォーターフォールは、以下の５つの静的なフェーズからなる一連の流れを持った方法論です：

• 要件
• デザイン
• 実装
• 制御
• 終結

これは、次の段階に移る前に各段階を完了させることを目的としています。ウォーターフォールは、エラーやイテレーションの余地がない、厳格なプロジェクト管理手法であり、プロジェクトの予算、要件、スコープが明確に定められており、柔軟な対応が必要でない場合はウォーターフォールを使うのが一般的です。

 デザインプロジェクト管理のためのソフトウェア

デザインチームは、プロジェクト管理ソフトウェアやさまざまなデザインツールを使ってプロジェクトを完成させます。

プロジェクト管理ツール

プロジェクト管理ソフトウェアは、タスクの確定やワークフローの管理、一元化されたレポジトリでの進捗の追跡に欠かせません。以下は、クリエイティブチームによく使用されるプロジェクト管理アプリです：

• Trello
• Asana
• Notion
• Wrike
• Monday.com

ホワイトボードとブレーンストーミング

デザイナーは、デザインプロセスを通じてホワイトボードツールを使って、共同作業やアイデアの共有を行っており、よく使われる例としては、以下のようなものがあります。

• Miro
• Mural
• Google Jamboard

ユーザーリサーチ・テスト

リサーチとテストは、あらゆるデザインプロジェクトに不可欠であり、デザイナーは、参加者の募集、スケジュール、テスト/分析、支払いなどに様々なツールを使用します。以下に例をいくつか挙げますね：

• Ethnio
• User Interviews（リサーチサービス）
• Userback
• Hotjar

チームでのコミュニケーション

特にリモートワークの環境では、チームメンバー同士や他の組織とのつながりを保つために、コミュニケーションは非常に重要です。ツールとしては以下のようなものが挙げられます：

• Slack
• Google Chat & Spaces
• Microsoft Teams

デザイン＆プロトタイピングツール

デザインツールで、デザイナーはユーザーフロー、ワイヤーフレーム、モックアップ、プロトタイプの作成ができるようになります。一般的なデザインツールには以下のようなものがあります：

• UXPin
• Figma
• Sketch
• Storybook

プロジェクトマネジメントにおける５つのステージ

プロジェクトマネジメントには以下のような５つのステージがあり、デザインプロジェクトもこれに従います：

• 開始
• 計画
• 実行
• 監視
• 終結

１．開始

デザインリードとステークホルダーは、以下の２つのドキュメントを確認して、デザインプロジェクトを開始するか決めます。

• ビジネスケース：プロジェクト、イニシアチブ、または戦略の利点と、会社や部門がそれを必要とする理由を概説するもの。
• 実現可能調査：問題を確定し、デザインプロジェクトがその問題を解決できるかどうかを検討する。

進めることを決定した場合、組織は以下を含むプロジェクト開始文書（PID）を作成します：

• プロジェクトの範囲と目標
• 制約条件
• 予算
• リスク査定
• 主要なステークホルダー
• コントロールとレポーティング
• 納期と納品
• デザイン概要

２．計画

PIDとデザイン概要に続いて、デザインプロジェクトマネージャーと様々なステークホルダーが、スコープ、ゴール、タスク、スケジュール、リソースなど、プロジェクトのロードマップを確定します。

デザインプロジェクト計画の典型例として、以下のようなものがあります：

• 時間、予算、労力など、利用可能なリソース
• 役割と責任
• プロジェクトのマイルストーンと目標
• KPI（重要業績評価指標）
• 報告間隔
• リスクと不測の事態
• プロジェクトツールおよびコミュニケーション方法
• プロジェクトの成果物、ファイル形式、納品方法（Dropbox、Google Driveなど）。

３．実行

通常、プロジェクトの ”キックオフ” は、チーム全体とステークホルダーが集まって、プロジェクトが解決すべき問題や関連する成果物について話し合うところで始まります。そこでデザインチームは、プロジェクトのフレームワークと割り当てられた責任に基づいて作業を開始します。

４．監視

監視は、プロジェクトマネージャーの主な責任であり、実行と並行して行われます。プロジェクトマネージャーは、KPI、予算、タスクを監視し、プロジェクトが軌道に乗るようにするとともに、潜在的な要件や仕様の変更や追加に細心の注意を払い、ステークホルダーと定期的にミーティングを行って、報告やアップデートを行います。

５．終結

プロジェクトの終結は、デザインチームがデザインハンドオフの準備が整った時点で行われます。また、場合によっては、ステークホルダーが不測の事態によるプロジェクトの解消で終わることもあります。

終結タスクの例として、以下のようなものがあります：

• エンジニアへのデザインハンドオフ
• 品質保証または UX監査 の完了
• 将来のための UX の成果物アーカイブ化
• ソフトウェアのサブスクリプション、請負業者など、サプライヤーとの契約解除
• 最終予算と報告書のステークホルダーへ提示
• チームメンバーの解放

UXPinでデザインのプロジェクトデリバリーを改善しよう

プロトタイプとテストは、どのデザインプロジェクトにも欠かせません。デザイナーは、デザイン概要とユーザーのニーズに従ってプロジェクトの核となる問題を確実に解決しながら、時間内に納品するために迅速なイテレーションが必要ですが、残念ながら従来の画像ベースのデザインツールでは、これがうまくいくために必要な忠実度と機能性が不足しています。

UXPin Merge は、デザイナーとエンジニアの間のギャップを埋めるコードベースのデザインツールであり、デザイナーは、デザインシステムのレポジトリから取り出したインタラクティブなコンポーネントを使って、完全に機能するプロトタイプを構築することができます。

このコンポーネント駆動型のプロトタイピング法により、デザイナーはデザインプロセスを拡張しながら、より速いイテレーションができるようになります。例えば PayPal は、２０１９年に社内の UXチームが UXPin Merge に切り替えた際に、このコンセプトを企業レベルで証明しており、現在、PayPal の製品チームは、経験豊富な UXデザイナーが従来のデザイン手法で以前できたよりも８倍速く、デザインプロジェクトの９０％を完了させています。

「UXPin Merge で、この「一緒に留める」タイプのデザインを実行できるようになり、製品チームには、UI（ユーザーインターフェース）を構築するためにドラッグ＆ドロップできるコンポーネントが提供されます。製品チームは、余白とコンポーネントを固定したレイアウトを作成するため、すべてが見た目通りに機能するようになります。なのでデザイナーは、出来栄えをいちいち取り締まる必要も、製品デザインのために踏み込む必要もないのです。」- PayPal 社 UXリードEPX、エリカ・ライダー氏

より質の高いプロトタイプによる、より良いテスト

Merge のコンポーネントがあれば、デザイナーは最終製品と見分けがつかないほどのプロトタイプを作ることができます。また、そのような高品質なプロトタイプによって、ユーザーテストから実用的な結果を得ることができ、ステークホルダーからの有意義なフィードバックも得られます。

よりスムーズなデザインハンドオフ

デザインから開発への移行は、デザイナーとエンジニアが同じレポジトリから同じコンポーネントライブラリを使用するため、UXPinを使えばシームレスです。

フロントエンドエンジニアは、デザインシステムのパッケージをインストールして、UXPinからプロトタイプのレイアウトをコピーします。そして UXPin Merge は各コンポーネントの JSX をレンダリングし、デベロッパーはスペックモードで見ることができます。

「この新しいUXPinのアプローチでは、より協働的で統合的なデザインプロセスが実現されます。デザイン、プロトタイプ、開発を分離するのではなく、UXPinによって、プロセス全体を通してエンジニアリングチームとプロダクトチームが関与する統合的なフローの構築ができ、その結果、製品の最終的な品質は劇的に向上しました。」- PayPal 社 UXリードEPX、エリカ・ライダー氏

世界最先端のデザインツールで、 デザインプロジェクト管理 を強化しませんか。Merge のページで、画期的なテクノロジーを使い始める方法をぜひご覧ください。

The post デザインプロジェクト管理 入門【必要なスキルやツール】 appeared first on Studio by UXPin.

 プロダクト思考 とは「UXデザイン」と「製品管理」が交わることで、組織とユーザーにとって価値を生み出す成果を提供することです。 プロダクト思考 にはフレームワークがいくつかありますが、「製品の成功のために、明確なゴールと測定可能な KPI で問題とソリューションの適合性を見出す」というコンセプトがベースにあります。

企業規模に関わらず、 プロダクト思考 の考え方を身につけるのは、現代の製品開発と競争が激しい環境において極めて重要です。今作ろうと思っているものは、すでに何らかの形で存在しているとなると競合他社が気づいていない、あるいは満たしていない問題や機会の特定が鍵になってくるのです。

実験とは、 プロダクト思考 と正しいソリューションを見つけるための核となるものであり、そのような実験には、アイデアや仮説をテストするための MVP （Minimum Viable Product）やプロトタイプが必要です。UXPin Merge は、プロダクトチームにデザインツールの経験がほとんどなくても、高忠実度で完全に機能するプロトタイプを作成できるようにする機能性があるデザインツールです。詳しくは Merge のページをぜひご覧ください。

 プロダクト思考 とは

 プロダクト思考 とは、ユーザーの問題に対して価値あるソリューションを開発するための問題解決手法のことであり、ユーザー、技術、ビジネスの目標がどのように交わり、顧客に利益をもたらす製品を提供し、プラスの投資対効果を生み出すかを考えます。

プロダクト思考の基本的な目的の１つに、「機能ではなく、価値を出すこと」があります。「これはいいね、顧客も喜ぶでしょう」ではなく、プロダクト思考はチームに「これは問題を解決するか？顧客はこれを使うだろうか？顧客や組織にとって価値があるものなのか？」と問いかけを強いるものです。

 プロダクト思考 は、プロダクトチームが新たな問題、ユーザー、市場を探求し、製品のライフサイクルを延長させるのに極めて重要です。

「 プロダクト思考 」と「デザイン思考」

 プロダクト思考 とは、ユーザー、市場、競合他社、ビジネス目標、およびその他の影響要因を理解するための全体的な手法です。組織が新製品をデザインするとき、製品管理チームは プロダクト思考 を使って問題を理解し、技術を使ってその問題を解決する方法を決定します。

対するデザイン思考は、よりユーザー中心で、特定のユーザーの問題を解決することに焦点を当てます。 プロダクト思考 が何を作るかを確定するのに対し、デザイン思考は UX を考慮し、製品内の特定のユーザビリティ問題を解決します。

両者の最大の共通点は、ユーザーとユーザーの問題を前面に押し出していることであり、主な違いは、 プロダクト思考 が複数の要素や複雑さを包含する広い考え方であるのに対し、デザイン思考は UX にフォーカスしている点です。

 プロダクト思考 のプロセス

メリッサ・シルク氏は、Mind the Productのウェビナーで、３つのパートからなる プロダクト思考 のフレームワークについて概説しています。このフレームワークは、デザイン思考プロセスの多くの特徴を備えていますが、より広い範囲とビジネス目標、市場、競合他社をより重視しています。

問題

プロダクトマネージャーは、まず問題の特定から始めます。この最初の段階は、デザイン思考プロセスの共感と確定のステップに似ていますが、ユーザーだけでなく、市場や競合他社を理解することにも目を向けます。プロダクトチームは、ユーザーの問題を特定してそれを多角的に分析し、その問題を解決することの価値を判断します。

プロダクトチームが問題を確定するのに使う重要なリサーチツールは２つあります：

• ユーザーペルソナ：ユーザー、その動機、習慣、環境、問題の把握
• JTBD（ジョブ理論）：革新的なソリューションを特定するために、複数の視点から市場、顧客、ニーズ、競合他社、および顧客セグメントを視覚化する手法

プロダクトチームがステークホルダーのために問題を確定するのに使えるテンプレートは２つあります。

基本的なテンプレート：

• 問題やペインポイントの説明
• 組織が問題を解決する方法
• 成功のための KPI 

高度なテンプレート(5W1H):

• 「何」が問題か
• 「誰」に影響を与えるか
• 「なぜ」この問題が重要なのか
• 「どこで」この問題が起こるか
• 「いつ」この問題が起こるか
• 「どのように」この問題を解決できそうか

機会

次に、プロダクトチームは、問題を解決できそうな方法や、それが組織とそのユーザーにとってどのような意味を持つかを、機会の大きさや投資対効果も含めて評価します。また、市場機会についても検討し、この問題を解決することで、組織の市場シェア拡大や、新しい顧客獲得が実現できるかを検討します。

また、機会を評価しながら、プロダクトチームはアイデアや仮説を検証するためにプロトタイプを作ることもあります。

ソリューション

最後に、プロダクトマネージャーは結果を分析し、どのソリューションが最も問題を解決できるかを決める必要があり、その際、以下のような要素が複数考慮されないといけません：

• 考えられる ROI
• 資金的、人的資源的、技術的制限などの制約
• この問題の解決が、現在の製品ロードマップとどのように整合するか
• この新製品は、組織の目標に合致しているか

製品作りのための プロダクト思考 の活用法

元 Google のプラシャント・ナイル氏が、 プロダクト思考 の実践的なテンプレートについて概説しており、プロダクト思考は多くの製品フレームワークのように直線的なものではないと主張しています。その代わりに、プロダクトチームはプロセスを進めながら「継続的な再調整」を行い、機会を特定します。

プラシャントの プロダクト思考 テンプレートには８つの「ボックス」があり、それぞれにアイデアを深く掘り下げ、ストレステストするための質問が用意されています。

1. ユーザー
2. 市場
3. ソリューション
4. ビルド
5. チーム
6. 測定
7. リサーチ
8. 反復

PM（プロダクトマネージャー）は、各ボックスを体系的に確認することから始め、アイデアや機会があれば、どのボックスにも飛べます。

１．ユーザー

最初のボックスは、ユーザーを特定し、そのニーズを理解することです。

以下を聞いてみましょう：

• 直接のユーザーは誰か
• 影響を受けるユーザーは誰か
• ユーザーは何を達成しようとしているのか

上の質問は例なので、実際には製品や市場についての具体的な質問が他にも出てくるかもしれません。このステップでは、ユーザーの動機、問題、目標、ニーズやほしいものなどを深く理解することを目的としており、このデータを使って プロダクト思考 のプロセスをガイドするためのペルソナを作成できます。

２．市場

２つ目のボックスは、市場を見ます：

• ユースケースは現在どのように満たされているのか
• ギャップや機会はあるか
• そのギャップは解決する価値があるほど大きいか
• 市場のプレーヤーはなぜその問題を解決しないのか

ボックス２の主な目的は、マーケティングの機会を特定し、その解決に価値があるかどうかを評価することです。問題を特定したら、競合他社がその問題に取り組んでいない理由を深く掘り下げて理解することが極めて重要です。

３．ソリューション

最初のボックス２つは、問題や機会を見つけるためのものですが、続く２つのボックスは、ソリューションと提供に焦点を当てます。そして３つ目のボックスである「ソリューション」にいきます：

• ソリューションは、ユーザーに価値を提供するギャップに対処しているか
• ソリューションの持続可能に向けて、その価値を十分に収益化できるのか
• １０倍のイノベーションを発掘できたか

４．ビルド

４つ目のボックスでは、課題を洗い出しながらMVP（Minimum Viable Product）を構築することを考えます：

• どのように迅速かつ安価にソリューションをテストできるか
• どのように問題を予見してチームに立ちはだかるブロックを解除するか
• 確実にスムーズに降り立つにはどうすればいいか

ビルドのボックスは、ソリューションをテストすることを目的としており、PMは、仮説を検証するための費用対効果の高い方法、すなわちプロトタイプが必要です。プロトタイプの段階で、プロダクトチームは新しい機会を発見する可能性があり、そうなると、さらなる調査のために前のボックスに戻ります。そしてそこからまたビルドボックスに戻って新しいアイデアを反復する、といった具合です。

同時に、PMはソリューションに関連するあらゆる問題を予測しなければなりません。その例として、以下のようなものがあります：

• 規定または法的な影響
• 組織的な制限とキャパシティ
• コストとリソースの課題
• 技術的な制約

最後に、PMはこのソリューションでどのように市場に参入するか、そのプロセスはどのようなものかの検討が必要です。

５．チーム

５つ目のボックスは、組織の現在のリソースを見るものです：

• 適切なスキルやモチベーションがあるか
• インセンティブは一致しているか
• このプロジェクトを成功させるための資金やスポンサーはあるか

スキルやリソースがなければ、ソリューションは冗長で、振り出しに戻らなければならなくなるので、「チーム」のボックスは非常に重要です。

PMは、そのソリューションが組織の価値観、目標、ロードマップに合致しているかどうかも評価しなければなりません。優れたソリューションがあっても、それが組織を新たな方向へ導くものであれば、悪影響が出る可能性がありますからね。

６．測定

６つ目のボックスは、成功度を測るためのKPI（重要業績評価指標）を見ます：

• 正しい方向に向かっているかどうかを教えてくれるメトリクスは何か
• 継続的に追跡するための測定はできているか
• 失敗したとき、何がうまくいっていないのかを知るための十分な粒度があるか

PMは、ビジネスや製品のメトリクスを特定し、場所、年齢、言語、性別など複数のデモグラフィックでそれを測ります。

そのようなメトリクスをデザインする際に最も重要なのは、問題をピンポイントで特定する能力があるか – の「粒度」です

７．リサーチ

継続的なリサーチによって、プロダクトチームは市場や競合他社の変化に対応することができます。

チームが行う質問には、以下のようなものがあります：

• 外的要因を追っているか
• インサイトを生み出すことができているか
• そのインサイトは適切なフォーラムで公開されているか

市場や競合他社などの外部要因を把握するのは、それによって製品が無駄になる可能性があることから非常に重要です。例えば、米国で新しい暗号製品を開発している場合、政府が新たなライセンスや監視を必要とする法案を可決すれば、市場投入までの時間やコストが増大する可能性があります。あなたの会社には、こうした新しい要件を満たすためのリソースがない可能性もありますよね。

外部の変更により、PM は前のボックスに戻って新しい問題に対処し、現在のソリューションを適応させる必要があります。このような研究体制が整っていないと、PM はもはや市場に適合しない、あるいはユーザーに貢献できない製品を提供する危険性があります。

８．反復

最後のボックスは「反復」で、すべてのボックスに当てはまるものです：

• 実験する文化を育んできたか
• データに基づいた意思決定ができているか
• どれだけ早く適応できるか

Google は、世界をリードする技術革新の一つであり、実験を奨励し、失敗を「学習経験」としてとらえ、否定的な意味合いを排除することによってそれが実現されています。イノベーションと優れた製品は、何度も繰り返されることで生まれますが、失敗を恐れているチームメンバーは、新しいことに挑戦せず、結果的に平凡なものになってしまいます。

プロダクトチームは、「測定」ボックスで確定された KPI を使って、各反復を測定する必要があり、その KPI は、何かしらうまくいっていないとき、その理由をチームメンバーに伝えるのに不可欠です。チームはこのデータを使って、変更を加え、反復することができますし、データ駆動型の意思決定は、チームがアイデアを完全に放棄するタイミングを知らせてくれますからね。

プロダクトチームは、各ボックスを体系的に調べてベースラインを作成しないといけません。そして、１つのボックスに変更が加われば、他の７つのボックスを再調整して、製品アイデアの全体像を把握する必要があります。

UXPin Merge – 究極のプロダクトデザインツール

UXPin Merge で、UXデザイナーとプロダクトチームは、インタラクティブなコンポーネントを使って完全に機能するプロトタイプを構築でき、プロダクトチームは、従来のデザインツールやコードよりも早く、新しいアイデアの反復や仮説のテストを行うことができます。

「UXPin Merge を使ったら、プロダクトマネージャーは、１ページのプロトタイプを８～１０分で作れるようになりました！以前は、リソースやデザイナーが限られていたため、１ページの製品を作るのに、モックアップのデザインだけで２～３ヶ月かかっていましたが、今では、プロダクトチームは同じ期間内に製品をデザインして提供できるようになりました。」 – Paypal のUXリードEPX、エリカ・ライダー氏

世界最先端のデザインツールで、製品思考に革命を起こし、より良いMVPを作りませんか。詳しくは Merge のページぜひご覧ください。

The post プロダクト思考 とは？重要な理由 appeared first on Studio by UXPin.

プロトタイプが完成するとデザイナーは開発者にプロトタイプを渡します。このようなプロセスは、両方にとって大変な作業になってしまいます。デザインハンドオフを手助けするデザインツールは数多くありますが、プロトタイプを開発者へ渡す流れでそれぞれのツールにどのような違いがあるのでしょうか。

よく使われるデザインツールにおいて大きな違いのひとつは、デザイナーの仕事の最終成果物である製品のプロトタイプに対するアプローチ方法です。プロトタイプをベクタグラフィックスにレンダリングするものもあれば、コードにレンダリングするものもあります。

UXPin Mergeを使用すると、デザイナーは最終製品で使用される正しいコンポーネントを完全に機能するインタラクティブなプロトタイプで構築することができます。

GitHubリポジトリやStorybookからUXPinのエディタに完全にコード化されたコンポーネントを同期させることも可能です。Mergeを使い、実際どのように最終製品との完全な一貫性を実現できるか体験してみてください。

ベクターベースのデザインツール　ハンドオフの限界

デザイナーから開発者に引き継がれるプロトタイプを例に考えてみましょう。それをベクターベースのデザインツールで作成したとします。つまり、すべてのコンポーネントがベクターベースでありながらも、インタラクションはコードを模倣しているだけということです。

コンポーネントの開発

まず、コンポーネントに着目してみましょう。その中には、開発者がゼロから作らなければならない新しいものもあり、既存のコンポーネントに手を加える場合もあります。

インタラクションの作成

ベクターベースのデザインツールでプロトタイプを作る場合、インタラクションがコード上に存在しないこともあり、開発者が作成するか、デザイナーと開発者のミーティングを重ねて何が必要かを正確に理解した上でデザイナーの期待に応えなければなりません。

デザインシステムの準備

デザイナーと開発者が、デザインシステムの信頼できる唯一の情報源を作るシステムです。再利用可能なマスターコンポーネントや、インタラクションがどのように機能すべきかのドキュメントを作成するのは

このデザインハンドオフは効率的か？

この方法はうまくいくが、少しイライラさせられ、時間がかかり、退屈かもしれない。誰もが壊れていることに気づき、それを直したいという衝動に駆られるわけではありません。彼らはそんなことをする必要はないのです。しかし、これは物事を動かすのに最適な方法なのでしょうか？

デザイナーと開発者の双方にとって、より良いものにするためにもっと何ができるのかという視点で見れば、議論できることはたくさんあると思います。この方法は、ベクターベースのドキュメントと開発者に渡されるものという、真実のソースがどこから来ているのかに基づく問題があります。

UXPin Mergeではデザインハンドオフはどうなるのか？

コードコンポーネントで作成したプロトタイプ

UXPin Mergeを作成する際に、開発者のハンドオフの際にもっと良いことができないか、このような視点を持ちました。

もはや、ベクターベースのコンポーネントや模倣されたコードインタラクションでデザインすることはありません。実際の設計は、生きたReactコンポーネントで行うのです。コンポーネントのコードをコピーして、アプリケーションに貼り付けることができます。

もし、デザイナーとデベロッパーが共同でドキュメントを作成し、コンポーネントのデザインとインタラクションのための唯一の真実のソースが実際のコンポーネントコードそのものであったとしたらどうだろう。つまり、デザイナーがプロトタイプを作成するとき、彼らはすでにコード化されたコンポーネントを、実際のコンポーネントが存在する本番さながらの環境で使用しているのです。

コンポーネントには、すべてのデザイントークン、インタラクション、編集可能なプロパティがすでに定義されています。最終的に、プロトタイプが出来上がると、コンポーネントのコード自体をハンドオフすることができます。

UXPin Mergeは開発者にどのように役立つのか？

デザイナーがどんなコンポーネントを使い、どんなインタラクションをデザインしたのか、想像したり打ち合わせたりする必要がなくなれば、どれだけ時間が短縮されるか想像してみてください。

開発者のハンドオフはシンプルで、プロトタイプを渡され、ソースコードにすでに存在するコンポーネント、コンポーネントのプロパティとそのコード化されたインタラクションを含むJSXコードをコピー＆ペーストするだけです。

これは、真実の源がコードそのもの、つまりソースコードであるために可能なのです。

デザイナーが編集できるコンポーネントプロパティとその編集方法は、開発者がソースコードで指定したものだけなので、予期せぬデザインが手渡されることはない。

デザイナーは、新しいインタラクションの追加、新しいプロパティの追加、スタイリングの変更などが必要な場合、開発者に説明し、ソースコードを変更することができます。推測や無駄なミーティングに時間を費やすことはもうありません。

デザイナーへの貢献度は？

開発者にとってはありがたい話ですが、デザイナーにとっては、限られたプロパティのコンポーネントを与えられてデザインすることは、創造性を制限することになると感じることが多いのではないでしょうか？私はそうは思いませんので、説明しましょう。

昔、友達と、あるいは今は一人で、レゴでクールな宇宙船やお城をデザインして遊んだことを想像してください。レゴは何歳になってもカッコイイのです。みんな同じようにあらかじめ積み木が与えられていて、その積み木がどうつながっていて、どう使うかはすでに決まっているのに、一人ひとりが他の人とはまったく違う、すばらしい宇宙船を作ることができるのです。

積み木を作ることと、その使い方を考えることに創造性を集中させるのではなく、純粋に後者に集中するのです。まずレゴブロックを作り、それがどのように機能するかを考え、それから宇宙船を作ると想像してみてください。

そんなことはあり得ないのに、それが現在のプロトタイプ設計の常識なのです。

デザイナーが最初にベクターコンポーネントを両方作らなければならないのは分かりますが、開発者はもっと大変なんです。一方、コードベースのコンポーネントであれば、双方が一度だけ作ればいいので、みんなハッピーなんです。

デザイナーは、開発者と調整会議をし続ける代わりに、他の超クールなタスクに時間を割くことができます。

Mergeを使用した開発者ハンドオフのプロトタイプ

UXPin Mergeでのハンドオフ

先ほどのプロトタイプでは、デザイナーが作成したMergeHeaderコンポーネントのJSXコードをReactアプリケーションにコピーするところから始め、開発者のハンドオフを正確に行う方法を説明します。

ソースコードそのものが真実なので、コピー＆ペーストするだけで、オブジェクトへのデータ追加やコンポーネントのインポートなど、いくつかの調整を行えば、ブラウザでアプリを表示する準備ができます。

あとは、プロトタイプの残りの部分と同じようにすれば、VOILÀ! デザイナーが作成したものと全く同じ、数分で完全に動作する本番用 React アプリが完成します。

では、結局のところ、どちらのデザインプロセスが優れていると思いますか？

UXPin Mergeでデザインハンドオフを改善する

UXPin Mergeは、ハンドオフプロセスだけでなく、多くのことを改善するのに役立ちます。統合プロセスを開始するためにもMerge ページに飛び、コードでデザインすることの利点をご覧いただけますと幸いです。ドキュメントで、Merge のデザインシステムコンポーネントをMergeについての詳細をご覧ください。

The post デザインハンドオフ ーUXPin Mergeで実現することー appeared first on Studio by UXPin.

コンテンツは、多くのクリエイターから提供された複数のタッチポイントにわたって存在しており、 UXコンテンツ 戦略は、製品のUX（ユーザーエクスペリエンス）を向上させビジネスゴールを達成するのに、コンテンツ制作とガバナンスを確実に高品質で一貫性のあるものにします。

本記事では、コンテンツ戦略を策定・維持する上で重要な以下の２つの要素を探ります：

• コンテンツのライフサイクル
• コンテンツ戦略における４つの要素

コンテンツ戦略チームは、このような要素を用いて、製品のコンテンツを作成および維持するためのフレームワークを作成します。

UXPinのMerge テクノロジーで、デザインを拡張し、製品のデザインと開発における連携を向上しませんか。プロトタイプのコンテンツを簡単にレビューし、デザインのイテレーションのスピードを上げ、デザインと開発の間で「信頼できる唯一の情報源（Single source of truth）」を共有しましょう。詳しくは、Merge のページをぜひご覧ください。

 UX コンテンツ戦略とは 

 UXコンテンツ 戦略は、製品のコンテンツ目標、作成、管理、および複数のタッチポイントにおける分配を確定します。以下が挙げられますが、他にも色々あります：

• デジタル製品のUI（ユーザーインターフェース）
• ウェブサイト
• ブログ記事
• メール（システム通知、マーケティングなど）
• モバイル通知
• SNS
• 広告

 コンテンツ戦略 担当は、このようなタッチポイントで一貫性のあるメッセージを作成してユーザーのニーズを満たし、ビジネス目標を達成することを目的としています。

UX戦略のように、 UXコンテンツ 戦略は、コンテンツデザイナーとUXデザイナーが、より良い UX のために製品とブランドを調和させるためのフレームワークを提供します。

 UXコンテンツ 戦略担当は、組織のコンテンツを統一するだけでなく、コンテンツデザイナーや UXライターと密接に連携し、ユーザーのニーズを的確に満たすコンテンツをデザインします。例えば、UXPinのドキュメントでは、デザイナーのデザインツールとその機能に対する理解を促すために、説明文、テキストハイライト、画像、説明ビデオ/GIFが使われています。

 UXコンテンツ 戦略の責任者

誰が組織における  UXコンテンツ 戦略の責任を担うかは、組織の構造によって違ってきます。例えば、多くのスタートアップ企業には、コンテンツデザイン専門のチームがなく、このような小規模な会社では、UXデザイナーがコンテンツの責任を担います。

大きな組織では、専任の コンテンツ戦略 担当がいる場合もありますが、多くの場合、コンテンツデザイナーがこの役割を担っています。

 コンテンツ戦略 担当の仕事

ここでは、典型的な コンテンツ戦略 担当の役割と責任についてご説明します：

• コンテンツの原則：言語、文章構造、読解レベルなど、組織がどのようにコピーを使用するかの確定
• コンテンツポリシー：GDPR（一般データ保護規則）、CCPA（カリフォルニア州消費者プライバシー法）などの法的要件を含む、組織のコンテンツ標準とガイドライン
• ボイス＆トーン：ブランドの個性とターゲットユーザーへの語りかけ方
• コンテンツロードマップ：コンテンツの優先順位付け、タスクの割り当てなど、コンテンツの作成と維持に必要な情報の提供
• コンテンツ監査：関連性と最新性を保証するための、各タッチポイントのコンテンツの定期的な監査

コンテンツ制作者

 コンテンツ戦略 担当は、複数のソースからコンテンツを調達するために、部門横断的な作業を行います。さまざまな種類のコンテンツを作成する担当者の例を以下に挙げましょう：

• コピーライター（ブログなどの長文コンテンツ）
• UXライター（ UI のコピー、メッセージ、通知、ラベルなど）
• グラフィックデザイナー（アイコン、インフォグラフィック、地図、その他ビジュアル要素）
• UIデザイナー（UI の要素やコンポーネント）
• ビデオエディター（ビデオコンテンツのソーシングと編集）

コンテンツライフサイクルの５ステップ

Meta（旧Facebook）のコンテンツデザイナーであるエリン・スキーム氏が２００９年に作成したコンテンツライフサイクルは、Usability.gov で参照されたフレームワークで、 コンテンツ戦略 担当に今日でも使用されています。

エリンの「コンテンツライフサイクルの５ステップ」は、 コンテンツ戦略 担当が組織のコンテンツニーズを定期的に評価する反復プロセスになります。

監査

コンテンツ監査には、UX監査のように、ブランドの既存のコンテンツとビジネス目標をきちんと評価するためのインタビューや調査が含まれ、コンテンツデザイナーは、単独の製品、プロジェクト、ドメイン、または組織を監査することができます。一般的なコンテンツ監査の内容は以下のとおりです：

• ステークホルダーインタビュー：主要なステークホルダーや各部門のコンテンツ目標の把握
• 競合分析：チャンスを見極めるための競合他社のリサーチ
• 市場調査：需要の分析およびギャップの発見
• カタログコンテンツ：既存の全コンテンツのリスト化およびカテゴリー化
• ユーザーリサーチ：ユーザーニーズを確定すべく、ユーザーペルソナ、ユーザージャーニー、製品データ（分析、ヒートマップなど）、その他のUXリサーチの評価

コンテンツ監査は、組織の現状の把握、問題や機会の特定、そしてそれがコンテンツ、UX、製品ロードマップとどのように整合しているかを確認することを主な目的としています。

戦略

戦略ステップでは、以下のようなハイレベルなコンテンツのニーズと優先順位を確定します：

• コンテンツのソーシング、プロダクション、ワークフロー
• コンテンツ配信のタイムラインと納期の設定
• コンテンツの分類法（カテゴリー、構造、メタデータなど）
• 音声とトーンの確定

プラン

戦略フェーズでは、組織が何のコンテンツを必要としているかを概説し、プランでは、誰が、いつ、どのようにそれを作成するのかを指定します。以下がその例です：

• コンテンツの調達と作成のためのタスクの割り当て
• コンテンツ管理システムのカスタマイズ
• メタデータの計画
• 移行計画
• マーケティング/広告モデル

作成

チームは企画・戦略に沿って、以下のようにコンテンツを制作します：

• ガバナンスモデルの構築
• コピーライティング、編集、レビュー
• アセット作成と最適化
• ブランディングとSEO（検索エンジン最適化）のための品質保証

維持

実行可能なコンテンツロードマップがあれば、コンテンツデザインチームは KPI （重要業績評価指標）を使って進捗をモニタリングします。また、次の監査も計画し、このプロセスを繰り返していきます。このようにコンテンツのライフサイクルを繰り返すことで、確実にコンテンツが適切であり続け、ユーザーに貢献し、ビジネス目標に合致しているようになるのです。

 コンテンツ戦略 の４つの要素

コンテンツデザインのパイオニアであるクリスティナ・ハルヴォーソン氏が設立したコンテンツ戦略コンサルティングのリーディングカンパニーであるBrain Traffic は、「Content Strategy Quad」を開発し、同社が２０１８年にブログ記事で発表しました。

「The Content Strategy Quad」は、４つの要素を２つのパートに分けて使います：

パート１ – コンテンツデザイン：コンテンツや UXデザイン戦略を通じて、ユーザーの問題を解決する。

• 編集戦略
• エクスペリエンスデザイン

パート２ – システムデザイン：システム、アーキテクチャ、インターフェース、コンテンツデザイナーが取り組むべき技術的制約など

• 構造エンジニアリング
• プロセスデザイン

編集戦略

編集戦略では、ビジュアルコンテンツと、原則、音声、トーン、ブランド、文法などを含むコピーのガイドラインに焦点が当てられ、製品にデザインシステムが採用されている場合は、コンテンツチームがそのガイドラインを文書で定めます。

良例として、Stack Overflow 社の、社内の Stacks デザインシステムにおける「コンテンツ・ガイドライン」があります。

スタイルガイドやデザインシステムで明確な編集戦略を打ち出すことで、クリエイターがブランド価値やユーザーニーズに沿った一貫性のあるコンテンツを提供できるようになるのです。

Brain Traffic によると、編集戦略は以下をどうするかについての答えを出します：

• 編集方針
• ターゲットオーディエンス
• 視点
• 声やトーン
• 準拠すべきブランドと言語基準

エクスペリエンスデザイン

エクスペリエンスデザインは、製品の UX とコンテンツとの関連性を分析し、コンテンツデザイナーは、解決すべき問題を理解すべく、製品のさまざまな対象者、カスタマージャーニーマップ、ユーザーニーズの評価をしないといけません。

Brain Traffic のエクスペリエンスデザインは、以下をどうするかについての答えを出すことを目的としています：

• ユーザーのニーズや嗜好
• コンテンツのエコシステム
• カスタマー・ジャーニー
• 必要なコンテンツ・フォーマット
• ウェブ、モバイル、タブレットなど、さまざまなプラットフォームにおけるコンテンツのデザインパターン

構造エンジニアリング（コンテンツエンジニアリング）

構造エンジニアリングは、製品の情報アーキテクチャ、各インターフェースのレイアウト／構造、ユーザーのコンテンツへの関わり方などを検討するものです。

Brain Traffic のコンテンツエンジニアリング班 は、以下をどうするかについての答えを出すことを目的としています：

• 「探して見つける」コンテンツの構成法
• ユーザーにとって最も直感的なタグ
• 効率的な管理のためのコンテンツ分類法
• 将来的な再利用のために、コンテンツの組み立て方
• 個別化、ダイナミックデリバリー、情報アーキテクチャの要件

プロセスデザイン

プロセスデザインは、「コンテンツライフサイクルのワークフローはどうするか」や「 UXコンテンツ 戦略の各側面について誰が責任を持つか」など、コンテンツガバナンス（作成、レビュー、編集、承認）に重点を置いています。

Brain Traffic のプロセスデザインでは、以下の点に重点を置いています：

• コンテンツのライフサイクルの進み方
• コンテンツの作成、配信、維持に使うツール
• コンテンツに義務と責任を追う人、また、その過程で、相談や情報を提供する必要がある人
• コンテンツの品質やパフォーマンスを測定するために用いる基準や指標
• 既存のコンテンツを管理する時期と方法
• 拒否できる人

UXPin Mergeでプロトタイプ、テスト、イテレーションを行う

コンテンツデザインのプロセスは、通常の UX デザインのワークフローと何ら変わりはなく、コンテンツデザイナーは、ユーザーのニーズを満たすコンテンツソリューションを見つけるために、プロトタイプ、テスト、およびイテレーションを行う必要があります。

従来のデザインツールでは、デザイナーは美しい UI を構築できますが、正確なプロトタイプやテストを行うための忠実度や機能は提供されていません。コンテンツデザイナーやUXライターの多くには、このようなツールを使いこなすスキルがなく、プロトタイプの能力が制限されてしまいます。

UXPin Merge があれば、コンテンツデザイナーは、コンポーネント、パターン、テンプレートなどの製品のデザインシステムをUXPinのデザインエディタと同期させて、最終製品のような外観と感触のプロトタイプを作成することができます。

このような既製コンポーネントは、コンテンツデザイナーがゼロからデザインすることを心配する必要がないということであり、それによって UI 要素をドラッグ ＆ドロップして完全にインタラクティブなプロトタイプを作成し、エンド ユーザーでテストすることに重点を置けるようになります。

TeamPassword は、非デザイナーが UXPin Merge を活用して製品のユーザーエクスペリエンスをテストできることを示す素晴らしい事例です。TeamPassword には UX 部門がないため、デザイン ツールの経験がないエンジニアが UXPin Merge を使ってプロトタイプを作成し、テストしています。

例えば完全に機能する動的なフォームフィールドでの、ユーザーエンゲージメントに基づくエラーメッセージのテストの実施が可能になるように、ユーザーは最終製品を使うような感じで Merge プロトタイプを操作することができ、コンテンツ デザイナーはテストとイテレーションのための正確なデータを得ることができます。

世界最先端のプロトタイピングツールで、テスト中に正確なフィードバックを得て、ユーザーニーズを解決する有意義なコンテンツを作成しませんか。詳細とアクセスリクエスト方法については、Merge ページをぜひご覧ください。　

The post UX コンテンツ戦略 【作成方法や４つのポイント】 appeared first on Studio by UXPin.

デジタル製品をゼロから開発するには、多くのリソースが必要ですが、 マルチブランド デザインシステムで 、一旦構築したものを複製し、カスタマイズすることができ、それによって何千時間ものデザイン・開発時間の削減が実現します。

このような デザインシステム の一元化は、組織が異なるブランド間でコストを共有し、新製品を市場に投入するためのフレームワークをより早く提供することができるということになります。

革新的なMergeテクノロジーを使ってコンポーネントライブラリをUXPinのデザインエディタと同期させ、デザインおよび開発全体にわたる『信頼できる唯一の情報源（Single source of truth）』を作成しませんか。Mergeのページで詳細とアクセス権のリクエストについてぜひご覧ください。

マルチブランドと１つ（単体）ブランドでの デザインシステム の違い

一言で言えば、「柔軟性」です。マルチブランド・デザインシステムは柔軟性に最適化されており、製品チームは既存のコンポーネントライブラリを活用して別のブランド向けの製品を開発することができます。

それに対し、企業は、柔軟性を制限する原則や制約を中心に、モノブランドのデザインシステムを構築しています。このような制限を設けることで、デザイナーは高い品質と一貫性でプロジェクトを確実に遂行することができます。

デザイントークンによる変化の促進

大抵のマルチブランド・デザインシステムでは、トークンのプロパティを変更するだけで、色、タイポグラフィー、 コーナー半径、スペーシングなど、ブランド要件に応じたグローバルなスタイル変更を簡単に行えるようにデザイントークンが使われています。

このように、マルチブランド・デザインシステムは、変更を簡単にするために構築された、テーマ性のあるオープンソースのコンポーネントライブラリと多くの類似点があり、基本的に、適応可能なコードベース、デザイン言語、ブランドガイドラインを備えたテンプレートまたはツールキットです。

以下より事例紹介をしていきます。

例1: Forge – Harry’s

デザイントークンの使用は、マルチブランド・デザインシステムの１つの側面であり、組織は、コンポーネントライブラリをカスタマイズできるようにしなければいけません。パーソナルケアブランドのHarry’sは、ブラッド・フロスト氏のアトミックデザイン（またはレイヤー化）のアプローチを用いて、マルチブランド・コンポーネントライブラリである Forge を構築しました。

Forgeには以下の２つの層が使われています：

ベース層（またはサブコンポーネント）：”これ以上分解できない柔軟な基本コンポーネント“。製品チームは、おそらくデザイントークンを通して、このような基本コンポーネントのスタイリング プロパティのみを変更する。

複雑層（「第二のレイヤー」）：”具体的かつ意見に基づいた方法で配置した複数のベースコンポーネント“

Harry’sでは、コンポーネントを「層」で構成することで、製品チームがブランドに依存しない層を維持しながら、ブランド固有の層を入れ替えてユーザー・インターフェースをカスタマイズできるようなマルチブランドのコンポーネント・ライブラリを構築しました。

また、Forgeの層によるコンポーネント構造は、各ブランドがレゴブロックのようにサブコンポーネントを使って新製品のデザインシステムを構築することができるため、柔軟性に富んでいます。

「Forgeを使えば、ブランドはサブコンポーネントを自由に組み合わせて、コンポーネントライブラリに変更を加えることなく、ユーザーに合わせたソリューションを作ることができます。」− Harry’s シニアソフトウェアエンジニア、メイ・カポッツィ氏

Forgeのデザインシステムガバナンスには、プロダクトマネージャーが新しいパターンを推進するための選択肢が以下のように４つあります：

• 既存のオプションA：カスタムコンポーネントの構築
• 既存のオプション B：既存のコードベースからコンポーネントの再利用の試み
• 新しいオプション C： Forge のベース コンポーネントからの「新しい」コンポーネントの組み立て
• 新規オプション D： 既存の Forge コンポーネントの使用

例2: フォルクスワーゲン「GroupUI・エンタープライズ」

フォルクスワーゲンの『GroupUI』は、約１５以上のブランドに対応するマルチブランド・デザインシステムです。２０２２年にInto Design Systemsとのウェビナーを収録した時点では、VW、Skoda、Audi、Porche、Man、Scania、RIOなど、Volkswagen系ブランドの一部しか GroupUI を採用していませんでした。

テク系企業とは異なり、フォルクスワーゲンには物理的な（タンジブル）製品とデジタル製品など、多くのデザイン層があります。

「たとえば、車載 HMI、Web アプリケーション、アプリ、および一部の内部 VR/AR アプリケーションの調和などの、1 つのブランド内でのタッチポイントの【縦の調和】、それから技術の【横の調和】という２つのことを両立させなければいけません。」- フォルクスワーゲンAG、ユーザーエクスペリエンスリードグループIT、トーステン・ヤンコフスキー氏。

フォルクスワーゲンは、各ブランドの中に複数のタッチポイントレイヤーを以下のように設けています：

• Web 技術
• ネイティブアプリケーション
• AR・VRのドライバーシステム
• 車載 UI

GroupUIは Web 技術 にフォーカスしていますが、あらゆるタッチポイントで一貫したUX を実現すべく、各ブランドのバーチカルとの可能な限りの連携が必要です。

例えば、顧客がブランドのWebサイトから車両を購入する場合、UXとUI は、ウェブサイトからメールマーケティング、車載用ユーザーインターフェースまで一貫してないといけません。

GroupUIのマルチブランドにおけるデザインシステムの原則

あらゆる業種やタッチポイントで一貫したブランド体験を維持しながら、このような柔軟性とカスタマイズ性を実現するために、GroupUI は次のような一連の「包括的原則」を開発しました。

GroupUIの「 ” 〜よりも—– ” の包括的原則」で、共通の目標に向かって交錯する以下の３本柱を通して、グループ導くことができます：

• 柔軟性
• 連携
• 透明性

硬直性より柔軟性：GroupUIはフレームワークにとらわれません。つまり、ブランドはその目的や目標に最も適したReact、Angular、Vueなどのフレームワークを採用することができます。その実現には、GroupUIのコアコンポーネントライブラリは、Webコンポーネントを使い、トークンベースで、Snowflakeを促進します。

ステークホルダー重視よりもグローバルな連携： GroupUIは、単一のブランドやステークホルダーよりもグループのニーズを優先させることで、「共通の目標としての継続的な進化」を目指しており、このジェネリック戦略が信頼を高めています。GroupUIのチームは、ブランド別ではなくジェネリックの導入を促進するために、普及と配布に継続的に取り組んでいます。

複雑なドキュメントよりも透明性：GroupUIでは、課題やデザインソリューションに一元化したバックログが使われます。この一元化により、ブランドが共に学び、進化するためのエコシステムが促進されるとともに、各ブランド内の縦割り、グループ全体の横割りのサイロが解消されます。

マルチブランドデザインシステムと「通常」のデザインシステム

GroupUI はフォルクスワーゲンの内部調査を利用して、マルチブランドと通常のデザインシステムを比較し、”マルチブランド・デザインシステムはコストを共有し、真の共同開発を実現する “ということがわかりました。

マルチブランドと通常のデザインシステムを比較したところ、４つの主要なメトリクスで以下のような驚くべき結果が得られました：

• ２５％安くて速いUI のデザイン作業
• 開発の効率と効果の３０%上昇
• 将来の管理コストの３０%削減
• 市場投入までの時間が３〜４倍短縮

マルチブランドデザインシステム構築のための３つのヒント

少ないツールで採用を促進

デザインツールを最小限にすることが、マルチブランド・デザインシステム構築の第一歩です！ツールが増えるということは、デザインシステム・チームが複数のプラットフォームを維持しないといけないということになりますからね。

News UK が The Times、The Sun、Virgin Radio、The Sunday Timesなどのマルチブランドのデザインシステムを構築した際、デザインシステム部門責任者のニック・ドーマン氏は、複数のツールの使用は “バラバラなソリューション “になることに気づきました。DS チームは各プラットフォームの変更を体系的に更新および検証する必要があったため、単純な変更の実装には数日または数週間かかりました。

News UKは画像ベースのデザインツールを選択し、デザインの統一を図りましたが、それでも以下の２つのデザインシステムの維持が必要でした：

• デザイン用 – 画像ベースのUIキット
• 開発用 – コンポーネントライブラリ

UXPin Mergeは、マルチブランド・デザインシステムに対応した、はるかに優れたデザインツールソリューションであり、レポジトリにホストされているコンポーネントライブラリをUXPinのデザインエディタに同期させ、デザイナーとエンジニアが同じUI要素を使用できるようにします。レポジトリが更新されると自動的にUXPinに同期され、デザインチームに変更が通知されるため、デザインおよび開発全体で『信頼できる唯一の情報源（Single source of truth）が作成されるのです。

フレームワークを問わないデザインシステム

フォルクスワーゲンから学んだように、フレームワークにとらわれないデザインシステムで、ブランドはそのニーズに最も適した技術スタックを使うことができます。GroupUIは、フォルクスワーゲンのブランドで使われている３つのフレームワークである【Web Components/HTML】、【Angular】、【React】をサポートしており、ブランドは、ガイドラインやドキュメントを含む一元化されたStorybookを通じて、このコンポーネントのプレビューができます。

Forgeと同様、GroupUIのデザインシステムは、チームがニーズに合わせてコンポーネントを構築できるように「層」で構成されており、各コンポーネントやネストされたコンポーネントのプロパティは、ブランドのテーマによって確定されます。

デザイナーは、UXPin Mergeによってフレームワークに依存しないデザインシステムの恩恵を受けることもできます。MergeのStorybook統合により、デザインチームはStorybookと互換性のあるフレームワークをUXPinのデザインエディターと同期することができ、UIキットの作成が不要になります。

デザインハンドオフの際には、エンジニアがフレームワークのパッケージをインストールして適切なテーマを適用し、UXPinがレンダリングしたコンポーネントの変更をコピーして、フロントエンドの開発を完了させます。

マルチブランド デザインシステムの将来性

アトミックデザインの方法論の採用は、マルチブランド・デザインシステムの将来にわたる維持にはとてもいい戦略であり、フォルクスワーゲン、Harry’s、NewsUKは、アトミックデザインの原則を適用して、柔軟でテーマ性のあるデザインシステムを構築しました。

このアイデアは、決して変更されないコアコンポーネントやビルディングブロックのベース層の作成であり、エンジニアは、そのコアコンポーネントをテーマ別のマスターコンポーネントの中にネストし、デザイントークンを使ってブランド

このフォルクスワーゲンの例では、タブパターンが２つ示されています。１つはポルシェ用で、もう１つはフォルクスワーゲン用です。タブのパターンとネストされたコンポーネントが同じであることに注目してください：各ブランドで変わるのはテーマのプロパティのみですね。

このアトミックの手法でコンポーネントやパターンを構築すると、マルチブランド・デザインシステムを拡張しやすくなる一方、各ブランドに個別のデザインシステム拡張のためのフレームワークを提供します。

UXPin Mergeでマルチブランドのためのデザインシステムを構築しよう

マルチブランド・デザインシステムは、デザインシステムチームが考慮しなければならないことがたくさんある、複雑な物であり、デザインシステムチームは、ワークフローを簡素化し、ツールを減らし、時間のかかる作業を最小限にする方法を見つけなないといけません。

News UKで見たように、複数のツールを使うと、複数のプラットフォームの更新・維持が、デザインシステムチームへの大きな負担となります。

UXPin Mergeは、デザイン、プロトタイプ、テストのための単一のソリューションをデザイナーに提供することで、このデザインツールの課題を解決します。プラグインや拡張機能は不要で、デザインチームに必要なものはすべて内蔵されています。

Mergeには、デザインと開発を同期させ、従来の画像ベースのデザインツールでは実現不可能だった、すべてのブランドにおける『信頼できる唯一の情報源（Single source of truth）』を作成するというさらなる利点もあります。

UXPinの【パターン】を使うと、デザインチームは、マルチブランド・デザインシステムからビルディングブロックを組み合わせて、コンポーネントライブラリの新しいパターンを進めることができます。UXPin の【パターン】は、コンポーネントバリアントの複数保存にも便利なので、デザイナーはプロトタイプ中に要素をドラッグ＆ドロップして正しいソリューションをすばやく見つけることができ、時間の節約になります！

マルチブランドを1つのコンポーネントで統合し、デザインと開発を同期させましょう。詳しくはMergeのページをぜひご覧ください。

The post マルチブランド （複数のブランド）を持つ場合の デザインシステム の始め方 appeared first on Studio by UXPin.