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.

多くのプログラミング言語では、ウェブサイト、ソフトウェア、その他のデジタル製品の構築、拡張のためにパッケージが使われ、こういったパッケージにより、エンジニアは追加のコードを書いたり維持したりすることなく、プロジェクトの機能を拡張できます。

もしあなたの会社で Node.js が使われていたら、エンジニアが NPM、Node.js パッケージ、またはパッケージマネージャについて話しているのを聞いたことがあるかもしれません。本記事では、パッケージがどのように機能し、なぜエンジニアがそれを使用するのかについての基本理解のために、デザイナーの視点でこれらの用語について説明します。

UXPin Mergeは、デザイナーが完全に機能するコードコンポーネントでUIデザインができる画期的なツールを提供しています。UXPin Mergeのトライアルはこちらより。

NPM(Node Package Manager)とは

NPM（Node Package Manager）は、エンジニアがアプリケーションやWebサイトの開発に使うツールのオープンソースレポジトリです。

NPMは2種類あります：

1. オープンソースプロジェクトを公開するためのレポジトリ。簡略版：デジタル記録及び検索機能
2. レポジトリとインタラクトするためのCLI（コマンドラインインターフェース）。簡略版：ストレージ機能と通信するためのツール

パッケージマネージャ とは？

NPMを説明する前に、パッケージマネージャの基本を理解しておきましょう。パッケージマネージャはデベロッパーのためのツールキットだと考えてください。

例えば、支払いにStripeを使用するアプリケーションを構築するとします。パッケージマネージャは、あなたの製品がStripeと通信して支払い処理をするのに必要なコードをすべてインストールします。

エンジニアは、コードを書いたりStripeのドキュメントからのコピー＆ペーストの代わりに、コマンドの入力だけで、パッケージマネージャがStripeから必要なコードの依存関係をインストールします。

検索機能、API、決済、認証ツール、地図、アイコン、ホスティングなど、アプリケーション開発のためにに思いつくあらゆる機能を備えたパッケージが何百万と存在します。

NPMなどの、誰でもパッケージをアップロードしてインストールできるオープンソースのレポジトリと、アクセスが制限されたプライベートなパッケージレポジトリがあります。

コマンドラインインターフェースとは？

CLI（コマンドラインインターフェース）とは、デベロッパーがコンピュータープログラムの操作に使うテキストインターフェースのことです。このCLIを使用すると、コマンドを実行して、ソフトウェア開発に必要なバックグラウンド操作を実行できます。

NPMの場合、例えば、エンジニアはnpm installのようなコマンドにパッケージ名を続けて指定したパッケージをインストールすることができるように、CLIによってパッケージレジストリの対話ができます。

NPMレジストリ

NPMのウェブサイトは、エンジニアがパッケージについて検索したり学んだりする場所ですが、このウェブサイトは単なるレジストリであり、パッケージをホストしているわけではありません。代わりに、エンジニアはGitHub、Packagecloud、AWS CodeArtifactなどのプラットフォームを使って、パッケージをホストし配布しています。

例えば、NPM上のUXPin Merge CLIを見ると、レポジトリと関連リンクとしてGitHubが表示されています。その上に、UXPin Merge CLIとその依存関係を【 npm i @uxpin/merge-cli】とインストールするコマンドがあります。 NPM の後の “i” は “install” の省略形なので、【npm install @uxpin/merge-cli 】と入力しても、同じ結果になります。

依存関係とは？

パッケージは、エンジニアが【依存関係】と呼ぶ他のパッケージで構成されています。ちょっとわかりにくいですよね。この「依存関係」とは、プロジェクト内で異なるタスクを実行するコードのパッケージのことです。

例えば、UXPin Merge CLI は Typescript を使用しており、Typescript は UXPin Merge CLI が必要とする 41 の依存関係のうちの 1 つに過ぎませんが、依存関係として typescript パッケージが必要です。

開発依存とは？

UXPin Merge CLI の依存関係を見ると、41の依存関係と41の開発依存 (devDependenciesとも呼ばれる) があります。

• 依存関係：あるソフトウェア実行（本番）に必要なパッケージ
• 開発依存：開発段階で必要なパッケージのみ

依存関係と開発依存はnode_modulesという別のフォルダに存在するので、packages.jsonファイルとプロジェクトのコードはそれらがどこにあるのかがわかります。

package.jsonファイルとは？

そのメタデータと依存関係を提供する package.json ファイルがあります。コンピュータにプロジェクトをインストールするとき、NPM は 、依存関係と 開発依存 をインストールするのにpackage.json ファイルを参照します。

それぞれの依存関係を個別にインストールする代わりに、コマンドラインでnpm installと入力するだけです。

ホスティングプロバイダーもpackage.jsonファイルを使用して、そのサーバー上でプロジェクトの実行に必要な依存関係（開発依存を除く）をインストールします。

package-lock.jsonとは？

package-lock.jsonは、プロジェクトのビルドに使用されたパッケージの正確なバージョンを特定します。このファイルによって依存関係がロックされ、プロジェクトがインストールされるときに、最新のリリースではなく、開発中に使用されたバージョンが参照されるようになります。

エンジニアは定期的にパッケージを更新しますが、多くの場合、パッケージの動作方法が変更されます。それにより、依存関係のロックによって、プロジェクトが意図したとおりに確実に動作するようになります。

NPMの使用方法

ここでは、一般的なNPMのコマンドとその機能について説明します。

• npm init：プロジェクト用のpackage.jsonファイルが作成されます。アプリケーションを一から構築する場合、npm initはプロジェクトの重要な情報を含めるために使用する最初のコマンドの1つになり、NPMは、パッケージをインストールまたは削除するたびに、package.jsonファイルを自動更新します。
• npminstall：プロジェクトの依存関係をすべてpackage.json ファイルにインストールします。
• npminstall <package-name>：たとえば、npminstall @uxpin/merge-cli とすると、Merge CLI がインストールされるように、 NPMレジストリから特定のパッケージをインストールし、node_modules フォルダに保存します。
• npminstall <package-name> –save：NPMパッケージをインストールし、package.jsonファイルの依存関係に追加します。
• npminstall <package-name> –save-dev：NPMパッケージをインストールし、開発依存に追加します。
• npmuninstall <package-name>：プロジェクトから特定のパッケージをアンインストールします。
• npmdoctor：npmのインストールを診断し、パッケージの管理に必要なものがすべて揃っているかどうかを確認します
• npmupdate <package-name>：特定のパッケージを最新バージョンに更新します。

これらは、最も一般的なNPMコマンドのほんの一部であり、すべてのリストはNPMのドキュメントでご覧になれます。

デザイナーとしてのNPMの理解

NPMは、デザインツールのプラグインやアプリの拡張機能に匹敵する、ツールキットです。パッケージがどのように作られるのか、その裏側を知る必要はありませんが、一つや二つ知っておくと便利かもしれません。

まず、MUIやAnt Designなど、コードコンポーネントライブラリの一部は、NPMパッケージとして共有されています。

NPMパッケージとして配布されているコンポーネントライブラリはどのように探すのでしょうか。UXPinが公開しているデザインシステムのライブラリAdeleから、UXPinに取り込めるコンポーネントライブラリを探したとします。そこでShopifyのPolarisを選び、それがNPMで配布されていることがわかります。 そこで、NPMのサイトに行って、ShopifyのPolarisを探し、見つけるのです。

UXPinはMerge技術により、NPMパッケージを介してコンポーネントライブラリからUI要素をインポートすることができ、それらの要素を使って、完全に機能するプロトタイプを組み立てることができます。

UXPin Mergeは通常、デベロッパーによってセットアップされますが、開発サポートが不足している場合はMerge Component Managerを使って、コンポーネントを自分で管理することができます。

もし、デベロッパーとの連携を強化するためにプログラミングの知識を高めたいのであれば、HTML、CSS、Javascriptなどの基本的なコードの原則やコンポーネントライブラリについて学ぶ方が、デザイナーにとってはるかに有益だと思います。

UXPin Mergeで連携の強化

Mergeは、デザイナーとエンジニアが同じコンポーネントライブラリを使用することで、デザインと開発の連携を促します。

Mergeは、デザイナー用のUIキットとデベロッパー用のコードを用意する代わりに、レポジトリをUXPinのエディタに同期させ、デザインチームがコードコンポーネントを使用して完全に機能するプロトタイプを構築できるようにしています。

自社デザインシステムやMUIなどのコンポーネントライブラリを同期させることで、デザイナーはUI要素をドラッグ＆ドロップするだけでインターフェースやプロトタイプの構築ができます。UXPin Mergeをトライアルしてみたい方はこちらまで。

The post NPMと言うのは？把握しよう！ 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.

どんなデザインチームでも、自分たちが何を目指しているかの正確な把握は必要です。そうしないと、仕事やプロジェクトにおける重要な目的や目標が簡単に見失われてしまうかもしれません。

 デザインチームの目標は、チームが正しいタスクの完了に向けてきちんと順調に進み、チーム全体の生産性と集中力を高めるには素晴らしい方法ですが、目標を正しく設定するのが難しい場合があります。

UXPinでは、どのようなデザインチームであっても、その能力が最大限に発揮されるようにすべきであると考えています。そこで、本記事では、デザインチームの目標について、その一部始終や設定方法をみていきます。コンポーネント駆動型のプロトタイプをお試しになり、チームに透明性、作業のしやすさ、理解力をもたらしませんか。UXPin Merge にアクセスし、デザイン チームと開発チームの間のサイロを今すぐ解消しましょう。Merge を詳しく見る

 デザインチーム の目標とは

デザインチームの目標は、デザイナーが一定時間内に達成すべきマイルストーン（​​中間目標、もしくは節目の地点）として設定されます。

『 デザインチーム の目標』は具体的ではなく、かなり広範囲に及ぶことがあります。「 デザインチーム の目標」は【大きな目標】と【小さなタスク】の両方で頻繁に使われ、それが混乱を招く可能性があります。なのでその代わりに、目標設定とマイルストーンの達成には、『OKR（Objectives and Key Results：目標と主な結果）』が有効であるというのが共通認識になります。

OKRは、多くのハイテクブランドやNielsen Norman Groupなどの組織で、目標の作成、進捗の評価・追跡、組織内の成果への報奨に利用されています。

OKRの構造は、以下のように明確でシンプルであり、コミュニケーションと理解のしやすさを考慮したわかりやすい構成になっています。

• 目的（Objective）：成功のために解決、改善、達成する必要のあるもの
• 主な結果（Key Results/KR）：問題が解決されたことを示すのに追跡される、測定可能な指標と結果

OKR は、目標に向かってチームを団結させ、ステークホルダーがチームが何を達成したいのかを理解するのに非常に優れているため、よく使われます。

このような仕組みがあれば、製品チームは目標に向かってより効率的かつ生産的に仕事ができるようになります。達成すべき具体的な目標があれば、それに向かって前進し、確実に軌道にとどまれるのです。

デザインチームの目標は、連携の強化や、プロセスの洗練、チームの団結のために設定され、OKRは、目的を達成し、確かな成果を得るための最適なアプローチです。

ここでは、この方法論を用いて、連携をサポートし、デザインプロセスを最適化し、チーム内の帰属意識を高めるために、デザインチームの目標をどのように設定すればよいかをご紹介します。

 デザイン チームのメンバーへの目標設定が重要な理由

• 具体的な目標を作ることで、チームのモチベーションを上げる：達成可能な目標を与えることで、自分の仕事に意義があると感じられるので、質の高い仕事をするモチベーションにつながります。そうでないと、仕事が散漫になり、何のプラスにもなっていないように感じられるかもしれません。
• 生産性と連携の質の向上：デザインチームに明確な目標を与えることで、目標達成に向けた集中力が高まり、そうすることで、生産性と仕事の質は上がり、チームの連携はより良い結果を生み出します。
• デザイナーの仕事が確実に会社の目的をサポートするようにする：スタートアップや企業組織の成功に向けて、チームが確実に動いているようにすることは重要です。OKRは、確実にチームがこの方向に向かってポジティブに働いているようにするための最適な方法です。

デザイン チームの目標６例

１．ユーザージャーニーの改善

以下の例は、Nielsen Normanのアンナ・ケイリー氏の、顧客や購入希望者の体験の向上に努める場合のOKRの例からヒントを得たものです。様々な指標での測定ができますが、この例では、リピート購入、コンバージョン率、ジャーニーパスの離脱率などの指標を使います。

目的：時間と労力節約のためのユーザージャーニーの改善

• KR（Key Result）1： リピート購入２５％増
• KR ２: コンバージョン率２０%増
• KR ３: ユーザージャーニーパスの離脱率３０%減

２．デザイン と開発の連携改善

この例の目標は３ヶ月間設定され、連携とワークフローがベースになっています。KRは、連携をより効率的かつシンプルにし、時間を短縮することを基本としています。

目的：より多くの時間節約のための、デザインと開発間のワークフローの改善

• KR １: 開発側で再開されたデザインタスクのチケットの４０%から１０%への削減
• KR ２: 「小さな改善」の平均解決時間の １０ 日から ３ 日への短縮
• KR ３: 実行に移されるデザイン依頼の ５０% から ８０% への増加

３．チームの成長を支える新しい デザインプロセス の導入

次の例は、Lattice です。デザインチームが２年間で６名から３９名に拡大したことをきっかけに、目標設定の方法を見直すことにしたそうです。

Lattice のスタッフ製品デザイナーは、「その年の振り返り」を毎年を実施することで、次年度の主な目標３つを設定できました。それぞれの目標が設定され、それぞれのチームがその年の各四半期に１つずつ、計４つのKR を出すのに働きました。次の例は、その目標のうち１つです。

目的：チームの成長に合わせたプロセスの進化

• Q１：ブランドと製品の慣習的行為をモニタリグし、調整を提案
• Q２：デザインのフィードバックとコンテキストの共有の、より頻繁な実施（２倍です！）
• Q３： より簡単なコンテキスト共有のためのテンプレートの作成
• Q４： ブランドおよび製品デザインの連携のプロセスの確定

４．ランディングページのパフォーマンス向上

GTMHubは、「アウトプット（自分の中にある知識や経験、情報を基に生み出された成果物）をアウトカム（主体的な行動によって生み出された結果や成果）に変える」ことに基づいて以下の例を共有し、これは特にランディングページのパフォーマンスを向上させることに重点を置いています。このように目標を設定することで、到達すべき一定の割合や数値が得られ、チームのパフォーマンスを把握しやすくなり、必要な時に後押しすることができるようになります。

ここでは、デザイン部門の特定のチームまたはサブセットが、この特定のタスクでの役割を果たすために OKR を割り当てられています。その OKR の例は以下の通りです：

目的：ランディングページの UX/UI によるパフォーマンスの向上

• KR １： CTAコンバージョンを２倍の１６%に
• KR ２：ページナビゲーション率を５%にアップ
• KR ３： 商品画像ギャラリーの開封率を２倍の２４%にアップ

５．デザイン 言語の一貫性

ここでは、Delivery Hero-Talabatのアンバー・ジャビーン氏が、Delivery Heroのチームにとってデザイン言語が大変だったことを話しています。デザイン言語が非常にわかりにくく、一貫性がないため、チームは生産性と効率性の維持が難しいと感じていました。そこで、チームはデザイン言語の改善に取り組みました。

以下のビデオでは、そのプロセスが詳しく説明されており、誰でも何でも同じページにたどり着けるように、デザイン言語の一貫性の改善に時間をかけることの利点が見られます。

６．プロジェクトのインテークの舵取り

この例では、Amazon/AlexaのシニアUXデザイナーであるオムカール・チャンドガドカール 氏が、これまで受け身だったデザインプロジェクトの取り込みから、会社運営への影響をよりコントロールできるようにすることを目指したことについて語っています。目標を用いてアプローチを変えることで、何とか移行でき、目標と達成に集中することができたのです。

このプロセスは、「戦術的なアプローチ」から「戦略的なアプローチ」へと移行することであり、チームがデザイン業務に関してよりイニシアチブを発揮するための素晴らしい目標です。確かに、それで彼らのデザインスキルが影響され、個人的な成長にもつながることでしょう。

このビデオでは、その全工程が紹介されています。

デザイン チームの目標到達ためのサポート

明確な目標と目的の設定だけでなく、率先して手を差し伸べ、チームをサポートすることが大切であり、それには、適切なツールへのアクセスの許可や保証が含まれます。特に、チーム全体の連携を支援し、仕事を加速させながら、生産性を向上に貢献できるツールですね。

UXPin Mergeでデザインチームの潜在能力が引き出され、それによって、最大の目標達成を目指してより協調的かつ効率的に作業することができます。Mergeを使えば、デザイナーはインタラクティブなコンポーネントをUXPinに取り込み、重複作業をせずに迅速かつスマートに作業を進めることができるのです。

連携はどのチームにとっても重要であり、Merge はチームと明確かつ迅速な連携に最適です。一貫性を保てることで、すべてが順調に進み、システムやコンポーネントの適用や実装方法について混乱が生じることがなくなります。

Mergeは、チームを強化する素晴らしい方法です。チームにより多くの透明性、可視性、理解をもたらすことで、より良いデザイン文化や、より良い製品デザイン・開発チームの連携を生み出すことができます。

UXPin Mergeでチームの生産性を上げよう

デザイン チームの目標で、チーム内の集中力とモチベーションの確立ができます。また、OKR を使うと、デザインの改良や最終製品の効果の改善高がしやすくなり、さらに、明確な目標を作成することで、チームが前向きな成果に向かって努力し、DesignOpsの重要な課題を克服できるようになります。

ただし、UI やUX のデザインチームと製品開発チームの間に繋がりがない場合は特に、緊密なコミュニケーションとチームの協力なしには、OKRの効果的な達成はできません。

そこで、UXPinの出番です。UXPinのプロトタイピングツールでは、デベロッパーが使うのと同じコンポーネントを使ってデザインすることができ、それによって、制限されたチームのサイロを解消することができます。UXPin Mergeを使えば、製品のHi-Fiプロトタイプをその場で作成し、作成中の製品の実際のUX（ユーザーエクスペリエンス）がわかります。

UXPin Merge をお試しになり、チームの連携を強化する方法をぜひご覧ください。

The post デザインチームの目標と達成するためのヒント【事例付き】 appeared first on Studio by UXPin.

CD（継続的発見）という言葉を聞いたことがある人は、プロダクトマネージャーの仕事を連想する可能性が高いかもしれません。このアジャイルなアプローチによるリサーチとプロジェクトの改良は、製品担当者の仕事だけに限ったことではありません。デザインチームが製品を形作り、価値を創造する際にも重要な役割を果たすのです。

CDは、顧客の声から製品を発見・適合させる手法であり、それによってデザインと開発の両チームが、ユーザーにとって価値のある結果を追い求めることができます。

このようなフィードバックが得られたら、それを使って製品の改善ができるかをチェックする時です。UXPinは、最も正確なフィードバックを保証するインタラクティブなプロトタイプの作成をしやすくする、連携型のエンドツーエンドデザインツールです。UXPinのトライアルに登録し、早速プロトタイプ第１号をデザインしましょう。UXPinの無料お試しでぜひご体験ください。

CD（継続的発見）とは

従来の製品リリースは、【発見】と【開発・納品】という２つのメインプロセスを経て行われます。【発見】の段階では、製品チームは顧客のニーズやペインポイントに基づいて、何を作るかを決定します。つまり、ユーザーのニーズを発見し、その問題に対する解決策を開発するということです。  

しかし、時間が経つにつれて、顧客のニーズや問題は急速に変化していく可能性があるため、従来の製品開発では、既存のソリューションをイテレーションするための機会やスペースがありません。

そこで CD（継続的発見）では、製品担当者と製品デザインチームが、UX（ユーザーエクスペリエンス）とビジネス成果の理解や改善のために、継続的なユーザー調査とイテレーションが行われます。

CDが製品開発プロセス全体に「発見段階」を統合し、日々の製品決定が確実にユーザー調査や検証によって導き出されるようにするのです。

その中で、変化に応じて即座に対応できるように、インサイトは継続的に発見されます。それには新しい要求、問題、ユーザーの習慣の変化などが含まれ、その結果、顧客にとって常に適切で有用な製品の提供が実現します。

CD が UX デザインにもたらす利点

  CD は、UXデザインチームをいい製品づくりに導いてくれます。

以下がその仕組みです

ユーザーのニーズの変化に合わせて、デザイナーが作業の優先順位を決められる

  多くのスタートアップ企業は、ユーザーにとって関係のないソリューションや機能にフォーカスしてしまうスコープクリープ（プロジェクトの要件が増加すること）に悩まされています。つまり、ユーザーのニーズが頻繁に変化する場合、そのニーズに基づいた優先順位付けは難しいのです。

それなら、ユーザーに最新の問題やペインポイントを教えてもらってはどうでしょうか。顧客の声や調査をデザインに反映させることで、顧客のニーズに合った作業や機能の優先順位を決めるといいでしょう。

最近のデータは、意思決定プロセスを導いて優先順位付けを改善し、チームの時間とリソースを大幅に節約することができますし、ユーザーからのフィードバックに基づいて、製品バックログに優先順位をつけることもできます。

真にユーザー中心である製品づくり

  顧客の声を定期的に取り入れることで、ユーザーが製品に何を求めているかがわかってきますが、ユーザーの苦痛や期待を定期的に把握していないと、顧客価値のない製品を生み出す危険性があります。

それは特に、UXデザイナーが製品の外観にとらわれ、ユーザーがどのように製品を使いたいかということにあまり目を向けてないようなデザインチームで起こります。

その結果、ユーザーの目的とはかけ離れた製品になってしまい、ユーザーはその製品を使い続けるだけの価値を見いだせなくなってしまうのです。

興味深い新ソリューションや新機能の公開

また、最初の「発見段階」で特定されたであろう新しいソリューションやペインポイントを提示することによって、CD でユーザー中心の製品が作りやすくなります。

デザインチームの製品理解は、顧客のそれとは異なることが多く、データやフィードバックを活用することで、顧客のニーズを解決する興味深い方法を明らかにすることができます。時には、ユーザーが製品の機能に対して、製品担当者とはまったく異なるイメージを持っていることを発見するところまでいくかもしれません。

また、その過程で、今まで考えもしなかったような機能やアプローチが発見され、それによってより創造的で弾力的な製品が生まれるかもしれません。

市場と競争の機会を明らかにする

ユーザーからのフィードバックを集めることで、競合他社が提供する可能性のある新製品とのギャップを発見できる可能性があります。

ユーザーが製品に求めるものを常に把握することで、混戦模様の市場に身を置き、新たな成長機会を見出すことができるのです。

例えば、ある業界のユーザーが、自社の製品にワークフローを改善する新機能を望んでいることが顧客インタビューで明らかになった場合、このペインポイントに焦点を当てることで、自社の製品を新たなターゲット分野にまで広げることができるかもしれません。まさにディスカバリーワークの威力ですね。

トレンドの把握

継続的な調査で、ユーザーの行動や製品との関わり方におけるパターンや変化を特定することができます。トレンドの把握は、自社の製品がコアユーザーにとって適切であり続けるための重要なステップです。

では、このような行動の変化はどこから来るのでしょうか？どのようにしてそれを特定できるのでしょうか？

• 「不足している機能を求めているユーザーがいる」ということは、「顧客の好みやニーズが変化している可能性がある」と考えられる。
• UX デザインの正統派が変わることで、ユーザーの期待値が変わる場合がある。例えば、他のアプリやサービスのインタラクティブな体験に慣れているユーザーは、当製品にもそれを求めるものである。

  このような顧客の声を製品ロードマップに反映させるために、UX デザインチームは、こういった変化やトレンドが「ユーザー」と「ビジネス」の両方の目的にどのような影響を与えるかの検証が必要です。

CD の実践

  UXデザインチームは、どのように CD に取り組むべきでしょうか。以下にご紹介します：

顧客の声を着実に反映させる

  ユーザーと製品との関わり方について実用的なインサイトを得るには、包括的なユーザーフィードバックが必要です。つまり、ユーザーレビューをデザインプロセスに取り入れることで、もっといい製品が作られるのです。

ディスカバリーコール（見込み客への初めての営業連絡）や顧客アンケートに参加してもらうことは、非常に重要です。顧客とのタッチポイントを計画することで、顧客の目標をどのように妨げているのか、あるいは可能にしているのかがわかります。

製品開発チームのメンバーが自分のインサイトに自信を持ち、効果的な CD を実施するには、代表的なサンプルサイズが必要です。

ユーザーによって、使い勝手の問題やユーザーニーズが違うので、様々な背景、分野、立地条件から、多種多様な顧客にアプローチしましょう。

醍醐味ですか？有益な顧客フィードバックは、自発的な手段からだけ得られるものではありません。営業やカスタマーサポートのような顧客対応チームは、毎日、感動した顧客と失望した顧客の両方から有益なインサイトを得られるのです。

率直で根拠のあるフィードバックを得るために、このようなチームと協力してコンタクトするユーザーのリストを集めましょう。

製品発見プロセスにおける役割の合意

  製品開発チームには、多くの場合、以下の３部門が関わります：

• デザイナー
• デベロッパー
• プロダクトマネージャー

  メンバーはそれぞれ、ディスカバリープロセスへのアプローチ方法について異なる視点を持っていると思われるので、この３部門のリーダーには、顧客と接することをお勧めします。そうすることで、ユーザーの状況を正確に把握することができるでしょう。

その結果、ユーザーからのフィードバックについて話し合う際に、全チームの視点が考慮され、非効率なサイロ化が回避されます。そして、そのリーダー達は、次のステップを共同で検討し、ソリューションの検討の際には、必要に応じてそれぞれのチームのメンバーを加えることもあります。

達成したい成果を明確に意識する

  スコープクリープを回避するために、CD は、達成したい「成果」と「ビジネス目標」に集中し続ける必要があります。

そこで、チームの目標を明確にすることが非常に重要になってきますが、筆者たちは、チームが「メトリクス」と「目標」に集中する「OKR（目標と主な成果）」という方法論を用いることをお勧めします。

このプロセスによって、チームは意図する目標を明確にし、実際のデータによる進捗状況の把握ができます。

デザインチームは、どのようにすれば、ソリューションが望ましい結果に合致していることを確認できるのでしょうか。デザイン上の決定がビジネス価値を生み出したかどうかを測る方法の概要である KPI（主要業績評価指標）というのがあります。

OKR を意識して製品開発に取り組むことで、ユーザーとのディスカッションで得られたフィードバックが、チームレベルの目標達成や重要なビジネス目標の達成に不可欠なものかどうかを判断することができるようになります。

OKR の方法論がどのようにあなたのチームを導くことができるかを探りたいですか？チーム目標をデザインするための完全ガイドをぜひお読みください。

CD を実現しやすくするプロトタイピングツールを使う

  ユーザーからのフィードバックに基づいて製品を効果的に適応させる秘訣は、ディスカバリー内の異なる部門が共同で製品のイテレーションを行うことができる「プロトタイピングツール」の使用です。

プロトタイプは製品開発の重要なステップであり、開発チームやプロダクトマネージャーなどがこのステップに関わることで、ライフサイクルの後半に潜む問題を解決することができます。  

だからこそ、チームが協力して作業できるプロトタイピングツールを使うことが重要なのです。

UXPin はコンポーネント駆動型のプロトタイピングツールで、実際の製品のように動作するプロトタイプを作成することができます。クラウド上で製品を作成したら、主要なチームメンバーをループさせてコメントや修正を依頼します。

このツールで、製品チームは UI の一貫性の維持、デザインハンドオフの迅速化、デザインのあらゆる判断へのユーザーの声の反映が実現できます。またデザイナーは、インタラクティブなプロトタイプを作成し、製品の UX をうまく示すことができます。

UXPin は、連携と情報の流れを促進することで、CD をプロセスの一部として取り入れるチームをサポートします。

UXPin による CD を通じて、ユーザー中心の製品プロトタイプを作成しよう

  CD によって、デザイン上の決定すべてが、UX の向上と顧客のペインポイントに対するソリューションの提供に焦点を当てたものとなり、特に、変化し続けるデジタルの世界においては、ターゲットユーザーにとって適切で有益なデジタル製品を提供し続けることができます。  

消費者の好みや期待の変化に対応するために、このような機敏で適応力のあるアプローチでの製品開発をお勧めします。

連携型のプロトタイプは、このステップの重要な部分であり、それによって製品発見部門のチームは、顧客フィードバックに対応するUXの形づけや、作り上げることができます。そこで、UXPin の出番です。UXPin のオールインワンのプロトタイピングツールによってデザインと開発のギャップを埋めることができ、チーム一丸となってユーザー中心の製品作りを行うことができます。UXPinを始める。

The post CD （継続的発見）ってなに？UXデザインにもたらすメリット appeared first on Studio by UXPin.

UXデザイナーがデザイン以外のチームやステークホルダーに、ユーザー中心のソリューションとUXの重要性について教育しようとするにつれて、デザイン提唱は過去10年間で人気が高まっています。

デザインの提唱者には、UXデザイナーから実体験を持つ最高幹部まで、さまざまな形態があり、組織全体にリプルを広げてユーザー中心の価値観へと思考を転換させることが目標としています。

UXPinのコードベースデザインで製品のUXを向上させませんか？最終製品を正確に再現する忠実度の高いプロトタイプを作成し、ユーザビリティテストやステークホルダーからの有意義なフィードバックを得ることができます。ぜひ無料トライアルにごサインアップしてUXPinがあなたのUXデザインプロセスにどのような革命をもたらすかご覧ください。

UXデザイン提唱者とは

デザイン提唱者とは、デザインの関心、ユーザー中心のデザインアイデア、デザイン思考を促しながら、UX（ユーザーエクスペリエンス）についてデザイン以外のチームやステークホルダーを教育し、連携することに専念するUX専門家のことです。

デザイン提唱者は通常、デザインチーム、ステークホルダー、および他の部門とデザイン関連事項での共同作用における内輪向きの役割になります。

• デザインチームでは、主に組織のデザインバリューを浸透させ、企業文化の構築のために活動する
• ステークホルダーや非デザイナーに対して、デザインの価値を示し、連携の機会を探っている

場合によっては、デザイン提唱者は、オンラインフォーラムやライブイベントを通じてエンドユーザーと外部でつながることもあり、彼らが社内で働くか社外で働くかは、製品や組織によって異なります。

提唱と説得の違い

提唱とは、デザインの利益のために立ち上がってテーブルにつくことであり、一方、説得とは、自分のように考えたり行動するよう人々を説得しようとすることです。

デザイン提唱者とは、人々にデザインの実践を強制することではなく、仕事の中にデザイン思考や原則を取り入れることです。目標は、デザイン以外のチームメンバーやステークホルダーに立ち止まってもらい、”この決定は「我々の利益」と「顧客」のためになるか？”と考えてもらうことです。

UX デザイン提唱 が重要な理由

多くのステークホルダーや非デザインチームはUXを理解しておらず、UXは見た目の美しさだけを追求するものだと考えています。これは些細なことに思えるかもしれませんが、デザインプロジェクトに悪影響を及ぼし、”デザインの失敗 “と認識される結果になりかねないのです。

例えば、ステークホルダーがデザイナーにビジネス上の利益のためにコンテンツとCTA（Call To Action）を優先するように指示するアプリを構築しているとします。ところが、ユーザー調査やテストの結果は、顧客は違うコンテンツや機能を優先すると出ています。

直感的に操作できなかったり、必要なものを見つけるのにメニューやサブメニューに移動しなければならず、その結果、単純な作業なのに必要以上に時間がかかってしまうようになり、ユーザーは製品に不満を感じるようになります。そうなると、以下のようなことが結果として起こる可能性があるのです：

• 顧客が製品を使わなくなり、競合他社に乗り換える
• 顧客問い合わせの増加
• コンバージョン数および売上高の減少
• 否定的なレビューがブランドの評判に傷をつける

このような問題は組織に悪影響を及ぼし、ステークホルダーはUXを責め立てます。本当の問題は、ユーザーリサーチやユーザー中心のデザインよりも、ビジネスの目標や前提を優先させることだったのです。

ステークホルダーは必ずしも悪くないのですが、UXに対する基本的な理解が欠けています。そこでデザイン提唱者の出番です。

デザイン提唱 の例

今回は、PayPalとGMの2つの企業組織におけるデザイン提唱の事例を紹介します。

PayPalにおけるUXの提唱

PayPalのUX Lead EPXであるエリカ・ライダー氏は、デザインバリュー会議2020の講演で、いかにUXの原則を製品やエンジニアリングチームに提唱し、UXだけでなく全員がユーザー体験に責任を負うようにしているかを語っています。

彼女は、製品開発プロセスにおける制御と責任の大きな不均衡を以下のように実感しました：

• UXデザイナーは、ユーザーに提供されたUXについて担うコントロールは0なのに責任は100％を負う
• エンジニアは、ユーザーに提供されたUXに対して負う責任は0なのに、コントロールは100％担う。

エリカは、責任を負うべきは提供するチームであると信じており、エンジニアがUXを理解できるように教育し、専用のウィザードでその成功を測定することに取り組んでいます。

デザインとUXの原則を提唱することで、彼女はユーザーへの製品提供を改善すべく、エンジニアリング担当者との中間点を見出したのです。

エリカのアプローチについては、デザインバリュー会議での30分間の講演「DesignOps 2.0 – Scaling Design」をご覧ください。

デザイン提唱 が有効であることの証明 – GMの場合

Miro Distributed 2020にて、GMのUX Researcher & Design Strategistであるジェラ・マーフィー氏が、自動車産業の大企業においてデザインとUXを提唱するための戦略について話しています。

彼女は、デザイン思考ワークショップと共有された経験を使用して、ユーザーとそのフラストレーションについてステークホルダーを教育します。 彼女の最大の成功は、GMのグローバルイノベーションディレクターであり、製品へのアプローチに欠陥があることに気づいたターニャ・スキルトン氏との出会いでした。

「当初は、問題やそれを解決するための製品について、ビジネスにフォーカスしたハイレベルな議論をすれば、製品をデザインし創造するのに十分な情報が得られると思い込んでいたのですが、それは大きな間違いでした。我ながら何という大間違い！

ジェラさんと一緒にUXに焦点を当てた研究をすることで、問題やニーズについて純粋に学ぶための質問と、そのユーザーや問題についての私の先入観を強化するための質問とでは、どのように違うのかがわかりました。」

まず、新しいアイデアを受け入れるターニャと、GMのデザインに対する考え方を形成する素晴らしい仕事をしたジェラに脱帽です。ジェラの30分の講演は、こちらでご覧いただけます。

このGMの例で、前述した「ステークホルダーが必ずしも悪いわけではなく、単にUXの基礎的な理解が欠けているだけ」という言葉に説得力が増します。

デザインの提唱 に一番いい方法

ここでは、パートナーシップから、デザイン活動へのステークホルダーの参加、さらには新しいデザイン手法の導入まで、組織全体でデザインを提唱する方法をいくつかご紹介します。

1. 部門を超えた連携

連携は、デザイン提唱を成功させる鍵の1つです。デザイン提唱者は、各部門と協力して、情報やユーザーリサーチの価値を共有する方法を見つけなければなりません。

ここでは、デザインチームが他の人と協力して、組織の他の部分に価値を提供する方法をいくつかご紹介します：

• セールスチームとマーケティングチームが情報を共有することには、大きなの価値があり、どちらのチームもユーザーの行動を見ますが、それぞれ違うレンズ越しに見ています。
• セールスやマーケティングは、リサーチをサポートするのに貴重なデータを持っていることが多く、UXはキャンペーンの最適化のために既存のユーザー調査を提供することができます。
• ​​ユーザーリサーチで、ビジネスチームが新しいユーザーや市場の機会を特定しやすくなります。デザイン提唱者は、この貴重な情報を共有することで、製品と市場の適合性を向上させ、ユーザーと組織のためになるビジネス上の意思決定におけるUXの影響力を高めることができるのです
• データサイエンティストは、ユーザーの行動、UXが解決できる問題、それに応じた優先順位の付け方について、貴重な見解を持っており、UXの提唱者は、アナリストが顧客の行動をより明確に把握し、理解するためのもう一つのデータポイントとして、ユーザーリサーチデータを共有することができます。

デザインの提唱者となり、組織内での部門の価値を高めるには、このような連携の機会を見つけることは不可欠な部分です。

2. ワークショップ

デザイン思考のワークショップは、デザインプロセスやデザイン思考による問題解決の方法について、デザイン部門じゃないチームやステークホルダーを教育するのにとてもいいです。デザインワークショップは、ジェラ・マーフィー氏がGMで魔法をかけた方法の1つです。その結果を見たらワークショップという方法のすばらしさが分かるでしょう！

3. ユーザーインタビューへ招く

ユーザーインタビューでは、ユーザビリティ・テストのプロセスや、UXデザイナーがどのようにユーザーの問題に対するソリューションを開発し、機会を特定するかをステークホルダーに見てもらうことができます。

また、ユーザーインタビューは、ユーザビリティの問題やデザインの悪いUIでユーザーがどのように苦労しているかをステークホルダーが見る絶好の機会であり、今後の意思決定に共感をもたらします。

4. デザインスプリントに招く

デザインスプリントでは、ステークホルダーとデザイン部門でないチームのメンバーが、1週間以内にエンドツーエンドのデザインプロセスを直接体験することができ、そこでデザイン思考やプロセスを学び、自分たちのソリューションに対するユーザーの反応を見ることができます。

5. ストーリーテリング

GMのジェラ・マーフィー氏は、ユーザーストーリーやUXの成功例を伝えるために、ストーリーテリングをよく利用しますが、UXの成果物を共有することは、こういったストーリーをステークホルダーに提示するにはベストな方法ではないことに、彼女は長い間わかっていました。デザイナーにとっては意味のあるものですが、ステークホルダーにとっては十分なビジュアルではないのです。

彼女は、ユーザーとビジネスゴールの接点を示すビジュアルを多用し、聞き手にとって適切なUXストーリーを語る方法を探しています。

ユーザーやUXのストーリーを語るときは、聴衆のことを考え、適切な言葉やビジュアルを使ってメッセージを伝えましょう。

6. DesignOpsでの提唱

DesignOpsは、デザイン提唱を推進するための一般的な手段であり、DesignOpsの専門家は、デザインの中で効率化を図り、組織の他の部分への影響を測定します。

彼らは、デザインの価値を高めるのに、以下のようないくつかの取り組みを行っています（これらの中には、デザイン提唱者の仕事と類似しているものもあります）。

• 部門を超えた情報共有の推進と促進
• 部門を超えた情報共有
• スキル開発
• デザイン理念の浸透とチーム文化の構築
• キャリア開発およびコーチング
• デザインチームの目標設定とメンタリング
• 結束と一貫性を高めるためのツールやプロセスの開発

このトピックにの詳細については、「DesignOps 101: Guide to Design Operations」と題した電子ブックをご覧ください。

UXPin – ユーザーのための究極のデザイン提唱者

ユーザーテストは、デザインプロセスの重要な部分ですが、プロトタイプが製品体験を再現できなければ、正確な結果を得ることはできません。UXPinのコードベースのデザインツールを使えば、デザイナーはコードのような忠実性と機能性を備えたプロトタイプを作成し、より良いユーザーテストを行うことができます。

UXPinのプロトタイプは、ステークホルダーからのより良い、より有意義なフィードバックももたらします。UXPinのコードベースのプロトタイプは、何かをすることを「想像」するのではなく、高度な機能を提供し、ステークホルダーが好む没入型の体験を｢創造」します。

「例えば、このボックスはテキストフィールドに見えないといったコメントだけではなく、こういったプロトタイプの機能や目標を体験しているので、最高幹部の方々やディレクターは、最終的な方向性についてより強いフィードバックができるのです。」 PayPal社 UXリード EPX エリカ・ライダー氏

UXPinのコードベースのデザインソリューションに切り替えて、デザイン提唱者が話題にする価値と効率性をより多く生み出しましょう。無料トライアルにサインアップして、UXPinがどのように顧客のためにより良いUXを生み出すかをぜひご体験ください。

The post デザイン提唱とは？ appeared first on Studio by UXPin.