DesignOps戦略 – DesignOpsチームを成長させるには?

DesignOps Strategy How to Grow the Team

DesignOpsは、多くの組織にとって重要な運営機能となっていますが、一部の企業では、まだ専門のDesignOpsの実装者やチームがなく、ボトルネックや非効率な作業を行っているのが現状です。

2020年にNN Groupが557人のUX実装者を対象に行った調査によると、「組織は推奨されるDesignOpsの取り組みを22%しか行っておらず、DesignOps専用の役割もなく、全体的にDesignOpsの成熟度は低かった 」とのことです。

というわけで、​​本記事では、DesignOpsの成熟度の4つのステージと、チームを拡張し成長させるために各ステージで設定すべき目標についてお話します。

まだ時代遅れの画像ベースのデザインツールを使っていますか?UXPin のコードベースのデザイン革命に参加して、デザインと開発を同期させる先進の Merge テクノロジーに触れてみてください。無料トライアルにサインアップして、Merge やその他の UXPin 機能をぜひお試しください。

ステージ0:DesignOpsの責任者がいない

​​機能を超えた小規模チームが一緒に仕事をしている製品では、DesignOpsのモチベーションは低く、NNグループは 「散在型チーム構造 」と呼んでいます。

プロダクトマネージャー、デザインリード、マネージャーは様々な運営活動を担当するため、Opsの仕事はチームメンバー間で「散在」しています。AmazonのシニアUXデザイナーであるオムカール・チャンドガドカール氏は、デザインバリュー会議2022の講演で、UXチームが戦略的ではなく反応的または戦術的に動作することから、この段階を「飛行機を飛ばしながらその飛行機をデザインする」と呼びました。

これはAirbnbの初期にも言えることで、デザイナーとエンジニアで構成されるプロダクトチームが同じオフィスで密接に働き、一日を通して交流し、関わり合っていました。彼らは緊密に連携し運営上の課題を一緒に解決していく、「全員参加型」の成長戦略でした。

しかし、Airbnbの成功と成長により、チームは分離し、サイロが生まれました。これは、急成長するスタートアップ企業や企業団体によく見られる問題です。

「…物事が突然難しくなる転換点に到達しました。チームはもはや全員が同じフロアに収まることはできませんでした…情報へのアクセス、デザイン基準、ワークストリームの衝突、品質問題、すべてが非常に現実的な問題となったのです。」(エイドリアン・クリーブ氏のDesignOps at Airbnbの記事から抜粋)

この段階でAirbnbはデザイン言語システムを開発し、DesignOpsが誕生したのです。

DesignOps ステージ0の主なリソース

ステージ1:一人体制のDesignOpsチーム

DesignOpsの最初の段階は、NN Groupが 「孤高のチーム体制 」と呼んでいるものです。DesignOpsは、その役割にフルタイムで専念する1人体制のチームとなります。SiriusXMのDesignOpsディレクターであるサロメ・モルタザヴィ氏がデザインバリュー会議2022の講演で指摘しているように、「DesignOps部門の70%は1人体制のチームである 」のです。

DesignOpsチームとしてスタートするとき、サロメは、まず耳を傾け、メモを取ることから始めることを勧めています。グループや1対1の環境で、人、スペース、プロセスなどを把握しましょう。

この傾聴のアプローチにより、企業の組織的・体系的な問題をあぶり出すことができます。また、DesignOpsの実装者は、組織の問題を特定し、明確に説明できるため、チームやステークホルダーとの信頼関係を築くことができるのです。

DesignOpsのステージ1の目標は、ボトルネックと問題の特定と、それに応じた修正の優先順位付けであり、サロメは、問題やテーマの特定にデザイン成熟度インデックスを使用しています。このようなDesignOpsの中には、解決しなければならないものもあれば、デザインリーダーに委ねられるものもあります。

DesignOps ステージ1の主なリソース

DesignOpsステージ2:DPM(デザインプログラムマネージャー)の採用

実装者が多少の成功を収め、組織がDesignOpsを拡張することに価値を見出したら、自身のチーム構築が始まります。この段階で、実装者が専門分野の専任チームメンバーの必要性を認識することから、NN Groupではこの段階を「特化型」DesignOpsと定義しています。

DPM(デザインプログラムマネージャー)は、DesignOpsチーム構築の際によく最初に採用されます。このDPMは、日々のワークフローの効率化のためにチームと一緒に仕事をしたり、オンボーディングやツールのキュレーション、ライセンシングなどの特定の分野に重点を置いたりすることがあります。

DesignOpsに影響力があり問題を解決するものですが、ステージ2ではまだ戦略的というより、非常に戦術的です。DesignOpsチームは問題解決や短期的なソリューションの開発には効果を発揮しますが、ロードマップがなかったり、長期的な目標にほとんど時間をかけていなかったりします。

DesignOpsステージ2の主なリソース:

ステージ3:DesignOpsの拡張

成熟したDesignOpsチームは、NN GroupのDesignOpsチーム構造に従って、「分散型」または「高架型」の構造で運営されています。DesignOpsは、このような成熟した構造において、ロードマップ、長期目標、およびプロジェクトの軌道のモニタリングを伴う戦略的な運営に流れていきます。

内部に目を向けるプロセス指向のDesignOps専任のリーダーがいます。Measuring DesignOps Impactでは、Babylonのアソシエイトデザインオペレーションディレクターであるパトリツィア・ベルティーニ氏が、DesignOpsリーダーの役割を5つの箇条書きでまとめています:

  • 使命: その方法又はパフォーマンス
  • 焦点: エンドツーエンドのデザインプロセスとチーム
  • KPI:チームの健全性、支出、パフォーマンスのメトリクス
  • 成果物: 運営ロードマップと戦略
  • スキル: 変更管理

そして、DPMも同様に5つのポイントを使っています:

  • 使命: 運営ロードマップの実行
  • 焦点: 実行のためのプロセスの調整
  • KPI:プログラムのメトリクス
  • 成果物: 設計図、プロジェクト状況
  • スキルプロセスおよびプロジェクト管理

パトリツィア・ベルティーニ氏は、DesignOpsの介入すべき3つの領域を定めています:

  • 事業運営:予算やリソース、その他ビジネスに関わるデザイン機能の管理
  • ワークフロー及びデザイン運営:エンド・ツー・エンドのデザインプロセスの全体像。デザイナーはどのようにしてコンセプトから最終製品まで到達するのか?
  • 人材操作:スキル開発、コミュニケーション、文化など、デザインチームの人的側面の考慮

DesignOpsの測定に関するウェビナーは、UXPinのYouTubeチャンネルでご覧になれます。

成熟したDesignOps環境でのDPMの拡張

DPMは、プロジェクトの戦術的または戦略的な戦略を適用するためにフレームワークを使用しますが、DesignOps Layers of Impactでは、マギー・ディエンジャー氏が以下のように「フレーミングとスケーリング」の方法論を用いて判断しています:

  • どこに時間を費やすのがベストなのか
  • その時間でどのように確実に最大の効果を発揮するか

マギーのフレームワークは、何かをすることの「適材」を探すのではなく、3つのフレームワークを通して、DPMが最も影響を与えることができる場所を特定するものです:

  • デザインチームの規模や組織の状態は?
  • どのようなリソースと割り当ての環境で運営されているのか?
  • 主なデザインパートナーはどのレベルか?

このようなフレーム要因に対する答えが得られたら、マギーはエンゲージメントの範囲に応じて、一方はズームイン、他方はズームアウトして、影響力を高めることを考えます:

  • ズームイン:チームとの日常業務
  • ズームアウト:提唱、戦略、プランニング

マギーは、以下の5つの質問に答えることで、自分のフレーム要因と影響の度合いに基づいたサポートDPMの軌道を概説しています:

  1. どのような活動や環境が、日々自分に仕事のやりがいをもたらしてくれるのか?
  2. 自身がサポートするチームに対して、今、最もインパクトと影響力を持つ活動は何か?
  3. 自分のキャリアにとって重要なことに取り組むのに、パートナーをどのように活用すればいいのか?
  4. 望ましい行動やエンゲージメントに影響を与えるのに、どのようにチームの規模を利用できるか?
  5. 自分は戦術的な活動か戦略的な活動か、あるいはその両方が得意なのか?

彼女は以下についても考えます:

  • 今日はどこにいるか?
  • どこにいたいか?
  • チームはどこにいたいのか?

DesignOps ステージ 3 の主なリソース

UXPin MergeによるDesignOpsの拡張と成熟化

DesignOpsチームは1人であるため、時間とリソースが限られています。成熟するにつれて、ハイレベルな戦略と長期的な目標に焦点を当てたいと思うようになることから、デザインチームの成長や拡張のためのツールの確保は、どのDesignOpsチームにとっても不可欠です。

UXPin Mergeは信頼できる唯一の情報源(Single source of truth)を作成し、時間のかかる手動タスクやアクティビティを排除します。それによってDesignOpsの多くの課題が解消され、実装者やDPMは戦略的イニシアティブや価値作りに集中できる時間が得られます。

コードベースのデザインがどのようにUXワークフローの改善、デザインチームとデベロッパー間の連携の強化、エラーと再作業の削減、DesignOpsの価値提供につながるか、無料トライアルにサインアップしてぜひご体験ください。

UXエンジニア のポートフォリオ – 短編ガイドと例をご紹介

ux engineer

Springboardのオンライン学習プラットフォームでは、2022年に最も需要の高い仕事の1つとしてUXエンジニア(別名:UXユニコーン)が挙げられています。魅力的なUXエンジニアのポートフォリオを作成すれば、あなたは頭一つ出て目立てます。

というわけで本記事では、UXエンジニアのポートフォリオの作り方、共有すべき情報、そしてインスピレーションを得るための事例をご紹介します。

世界最先端のUXデザインおよびプロトタイピングツールで、デザインと開発の連携を改善し、両者間のギャップを埋めましょう。無料トライアルにサインアップして、UXPin Merge が製品開発プロセスにどのような革命をもたらすかご体験ください。

UXエンジニアとは

UXエンジニア(ユーザーエクスペリエンスエンジニア)は、UIエンジニア/デベロッパーまたはUI/UXエンジニアとも呼ばれ、UXデザイナーとデベロッパーのハイブリッド的な職種です。一般的に、デザイン思考、デザイン原則、アクセシビリティを理解するフロントエンドデベロッパーになります。

UXエンジニアは、HTML、CSS、Javascriptなどの主要なフロントエンドプログラミング言語の専門家です。デザイナーが忠実度の高いプロトタイプの作成や、フロントエンドのUI要素やインタラクティビティの開発をする際にサポートするのが彼らの仕事です。

UXエンジニアは、デザイナーやエンジニアと連携するための知識とスキルがあることから、デザインと開発の橋渡し役と思われがちです。

UXエンジニア のスキル

  • デザイン思考
  • ビジュアルデザイン
  • インタラクション
  • UIデザイン
  • ウェブデザイン
  • ウェブ開発
  • モバイルアプリ開発
  • バージョン管理
  • HCI(ヒューマンコンピュータインタラクション)
  • デザインシステム
  • デバッグとテスト
  • ナビゲーションと情報アーキテクチャ
  • レスポンシブデザインと開発
  • Hi-Fiプロトタイピング

UXエンジニア のポートフォリオが必要な理由

フリーランスとして働くにしても、正社員のポジションを探しているにしても、ポートフォリオは自分のスキルや経験をアピールする機会になります。

design and development collaboration process product

UXエンジニアは、UXとフロントエンド開発の能力があり、組織にとらわれることなくチームで働くことができることを証明するのに、ポートフォリオが必須なのです。

UXエンジニアのポートフォリオの作り方

UXエンジニアがUXポートフォリオサイトを作成する場合、選択肢がいくつかあります:

  1. WordPress、SquarespaceなどのCMS(コンテンツ管理システム)の利用
  2. HTML、CSS、Javascriptを使った静的なWebサイトの構築

CMSはメンテナンスが簡単であり、静的なWebサイトはUXエンジニアに創造性と柔軟性を与えます。また、静的なWebサイトは、デザインからフロントエンド開発まで、UXエンジニアのスキルをトータルにアピールできる機会でもあります。

UXポートフォリオサイトの構成要素

  • ホーム
  • 自己紹介
  • ポートフォリオ
  • お問い合わせ先

UXエンジニアの中にはブログを入れる人もいますが、気が散るものは少ない方がいいですよね。

designops picking tools care

ポートフォリオのウェブサイトを構築する際には、ユーザーのことを考えるのが重要です。彼らは、あなたのことを知り、あなたのポートフォリオを見たいと思っている潜在的な顧客やリクルーターですから、それに応じてコンテンツの優先順位を決めましょう。

ホーム

ホームでは、1〜2文での簡単な自己紹介、スキルセットの概要、作品へのリンク(ポートフォリオページ)を掲載しましょう。また、折り返しの上に2つのCTA(Call To Action)を設け、1つはポートフォリオに、もう1つはコンタクトページにリンクさせるとよいでしょう。

自己紹介

アバウトページでは、あなたの知識、経験、職歴を紹介しましょう。また、あなたが得意とするデザインや開発ツールのリストも掲載しましょう。

業界関連の講演や出版物の記事などについての言及やリンクがあれば、専門家としての自分をアピールでき、大きな仕事を獲得できる可能性が高まります。

ユーザーはペットの猫の写真よりも、あなたの専門的な知識を知りたがっているため、個人情報は最小限にとどめましょう。

ポートフォリオ

ポートフォリオページは、ウェブサイト上で最も重要なページです。あなたのプロジェクトでをベストなのを3~5つ紹介することをお勧めします。UXエンジニアとしての仕事を希望する場合は、デザイナーやエンジニアと共同作業したエンドツーエンドの製品開発プロセスを示すプロジェクトを含めるとよいでしょう。

各事例の構成については、下記の「The Anatomy of a UX Engineer Portfolio Case Study」をご確認ください。

お問い合わせ先

以下の項目を入力するためのシンプルなお問い合わせフォームを使いましょう:

  • 氏名
  • メールアドレス
  • 本文

関連するSNSアカウントへのリンクを忘れすに含めましょう。メールアドレスや電話番号の記載は、迷惑メールにつながる可能性があるため避けましょう。

UXエンジニア のポートフォリオ事例を解析

ここでは、UXエンジニアに関連する余分な部分を含む、UXケーススタディの解析をご紹介します。ケーススタディを読むのに時間がかかりすぎないように、文字は最小限に抑えるのがベストなアドバイスです。

task documentation data

1. イントロ

プロジェクト、クライアント/雇用主、新製品や新機能の必要性、自分の役割について3段落で説明しましょう。

2. 問題の概要

1〜3文でユーザーとプロジェクトが解決しなければならない問題を定めましょう。

3. デザインプロセス

あなたがデザインプロセスにどのように関わり、デザインチームとどのようにコラボレーションしたのか、デザイン思考を応用して問題を理解し、解決策を開発したことを含めて、3段落で説明しましょう。

また、デザインシステムを使用したかどうかや、デザインのハンドオフにおける自分の役割も記載するとよいでしょう。これらはUXエンジニアの重要な役割であり、デザインと開発の連携をどのように強化したかを示すものだからです。

ポートフォリオのこの部分で重要なUXアーティファクトは以下の通りです:

  • アイデア出しのメモとスケッチ
  • UXリサーチ
  • Hi-Fiプロトタイプのスクリーンショット

デザインチームと共同作業する際に使用したデザインツールをリストアップしましょう。

開発プロセス

ユーザーインターフェース開発におけるあなたの役割と、エンジニアとの共同作業について、1~3文で説明しましょう。その際、コードのコンパイルとテストに使用したツール、ソフトウェア、技術スタックを含めましょう。

採用担当者は、あなたが技術的な問題に対する解決策を見出す能力があることを確認したいことから、開発プロセスにおける課題と、それを克服するために何をしたかを強調することが重要です。

また、デザインファイルをどのように機能するコードに変換したか、さまざまな反復作業、課題、最終製品に到達した方法もオススメです。

プロダクトデザイナー兼UXエンジニアのアドハム・ダナウェイ氏は、2枚のスクリーンショットを並べることで、ワイヤーフレームから最終製品に至るまでを紹介しています。



UXエンジニアの重要なプラットフォーム

UXエンジニアのためのプラットフォームは、あなたの露出を増やし、最高の仕事を獲得するチャンスを増やすために、以下のものをお勧めします:

  • LinkedIn:LinkedInは、UXデザインスキルやプログラミングの理解度を証明するテストが受けられるので、UXエンジニアには最適です
  • CodePen:デベロッパーがコードを共有できるコミュニティベースのプラットフォームで、プログラミングのスキルをアピールするのに適しています。CodePensを埋め込むこともできるので、ユーザーはあなたのポートフォリオのサイトから離れる必要がありません。
  • GitHub:GitHub プロファイルへのリンクを共有することで、見込み客や雇用主があなたの貢献や個人的なプロジェクトを見ることができるようになります。

また、このようなプラットフォームへのリンクをウェブサイトに掲載し、訪問者があなたの作品をより多く探せるようにしましょう。

UXエンジニアのポートフォリオ5例

ゼニア・リン:米国のUXエンジニア

UXエンジニア

 

ゼニアのポートフォリオのホームには、彼女のスキル、仕事、経験についての紹介が含まれています。ゼニアはこのスペースで、デザインと開発の両方のスキルや、拡張現実体験の構築に対する情熱をアピールしています。

マット・ファーレイ:カナダのプロダクトデザイナー兼UXエンジニア

UXエンジニア

 

マットのポートフォリオのホームは、ミニマルなUIと明確なCTAである「Say Hello」によって、訪問者をお問い合わせページに導き、コンタクトを取ることができるようになっています。また、彼のホームページには、以下のような重要なセクションがあります。

  • デザイナー、フロントエンドデベロッパー、メンターとしてのスキル
  • 最近の仕事
  • マットが関わった企業
  • スタートアップ・プロジェクト
  • お客様の声

マットのフッターには、明確なCTAと彼のSNSリンクが含まれています。

アドハム・ダナウェイ:オーストラリアのプロダクトデザイナー兼フロントエンドデベロッパー

アドハムのホームページは、片方に【designer】、もう片方に【<coder>】と表示されたクールなヒーローアニメーションが特徴です。その下には、彼の最新の作品へのリンクがあります。アドハムのヘッダーナビゲーションは、彼の他のポートフォリオウェブサイトやSNSへのリンクが提供されています。

ヘレン・コーア:英国のUXエンジニア

ヘレンは、ホームページでさまざまなプロジェクトを紹介しており、GitHub上のプロジェクトとプロトタイプへのリンクがあります。彼女のUIはシンプルですが、人々が自身の作品を見るために最も必要な情報とリンクを載せています。

アタ・ドーガン:MetaのAR プロダクトデザイナー

Ata Dogan

アタのポートフォリオサイトでは、彼の作品、プロセス、トークが没入型ビデオで紹介されており、それは自分自身と作品を紹介するためのクリエイティブなアイデアになっています。彼の自己紹介ページには、簡単な自己紹介、講演活動、SNSへのリンクが掲載されており、ヘッダーナビゲーションには履歴書へのリンクがあります。

UXPin Mergeでギャップを埋める

UXPin Mergeは、レポジトリからUIコンポーネントライブラリをUXPinのエディタに同期させ、デザイナーがコードコンポーネントで完全に機能するプロトタイプを構築できるようにするものです。

プロトタイプを作成するためにコード コンポーネントを使用すると、UX エンジニア の UI 開発時の作業が少なくなります。Merge は、UX デザイナーと UX エンジニアが同じ言語(信頼できる唯一の情報源(Single source of truth))を話すため、デザインのハンドオフ プロセスが簡素化されます。

uxpin merge git react storybook library

レポジトリ内のコンポーネントに変更があると自動的にUXPinに同期されるため、デザインチームは最新のイテレーションでプロトタイプやテストを行うことができます。UXエンジニアは、コンポーネントのプロップ(またはStorybookとの統合によるArgs)を使用して、デザイナーがUXPinでプロパティを調整できるようにします。変更はすべてJSXでレンダリングされ、エンジニアはこれをコピー&ペーストして開発を開始できます。

PayPalデザインチームを超えたDesignOps:エンジニアと働く秘訣

PaypalのUX Lead EPXであるエリカ・ライダー氏 とPayPalは、UXPinを知らないわけではありません。彼女は長年にわたってUXPin Mergeを賞賛し、この技術がPayPalの社内製品開発プロセスにどのような革命をもたらしたかを声高に語っています。

彼女はデザインバリュー会議2022で、デジタル決済の一大企業におけるデザインをスケーリングさせるための新しいフレームワークである、PayPalのDesignOps 2.0について語っています

PayPalの新製品開発ワークフローの開発において、UXPin Mergeが重要な役割を果たしました。UXPin Merge へのアクセス権をリクエストして UXPin Merge をご体験いただき、コードベースのデザインがエンドツーエンドのデザインプロセスにどのような革命をもたらすかをご覧ください。無料トライアルにサインアップして、MUI ライブラリとの統合によるコードコンポーネントでのデザインで UXPin Merge をぜひお試しください。

従来のDesignOpsとDesignOps 2.0

UXデザイナーが自身を含めて5人しかいない状況で、エリカは従来のDesignOpsモデルがPayPalのニーズに合わないことに気づきました。DesignOpsの原則は、大規模なデザイン組織には有効ですが、5人のチームには合わないのです。

1000人以上のエンジニアを抱えるPayPalのDesignOpsは、デザインと開発を効率化されたエンドツーエンドの製品開発ワークフローに組み込まなければいけませんでした。

DesignOps 2.0には以下が求められました:

  • すべてのツールで一貫した予測可能なユーザー体験の提供
  • 製品チームが有用で使い勝手の良い製品の提供できるようにする
  • 新たなデザイナーを加えることなく、デザインを可能な限り効率よく大幅に拡張する

エリカとチームは、一般的なエンタープライズデザインソリューションをいくつか試した後、DesignOpsとDevOpsのハイブリッドフレームワークを作成する必要があることがわかりました。そこで彼女たちは、DesignOpsを作る代わりに、DevOpsの中でデザインを運用することにしたのです。

担当業務の進化

designops increasing collaboration group

エリカは、自分のビジョンを実現するための鍵の1つは、UX(ユーザーエクスペリエンス)の責任をUXから組織の他の部分に移すことだと気づきました。デザインをDevOpsに組み込むということは、プロダクトチームとエンジニアリングチームが “良いUX “を持つ製品を提供しなければならないということなのです。

製品チーム

製品チームは、以下のようなUXの責任も負わなければなりませんでした:

  • 優れたUXを備えた製品の提供
  • UXチームと連携したユーザー調査の実施
  • UXチームの指導のもとでのプロトタイプのデザイン

UXチーム

UXデザイナーは、デザイナーからビジョナリーやメンターへと進化を遂げ、部門の責務は以下のように変化していきました:

製品チームのための「自分でするUX」の実現

  • PDチームが簡単に学んで使えるデザイン・調査ツール

PDチームへの指導と助言

  • チームがチームの デザイン思考やユーザー中心のデザインをまとめる
  • プラットフォームにおける各チームの位置づけを理解させる

プラットフォームレベルでのソリューションデザイン

  • 共有できるサービスや、大抵の製品で必要とされるサービス

UXの大きな問題の解決

UXに関するエンジニアリングチームの教育

エリカは、エンジニアが考えるUXを、美観を重視したUIから、ボトルネックやロードブロックを引き起こす問題へとシフトさせる必要がありました。

彼女は、エンジニアの視点からUXを示すために、製品開発のワークフローを作成しました。

  • ビルドに失敗したが原因がわからない=エンジニアのUXがお粗末
  • API契約変更があったのを知らなかった。誰に相談すればいいのか=エンジニアのUXがお粗末

彼女はまた、製品チームやエンジニアリングチームと、UXに関する問題について以下のようにいくつか議論しました:

  • レイテンシ:ボタンをクリックしても読み込みに時間がかかるということは、お粗末なUXである
  • 可用性:URLが読み込まれないということは、お粗末なUXである
  • セキュリティ:もし誰かが私のアカウントをハッキングしたら、それは相当お粗末なUXである
  • 「人間が読める」ものではない、あるいはユーザーが解決する術のないエラーメッセージ:なぜ、その意味も解決方法も告げずに、「エラーコード1578-B1273 – 失敗しました!」というメッセージがユーザーに表示されるのか?これもまた、お粗末なUXである。

エリカはこのような例を用いて、UXがフルスタックの問題であることをエンジニアリングチームに伝えました。エンジニアリングの問題、遅延、可用性、セキュリティなど、すべてUXに影響を与えるため、UXはこれら考慮するのです。

PayPalのDesignOps 2.0プロセスを進化させる

designops efficiency person

エリカが2019年にDesignOps 2.0を発表した当初、それはデザインを拡張し、小規模なデザインチームの作業をしやすくするためのものでした。

現在、彼女とチームは、デザイナーの作業負荷を軽減するためのシステムではなく、より良い製品を提供するための製品チームのためにDesignOps 2.0の最適化を検討しています。

エリカは、ユーザー調査を運用するためのシステムに取り組んでいます。「Getting to DesignOps 2.0」のロードマップには、完了するのに重要な3つのユーザー調査のコンポーネントが以下のようにまだ残っています:

  • ユーザーへの理解
  • UXの成功度の測定
  • PDチームの説明責任

説明責任は、エリカが克服すべき最大の課題の1つであり、ほとんどの企業は、コントロールと説明責任のバランスが大きく崩れています。

  • UXデザイナーは、ユーザーに提供されたUXのコントロールは0なのに、説明責任は100%負っている。
  • エンジニアは、ユーザーに提供されたUXに対する説明責任は0なのに、コントロールは100%担っている。

優れたUXを持つ素晴らしい製品の提供には、デザイナーとエンジニアはバランスの取れたコントロールと説明責任を持たなければならないと彼女は考えています。UXチームはエンジニアと協力してPayPalの優れたUXを実現しますが、最終的な製品に対して説明責任を負うのはエンジニアなのです。

UXの成功度の測定

designops efficiency speed optimal

エリカとチームは、製品開発プロセスにおけるユーザーの行動と成功率を自動的に追跡するウィザード・ツールを開発しました。このツールによって、UXチームは問題の追跡や特定ができます。

ユーザーメトリクスの継続的かつ自動的な収集:

  • デベロッパーは特別なコーディングは不要
  • ウィザードコンポーネントのすべてのインスタンスのデータはPayPalのダッシュボードに自動的にフィードされる

完了までの時間や離脱率の追跡:

  • ワークフローを完了するまでの総時間
  • 各ステップを完了するまでの時間
  • 総ドロップオフ率
  • 最もドロップオフ率の高いステップ(ステップ固有の問題の特定に使用)

戦略的な割り込みによるリアルタイムの定性データ:

  • ユーザーが困っているときに割り込みを発生させる
  • ユーザーが条件を満たしたときのみ

ベースライン、ベンチマーク分析搭載:

  • 完了までの時間が増えているか減っているか
  • 離脱率は改善されているか

PayPalのDesignOps 2.0の詳細な説明と背景については、エリカ・ライダー氏による30分のデザインバリュー会議の講演をごぜひ覧ください。

 

エリカのチームにおけるUXPin Mergeのスケーリングされたデザイン

uxpin merge react sync library git

 

UXPin Mergeは、エリカがPayPalの新しい製品開発システムのビジョンを達成する上で極めて重要な役割を果たしました。

Mergeによって、彼女は製品チームが膨大なドキュメントやトレーニングなしに、完全に機能するプロトタイプを構築できるようになったのです。

PayPalは、63のReactプロトタイピングコンポーネントをレポジトリからUXPinのデザインエディタに同期し、製品チームとエンジニアリングチームがまったく同じUI要素を使用することで、組織全体で信頼できる唯一の情報源(Sigle source of truth)を提供します。

エンジニアと協力し、エリカはReactのコンポーネントプロップを使って制約を設定し、デザインの柔軟性を確保しました。このような制約により、PayPalの製品チームは100を超える社内製品に一貫した品質を提供することができます。

UXPin Mergeが5人のデザイナーと1,000人以上のエンジニアからなる企業組織のためにデザインをスケーリングできるとしたら、あなたにとって何ができるかを想像してみてください!

無料トライアルにサインアップして、UXPinに同期されたMUIライブラリのコンポーネントでプロトタイピングを行い、UXPin Mergeをお試しください。アクセス権をリクエストして、ぜひコードコンポーネントを使用したデザインの可能性をすべてご覧ください。

ダッシュボード のプロトタイプを作成する方法

How to prototype dashboard 1

ダッシュボード デザインは、企業向け製品を連想させることが多いですが、ダッシュボードは、SNSアプリやゲーム、そしてモバイルデバイスなど、どこにでもあり、ユーザーにわかりやすいように簡潔に視覚化された、重要な情報が表示されています。

では、ダッシュボードのデザインとプロトタイピング、そして顧客に素晴らしいダッシュボード体験を確実に提供するためのベストプラクティスを見ていきましょう。

UXPinは、ユーザビリティ参画者やステークホルダーから有意義で実用的なフィードバックを得られるような正確なダッシュボードプロトタイプを作成できる、高度なコードベースのデザインツールです。無料トライアルにサインアップして、UXPinを使ったダッシュボードのプロトタイプ作成をぜひすぐに始めてみてください!

ダッシュボードとは

ダッシュボードとは、分析、ステータス、統計、レポートなどの重要な情報の視覚化、管理タスクの完了、設定の微調整をユーザーができるようにするユーザーインターフェースのことです。

携帯電話やデスクトップで設定するユーザーインターフェースはダッシュボードです。WordPressやShopifyなどのCMS(コンテンツ管理システム)を使ったことがあったら、その管理画面のUIはダッシュボードであり、ネット銀行のユーザー・インターフェースもダッシュボードです。

ダッシュボードの種類

ダッシュボードデザインの選択は、ユーザーに提供したい機能や情報によって異なり、ダッシュボードのUIデザインには、4つのタイプがあります:

  • 分析型:可視化されたデータを表示
  • 運営型:リアルタイムまたは短期間のデータを表示
  • 戦略型:長期目標をKPIとステータスで可視化
  • 戦術型:ハイレベルなパフォーマンスのモニタリングを表示

タイプ1.分析型ダッシュボードデザイン

製品のデザイナーは、膨大な量のデータを簡素化して表示するのに、分析用ダッシュボードを使い、そのダッシュボードには、データのハイレベルな概要が単一の数値またはグラフ表現で表示されます。

分析型ダッシュボードは通常、過去のデータを参照し、ユーザーが予測や意思決定を行うための傾向を特定できるようにします。例えば、マーケティング担当者は、分析型ダッシュボードを使用して、主要な人口統計、ユーザーの場所、およびトラフィックソースを分析し、マーケティング戦略を作成します。

タイプ2.運営型ダッシュボードデザイン

運営型ダッシュボードでは、リアルタイムまたは短い時間枠のデータが表示され、ユーザーがシステムや運営をモニタリングできるようにします。運営型ダッシュボードのデータは、多くの場合、データソースの変更に伴い、定期的にリアルタイムで変更されます。

運営型ダッシュボードでは、通常、多くのユーザーの視線が最初に集中する上部付近に、運営に必要な情報を表示します。例えば、ロジスティクスマネージャーは、運営型ダッシュボードを使って、倉庫の活動をリアルタイムでモニタリングします。

タイプ3.戦略型ダッシュボードデザイン

戦略的ダッシュボードでは、長期的な目標に向けたKPIに対するパフォーマンスの追跡ができ、このダッシュボードで複雑なデータがまとめられ、ユーザーは強みと弱点の特定ができます。

戦略型ダッシュボードには通常、【目標】、【現在の状況】、【目標達成に必要な予測】が表示され、過去の期間や年度が含まれることもあります。例えば、セールスマネージャーは、戦略型ダッシュボードを使って、売上目標に対するパフォーマンスを表示し、前年、四半期、月、週、日を比較して進捗状況を確認します。

タイプ4.戦術的ダッシュボードデザイン

戦術型ダッシュボードは、戦略型と運営型ダッシュボードのハイブリッドで、ユーザーは「プロジェクトの完了」などの目的に向かって、パフォーマンスのモニタリングができます。

戦術ダッシュボードは、戦略や意思決定の指針として、全体的なパフォーマンスとセグメント化されたパフォーマンスを可視化するためのものです。例えば、プロジェクトのダッシュボードでは、全体的な進捗状況と、チームがまだ完了させなければならないタスクが表示されます。また、戦術ダッシュボードでは、プロジェクトマネージャーがフォローアップできるように、納期遅延や期限間近の問題など、潜在的な問題を指摘することもできます。

ダッシュボードのUIタイプについては、Datapineのこちらの記事で詳細と例をご覧ください。

ダッシュボード デザインの要素

UIデザイナーは、さまざまな種類のデータの表示のために、主要な要素をいくつか使用し、この写実的表現によって、ユーザーは情報の視覚化や比較が簡単にできるのです。

データテーブル

Excelシートのようなものであるデータテーブルは、チャート、ゲージ、パイ、グラフなど、他のUI要素の作成に使用できることから、ダッシュボードのデザインにおいて重要です。テーブルは通常、多くのスペースを占有するため、デザイナーは、ユーザーが可視化の背後にあるデータを分析できる二次的なページに、こういったテーブルを配置します。

棒グラフ

棒グラフは、月次売上高のように時系列のデータ比較に適しており、さまざまな高さを視覚化することで、ユーザーはさまざまなデータポイントをパッと比較することができます。

円グラフ

円グラフは、全体を構成する複数の点におけるデータの分布を視覚化するものであり、ユーザーが自分の支出を視覚化し、どこに最も多く支出したかを確認できるため、支出追跡アプリでよく見られます。

折れ線グラフ

折れ線グラフは、特定の期間におけるパフォーマンスやトレンドの追跡に最も有効であり、線によって、トレンドがどの方向に動いているのかや、1年における月単位などの色々な重要な間隔での変化を簡単に確認することができます。

ゲージ

デザイナーは、進捗状況やステータスの表示にゲージを使用することができます。進捗ゲージに数値を表示することで、ユーザーは2つのビジュアルを見ることができ、より分かりやすくなります。

また、特定のシステムをモニタリングする際にも、ゲージを用いたステータスの表示ができます。例えば、倉庫管理システムで、包装担当者の1日の目標達成に向けた現在のパフォーマンスを、【不十分】【平均以下】【許容範囲】【最適】で表示することができ、インジケータが許容範囲を下回ると、マネージャーはパフォーマンスの問題を調査し、対処することができます。

メトリクスや数字

デザイナーは、例えば現在の収益を表す数値など、主要な値の表示や、視覚化のサポートのためにメトリクスを使用できます。

メトリクスは、ユーザーが情報をより簡単に理解することや、認知的負荷の軽減といった目的において、単独の使用が最も効果的です。

ダッシュボード デザインのプロセス

The Data SchoolのeBookにある「Dashboard Prototyping and Feedback」では、ダッシュボードデザインとプロトタイピング戦略の概要を4つのステップで説明していますが、筆者たちはこれを、以下のような包括的な6ステップのエンドツーエンドのダッシュボードデザインプロセスを含めるべく、若干手を加えました:

  1. レビュー
  2. スケッチ
  3. フィードバック
  4. プロトタイプ
  5. テスト
  6. ハンドオフ

ステップ1.レビュー

最初のステップは、ダッシュボードの目標と要件を確定するために調査を見直すところであり、デザイナーは、デザインの構成と優先順位を決めるのに、ユーザーのニーズと利用可能なデータを一致させなければいけません。

ここでスケッチを開始するために必要なUIと要素のリストを作成しましょう。この要素を重要度順に並べると、ダッシュボードのUIに優先順位をつけやすくなります。

ステップ2.スケッチ

ダッシュボードのデザインは、複雑で時間のかかる作業であることから、デザイナーは、忠実度の高いモックアップやプロトタイピングに取りかかる前に、アイデアのスケッチや改良が欠かせません。

デザイナーはスケッチを使って、データをどのように表現するのが最適かを判断します。1つのUIに複数のグラフィックがある場合は、1ページにまとめる前に、それぞれを切り離してスケッチしましょう。

また、 Data SchoolのeBookでは、スケッチする際に以下の2つを考えることを推奨しています:

  • ユーザーはどのような判断が必要か
  • その判断のために、ユーザーは何を知る必要があるか

​​ダッシュボードは、他の多くのUIレイアウトよりも色々とたくさんあるので、データは最小限にとどめましょう。重要なデータがたくさんある場合は、情報を分類して2ページ以上に分けることを検討しましょう。

ステップ3.フィードバック

デザイナーがデジタルモックアップやプロトタイプを作成する前に、チームメンバーやステークホルダーからのフィードバックは欠かせません。このフィードバックで、時間のかかるデジタル処理に入る前に、デザインを改善し、問題を解決できるのです。

次のステップに進む前に、何度かイテレーションがあることを頭に入れておきましょう。

ステップ4.プロトタイプ

ペーパープロトタイプやメモを使い、ワイヤーフレームやデジタルモックアップ、プロトタイプを作成しましょう。ゼロから始める必要がないように、コンポーネントライブラリUIキットの使用をお勧めします。

UXPinには、Material Design UI、Bootstrap、Foundationなど、ダッシュボードのプロトタイプに最適なライブラリである内蔵デザインライブラリがあります。

また、Mergeを使ってデザインシステムやコンポーネントライブラリをUXPinに同期させることもできます。デザイナーは、画像ベースのデザインツールでは不可能な、完全に機能するグラフやチャートを構築できるため、Mergeテクノロジーを採用したUXPinは、ダッシュボードのプロトタイピングに最適です。

ステップ5.テスト

プロトタイピングとテストは、繰り返し行われるプロセスであり、UXデザイナーは、確実にユーザビリティの問題が最終製品に影響しないよう、プロトタイプを総合的にテストする必要があります。

ユーザーのニーズを満たしながらビジネス価値を最大化するデザインを確実に行うのに、エンドユーザーや主要なステークホルダーからのフィードバックは重要です。

ステップ6.ハンドオフ

ダッシュボードのデザインハンドオフは複雑で厄介なものです。このデザインハンドオフチェックリストに従って、プロセスを合理化し、デザイナーとエンジニア間の連携を向上させることをお勧めします。

ダッシュボードデザインのベストプラクティス

コンテンツの優先順位

調査段階で、どのデータが最も重要かをユーザーに尋ね、デザインプロセスの指針とすることが重要です。データを【ミッションクリティカル】と【セカンダリ】に分けることで、コンテンツの優先順位や配置を把握するようにしましょう。

シンプルイズベスト

ダッシュボードのレイアウトを可能な限りスッキリまとめることを常に意識しましょう。ダッシュボードのUIは色々とたくさんあるので、認知負荷とユーザビリティに深刻な影響を与えかねません。

モバイル優先のデザイン

ダッシュボードをデスクトップで美しく見せるのは簡単ですが、本当の課題は、モバイルフレンドリーなダッシュボードの作成です。モバイル優先のダッシュボードデザインの戦略を取ることで、以下の2つの問題を解決することができます:

  • モバイルユーザーからのダッシュボードへのアクセスができるようにする
  • UI要素の軽減

一貫性を保つ

どのようなUIでも一貫性は重要ですが、複雑なダッシュボードのデザインでは、一貫性は不可欠です!デザインシステムを使えば、タイポグラフィー、色、スペーシング、レイアウト、その他のUI要素をデザイン全体で一貫性を保つことができます。

余白は倍取る

デザイナーであるタラス・バクセビッチ氏は、「10 Rules for Better Dashboard Design」の中で、コンテンツを区切るのに、余白を倍取ることや空白を使うことを推奨しています。コンテンツが余白に触れたり、近すぎたりすると、読みづらいですからね。

スクロールしない!

また、彼はダッシュボードをスクロール可能にすることが最大のデザインミスの1つであると述べています。できるだけ要約し、新しい画面に移動させるか、タブを作成してユーザーがコンテンツを切り替えられるようにしましょう。

柔軟性を持つ

組織や個々のプロジェクト内でも、ユーザーのニーズや優先順位はさまざまであることから、一律のダッシュボードのレイアウトを作ることは無理です。

ユーザーが自分のニーズに合わせてダッシュボードをアレンジできる機能を提供することで、「これひとつで全部できます」という課題を解決しながら、ポジティブなユーザーエクスペリエンスを実現します。

UXPin Mergeを使ったダッシュボードのデザインとプロトタイプの作成

UXPin Mergeは、ダッシュボードのプロトタイピングとテストを正確に行うことができる唯一のデザインツールです。静的なデザインを使用する代わりに、デザイナーは最終製品のような外観と機能を持つコードコンポーネントを使用して、ダッシュボードのプロトタイプを構築することができます。

MUI ライブラリ統合から React コンポーネントを使用して、一行のコードも書くことなく Merge ダッシュボードを構築してみましょう!MUI コンポーネントをドラッグ&ドロップするだけで、完全に機能するダッシュボードやその他のユーザー インターフェイスの構築ができます。

無料トライアルにサインアップして、UXPinの高度なコードベースデザイン機能をぜひお試しください!



UXのための競合分析 – 調査方法6選

UX競合分析は、UXリサーチの重要な部分であり、これは、デザイナーが競争上の優位性を得るために、うまくいっているものを活用し、そうでないものを避け、ギャップを特定する機会でもあるのです。

UX競合分析で、デザイナーはユーザーをより深く理解することもできます。顧客の目を通して競合を見ることで、UXリサーチャーはより共感し、何が顧客をわくわくさせ、何が不満を与えるのかが見えてくるのです。

UXPinの高度なプロトタイピングおよびテストツールで、ユーザーテストからより良い結果を得ませんか?製品のユーザーエクスペリエンスを模倣した、コードのような機能を持つ忠実度の高いプロトタイプをデザインしてみましょう。無料トライアルにサインアップして、ぜひUXPinの高度な機能をすべてお試しください。

UX競合分析 とは

task documentation data

UX 競合分析 とは、UXリサーチャーが競合の理解や好機の特定、さらにエッジを見つけるのに使用する手法です。この分析により、UXデザインチームは、製品のユーザーエクスペリエンスとビジネス価値の向上のためのUX戦略開発に向けた貴重なインサイトを得ることができます。

UX競合分析は、主にデザインとインタラクションに焦点が当てられますが、リサーチャーは、ビジネスやその他の側面がユーザー体験全体にどのような影響を与えるかも検討します。

UX競合分析 が必要な理由

UX競合分析を行いたい理由はいくつかあります。例をいくつか挙げてみましょう:

  • 市場における立ち位置とシェアの把握
  • UX戦略の策定とデザインプロセスの優先順位付け
  • 競合他社が同じようなユーザビリティの問題をどのように解決しているかの特定
  • 失敗やその予防法の失敗の模索
  • 競合の強み・弱みの把握
  • トレンドとイノベーションのリサーチ
  • ユーザー調査・市場調査のサポート

UX 競合分析 の目的

UX競合分析は、他のUX調査を補完して、市場、競合他社、製品、ユーザーの全体像を把握することを目的としています。ここでは、デザイナーが 競合分析 を行うシナリオをいくつかご紹介します:

新製品や新機能の構築

UX競合分析は、発見段階の調査において重要な役割を果たし、UXチームは、この競合分析を用いて競合状況を理解し、好機を見出します。

市場ギャップの特定

UXリサーチャーは、競合分析を利用してギャップと好機を特定することができますが、このギャップは、製品のイノベーションかもしれなですし、単に価格設定の改善かもしれません。

市場のギャップを見つけることで、企業は競合他社よりも優位に立ち、製品をより魅力的なものにすることができるのです。

企業は常にギャップを探しているわけではなく、競合の革新的なアイデアを改良(または盗用)することがよくあります。例えばFacebookは競合他社をコピーすることで有名ですが、TwitterはSpacesでクラブハウスのソーシャルオーディオプラットフォームとしての君臨を終わらせました

リサーチのサポート

デザインチームは、仮説の確認やユーザー調査のサポートとしてUX競合分析を行うこともあります。

UX競合分析 を行うタイミング

search observe user centered

UXチームは、デザインプロセスの初期段階において、新規プロジェクトの開始時にUX競合分析を行います。競合状況や市場は定期的に変化するため、デザイナーは定期的に競合他社の調査を行い、常に情報を入手します。

競合他社の種類

競合は2つに分類されます:

  1. 直接の競合他社
  2. 間接の競合他社

直接の競合他社は、同じ、または重複するターゲット市場に、同じ商品やサービスを提供しています。こういった競合他社は、提供するものが非常に類似しているため、通常は価格で競争します。 例を挙げると、Instagram、TikTok、Snapchatは、同じようなターゲット市場に同じような製品を提供する直接の競合他社です。

間接的な競合他社は、同じ市場領域で事業を展開しますが、異なる製品を提供しています。異なる製品といえども、通常は同じニーズを満たすため、顧客はどれか1つを選択することになります。

例えばInstagramとLinkedInは、間接的な競合他社です。このプラットフォームは異なるニーズを満たすものですが、どちらも「ユーザーの注目」を集めるために競争しています。

直接の競争相手を理解することは、自社ブランドをより魅力的なものにするための製品や価格の改善につながりますし、間接的な競争相手は新たなチャンスを発見できる可能性があります。

例えば、多くのカップルは、ディナーと映画を楽しむために外出しますが、そこでロビーに「レストラン」がある「映画館」は、他の地域の映画館(直接の競合他社)やレストラン(間接の競合他社)と競合しています。

テック界では、製品が重複する間接的な競合他社がよく見られます。例えば、TwitterとYouTubeは間接的な競合関係にありますが、前者はユーザーをプラットフォームに留めるためにツイートに動画ホスティングを提供しています。

Twitterがビデオホスティングを提供する以前は、ユーザーはビデオコンテンツを自分のYouTubeアカウントにアップし、そのリンクをツイートで共有しなければいけませんでしたが、現在では、Twitterユーザーは動画コンテンツを共有するためにYouTubeアカウントを必要とせず、ブログ記事にTweet動画を埋め込むことができるため、結果的にYouTubeのトラフィックが減少しています。

UX競合分析 の調査法6選

ここでは、競合分析のための方法を6つご紹介します。

1. SWOT分析

SWOT分析(Strengths(強み)、Weakness(弱み)、Opportunities(好機)、Threats(脅威))は、企業が社内または競合他社に対して行う分析手法です。企業は、業界全体、市場、競合他社、製品群、または単一の製品についてSWOT分析を行うことができます。

SWOTでは、重要な4分野を評価します:

強み:競合他社が最も強いのはどこか?競合が最も競争力を発揮しにくい分野

弱み:競合他社が最も弱いのはどこか?競合が提供しないもの、あるいは苦手なものは何か?プロからのアドバイス:競合の1つ星のレビューから、この答えは通常見つかります。

好機:競合他社が現在開拓していない好機は何か?例えば、eコマースブランドがコンバージョンを増加させるためのワンクリックチェックアウトのようなシンプルな機能に好機があるかもしれません。

脅威:競合のビジネスに損害を与える可能性のあるものは何か?これは通常、例えば競争、法律、政治、技術など、外的なものになります。 Investopediaの記事に、SWOT分析を行うためのステップバイステップのガイドがあります。  

2. 競合製品の使用

競合他社を「スパイ」してデータを集める最も簡単な方法の1つは、競合他社の製品を使用することです。以下は集めるデータの例です:

  • まず、競合他社のタッチポイントは何か?ウェブサイトにアクセスしたとき、アプリをダウンロードしたとき、ブログ記事を読んだときなど、どのようなことが起こるのか?どのようにしてトラフィックをユーザーに変え、さらに有料顧客にしているのか?
  • 競合他社は、自社の製品や価格をどのように顧客に提示しているか?
  • 無料トライアルに申し込むとどうなるのか?
  • アップグレードのしやすさは?さらに言うと、解約は簡単かどうか、そのプロセスはどのようなものか?
  • レイアウト、マイクロインタラクション、色、タイポグラフィなど、UIデザイン全体の分析
  • 顧客として製品を使い、タスクをこなす。ペインポイントがあるか?競合他社の強み、弱点は何か?

共感マップで競合製品を使った感想や気持ちを記録することで、自身をユーザビリティの参画者として見てみてください。もしかしたら、不明瞭な価格体系に戸惑い、不満を感じたかもしれませんし、直感的なUIとマイクロインタラクションによって、製品を使うのが楽しくなったかもしれません。

3. 競合他社のレビューを読む

モバイルアプリストア、Facebookページ、TwitterメンションなどのSNS、マーケットプレイス、TrustPilotのようなウェブサイトからのレビューは、競合他社分析の優れたリソースです。こういったカスタマーレビューから、競合他社についての顧客の好みが見えてきます。

レビューの分析に時間をかけて、ポジティブなパターンとネガティブなパターンを見つけ、それを他のリサーチと比較します。顧客は大体、「この製品が◯◯だったらいいのに…」というようなコメントを残し、このようなレビューから、デザイナーは競合他社が満たしていないギャップの特定ができます。

4. 比較表

比較表は、同じような製品機能を提供する直接の競合他社に最適です。例えば、有料プランを競合他社と比較し、どの会社が顧客に最も価値を提供しているかの判断ができます。

EdrawMaxのこの記事では、5種類の比較表の解説と比較表の作成方法が紹されています。

5. ユーザージャーニー比較

ユーザージャーニーは、顧客がどのようにタスクを完了するかを最初から最後までマッピングします。このエンドツーエンドのプロセスを最適化することで、ユーザー体験を向上させ、コンバージョンを増加させることができます。

例えば、競合他社はより少ないステップや戦略的なCTA(Call To Action)の配置で、より多くの顧客をコンバージョンさせていることが分かるかもしれないうように、成功している競合他社と自身のユーザージャーニーを比較することで、成功の秘訣が見えてくるかもしれません。

6. 競合他社のプロトタイプを使ったユーザビリティテスト

競合他社との比較の1つの方法として、製品やフローのプロトタイプのレプリカを作り、ユーザーの製品とのインタラクションや関わり方を見ることができます。デザイナーはこのインサイトをもとに、デザインの修正、改良を加えることができます。

testing user behavior

競合製品の真似をすることが目的ではなく、参加者の反応をみたり、どのプロトタイプがより直感的で、魅力的で、魅力的だと思うかを聞いたりするのです。

UXPinによるプロトタイピングとテスト

UXPinのコードベースのデザインツールにより、デザイナーは最終製品のような外観と機能を持つユーザーインターフェースを備えた直感的で魅力的なプロトタイプを構築できます。

UXPinプロトタイプは、製品の改善に向けてステークホルダーからの実用的なフィードバックとユーザビリティスタディからの有意義な結果を得て、最高のユーザーエクスペリエンスを実現します。

また、UXPinはデザインチームとエンジニアの連携を強化し、手直しの軽減とスムーズなデザインハンドオフを実現します。このようなワークフローの強化は、今日の競争市場において重要なメトリクスである、市場投入までの時間を短縮を実現します。

design system 1

  デザインシステムは、品質、一貫性、市場投入の迅速化など、企業が競合他社に対して優位に立つためのもう一つの方法です。UXPinで、スタートアップ企業や小規模企業は、ゼロからデザインシステムの構築、管理、拡張ができます

デザイナーは、Material Design、Bootstrap、iOS、Foundationなどの内蔵デザインシステムを使って、アイデアをさっとプロトタイプ化できます。 

世界最先端のコードベースのデザインツールで、エンドツーエンドのデザインプロセスを強化し、競合他社に差をつけませんか?無料トライアルにサインアップして、UXPin を使って顧客のためにより良いユーザーエクスペリエンスをぜひデザインしてみてください。

デザインチーム におけるDesignOpsについてとその役割

デザインチーム

数人のスタッフで構成される非常に小規模な デザインチーム では、なぜDesignOpsのプロが必要なのか不思議に思うかもしれませんが、ビジネスの成長に伴い多くのフリーランサーの助けを求めるようになったり、製品がより複雑になったりすると、DesignOpsが デザインチーム にとって重要な役割を果たすことがすぐにわかってくるでしょう。

DesignOpsによる多様な人材が集う デザインチーム の構築

テクノロジーは常に前進しています。つまり、新しいトレンドへの迅速な対応が製品に求められます。例えば、今やスマートフォンは文字通りどこにでもあり、2013年に最初のiPhoneが発売されたばかりだということを覚えいる人は少ないでしょう。そして10年足らずの間にアプリがどれだけ変化したかを考えてみてください。今から数年後にあなたの デザインチーム にどんな担当・役割が必要なのか、見当もつかないでしょう。デザインチーム メンバー

現在、あなたのチームには、以下のうち少なくとも1つは必要ではないでしょうか:

  • プロジェクトマネージャー
  • グラフィックマネージャー
  • アニメーションデザイナー
  • UI/UXデザイナー

より複雑なプロジェクトだと、以下が必要かもしれません:

  • コンテンツ制作者
  • アートディレクター
  • ブランドマネージャー
  • デベロッパー

難しいプロジェクトの完遂に適切なメンバーが確実にチームに揃っていますか?DesignOpsのプロは、多様な人材からなるチームを構築することで、注目のクライアントを引きつけてブランドの認知度を高め、収益を上げることができるのです。

関連記事: Design Team Structure: Ideal Setup for Small, Medium & Large Organizations

DesignOpsによる個々のプロジェクトに必要な人材の採用

必ずしも全員を給与支払名簿に載せる必要はありませんが、米国労働統計局によると、アニメーターの年収は約75,270ドル+手当です。アニメーターに常時仕事がある限りは、正社員給与を払う意味がありますが、たまにしかないプロジェクトにアニメーションを加えるだけの人材が必要な場合は、話が違ってきます。

チームメンバーがコンスタントに必要でない場合、業務をフリーランサーに外注することができますよね。その際DesignOpsは、業務に適したスキルと才能を持ったフリーランサーを確実に選び出せます。FiverrのようなWebサイトから無作為に人を雇うこともできますが、その場合、得られる結果を気に入るとは限りません。その点DevOpsなら、その業務に適した人材を見つけることができます。

DesignOpsを信頼して優れたデザインシステムを作成

DesignOps担当者は、戦略を練り、計画をチームに伝えるコーチのような役割を果たしますが、優れたデザインシステムを構築することで、プロジェクトの要件や制限を伝えることが少し簡単になります。デザインチーム デザインシステム

DesignOpsは、クライアントやブランドの専門家なども含め、プロジェクトに関わるすべての人とコミュニケーションをとるため、デザインシステムを作るのにふさわしい人材です。例えば製品開発において、ブランディングは非常に重要な役割を担っていますが、クライアントが製品の認知度を高めるために、どのデザインにも同じアイコンを使用する場合、チームはそのアイコンに限定したデザインシステムを必要とします。多くの場合、DesignOpsは、こういった決定の重要性を知るためにクライアントとのやりとりの窓口になります。

DesignOpsのプロがデザインシステムをコントロールすることで、プロトタイプの作成プロセスが合理化され、クライアントの期待に応えることができるのです。

関連記事: How to Use a Design System to Make Great UX Design Decisions

DesignOpsはビジネス上の問題処理を担当、 デザインチーム は「デザイン業務」に集中デザインチーム メトリクス

予算を気にせずにチームで製品をデザインできたらすごくないですか?すごいことがたくさんできるかもしれませんね!

しかし現実には、デザインプロジェクトには、次のような無数のビジネス業務がつきものです:

  • 予算の追跡
  • 時間の記録
  • メール対応
  • クライアントとのミーティング

ほとんどの場合、デザイナーはそんなことに興味はなく、むしろ自分の好きな業務に時間をかけたいはずです。となると、ビジネス業務をDesignOpsに割り当てることで、デザイナーをデザインに集中させることができ、このような業務の負担がなければ、 デザインチーム の作業はより効率的になり、より良い製品が生み出されるのです。

完璧なプロジェクト管理にはDesignOpsが必要

 デザインチーム には、メンバーの力を結集し、共通のマイルストーンを達成するための仕組みが必要です。つまり、あなたのチームに適したプロジェクト管理法が必要なのです。

 デザインチーム の管理法は、Agile、Scrum、Kanbanなどが最も一般的ですが、チームをより効果的にする可能性のあるオプションは他にもたくさんあります。

また、チームが独自の管理アプローチを必要としている可能性もあります。独自のデザインプロセスを構築することで、壁がなくなり、社員は驚くような機能を実現するための斬新なアイデアを自由に追い求めることができるのです。

あなたが抱えるチームのプロジェクト管理手法を誰が決めるのか。その仕事はDesignOpsに任せましょう。彼らはすでにあなたのチームメンバー、プロジェクト、クライアント、およびプロセスについて多くのことを知っていることから、チームとテクノロジーのベストを引き出す管理手法を選ぶ責任を担うのは自然の流れです。

関連記事:How Agile Environments Revolutionize a Team’s Workflow

DesignOpsで、チームの成功に必要な技術を見つける

 デザインチーム が何を実現できるかは、少なくとも部分的には技術スタックによって決まります。アニメーション機能を備えたソフトウェアがなければアニメーションを作ることはできませんし、プロトタイプと対話できるツールがなければ、デザインをテストすることはできません。

デザインツールをインターネットで検索すると、「最高の機能を提供する」と主張する結果が何十件と出てきます。果たしてその言葉は信用できるのでしょうか?「ベスト◯◯」のリストを作成するライターでさえ、あるデザインツールを他のツールよりも上位に位置づけるような”約束事”を結んでいるのです。

つまり、これらの製品について知っている人の助けを借りるのが一番なのです。どのような評判があるのか?他のツールとの統合はどうか?時代遅れのアプリを使っていることを他のデザイナーが知ったら笑われないか?チームがフォローすべき市場のトレンドはあるか?など、率直に聞いてみればいいのです

DesignOpsのプロは、テックスタックを選択する前に答える必要のある、これらの質問とその他の無数の質問に対する答えを持っており、また、製品開発プロセス全体の最適化に役立つ技術的な新しさも追求するのが常です。

例えば、製品チームにおける切実な問題の1つは、デザインと開発が切り離されることです。デザインのアイデアの一部が生産に移せなかったり、予測よりもはるかに時間がかかったりする瞬間が、ハンドオフ・リアリティ・チェックなのです。

このような状況では、DesignOpsは、デザインをコードに変換するツールや、デザインを開発に移す前に対話性のシナリオをチェックするインタラクティブなプロトタイピングツール、あるいは、すでにコード化されたコンポーネントでプロトタイプを作成して、すぐに製品化できるような技術など、さまざまなソリューションを模索することになるでしょう。

最後のソリューションは、デザイナーがプロトタイプを作成し、デベロッパーが準備の整った製品を発売するまでの時間を短縮することで、製品開発のプロセスが速く簡単になります。もしあなたが、それについてDesignOpsやプロダクトチームのメンバーとして興味があるなら、 UXPin Mergeというソリューションがあります。すでにインタラクティブで簡単に再利用ができるUI Reactコンポーネントでデザインを作成することができます。複雑に聞こえるかもしれませんが、実際には、標準的な要素によるプロトタイピングと、革新的なコードによるコンポーネントとの間に違いはありません。

完璧なソリューションっぽいですか?

UXPin Mergeについて、私たちの見解を鵜呑みにする必要はありません。UXPin Merge があなたにとってどれだけ有益なものであるか、ご自身でお確かめになるのが一番です。コードによるデザインは、 デザインチーム にとって製品開発プロセスの最適化に大いに役立ちますので、革新的でありながらそれほど複雑ではない技術の導入を検討中でしたら、ぜひMerge へのアクセス権をリクエストしてみてください。

デザインチーム DesignOps UXPin Merge

DesignOpsの エキスパート を採用するには?

DesignOps エキスパート

デイブ・マルーフ氏による「総合的なDesignOps」についてのウェビナーは、DesignOpsのトピックを広げるために、他にどんなことを書けばいいのだろうかと考えるいい機会になりました。その1つが「採用」についてです。DesignOpsのエキスパートに何を求めるべきなのでしょうか?ちなみに、ウェビナーをご覧になりたい方は、当社のYouTubeチャンネルの録画をご覧ください。

では、今回の本題である「DesignOpsのエキスパートの採用法」についてお話しましょう。

DesignOpsはまだできたばかりの分野であるため、DesignOpsの エキスパート になるための明確な道はありません。UXのように、デザイナーになるために勉強するのではなく、DesignOpsのエキスパートは、多くが自社の非効率性を解決したいという考えや製品、デザイン、変更管理、またはプロジェクト管理からの転身です。

デザインチームが優れた製品の構築に集中できるようなシステムとプロセスの設定による、生産性や投資対効果の向上が証明されており、今日の超競争的な市場で競争するためには、DesignOpsチームの構築が不可欠です。

DesignOpsの課題を解決するために構築された、世界最先端のコードベースのデザインツールであるUXPin Mergeで、市場投入までの時間を短縮しませんか?UXPin Mergeは社内のデザインシステムをUXPinのエディタと同期させ、デザイナーとエンジニアの間に信頼できる唯一の情報源(Singe source of truth)を作成できます。無料トライアルにサインアップし、MUIライブラリ統合によるMergeをぜひご体験ください。

DesignOpsの エキスパート とは

エキスパート 分析

DesignOpsの エキスパート は、運営上の非効率性を特定し、それを最適化するためのソリューションを見つけることに重点を置いています。DesignOpsの エキスパート は、デザインそのものにはほとんど関わりませんが、その代わりに、デザイナーが仕事をするためのツール、プロセス、システム、プロトコルに焦点を当てます。

DesignOpsには主に10の役割があります:

  1. 運営管理:デザインチームの目標に沿ったデザインロードマップの作成と管理、およびその目標を達成するためのスキルギャップの特定
  2. プロセスデザイン:デザインシステムの構築及び、チームが必要とするツールのマッピング
  3. プロジェクト管理:ワークフローのデザインによるプロジェクトの割り当て、及びスケジュールの設定によるボトルネックの解消
  4. コミュニケーション戦略の作成 :コミュニケーションチャネル、ファイルやリソースの保管などのデザインチームと組織の間の連絡
  5. 新規採用のオンボーディング :新しいスタッフがデザインチームとシームレスに溶け込むよう、採用、オリエンテーション、トレーニングの実施
  6. デザインチーム文化の構築:ワークショップやトレーニングなど、チーム構築のためのイベントによる企業文化の普及
  7. 予算の配分と管理:製品の直接コストではなく、デザインチームの運営に関わるコストの管理
  8. 法務:法務チームと協力し、NDA(秘密保持契約)、参加者リリースフォーム、その他の法的文書の作成
  9. 調達プロセスの管理:財務部門と連携した予算の制約を満たすための購買決定の合理化及び管理
  10. ITとセキュリティ: IT部門との連携による、すべてのツールやプロセスがセキュリティ基準を満たしていることの確認

DesignOpsには、主に3つのポジションがあります:

  • DesignOpsリーダーまたはDesignOpsの責任者
  • DPM(デザインプログラムマネージャー)
  • デザインプロデューサー

DesignOpsリーダー

DesignOpsリーダーは、デザインリーダーと密に連携し、運営ビジョンとロードマップを作成します。このハイレベルな役割は、デザインチームがどのようにタスクやプロジェクトを完了させるかに焦点が当てられています。

DesignOpsリーダーは通常、チェンジマネジメントとプロジェクトマネジメントのバックグラウンドを持っており、エンドツーエンドのプロジェクトプロセスを認識しながら、どのように変化を促すのかを理解していなければいけません。

UXPinのウェビナー「Measuring DesignOps Impact」でパトリツィア・ベルティーニ氏が言うように、DesignOpsは「既存の現実を変え、より大きな価値をもたらすものであり、非常に変革的な学問」です。

DesignOpsリーダーは、運営ワークフローを最適化するためのツールやプロセスを見つけ出し、その採用を促進するための戦略を立てなくてはいけません。

DPM(デザインプログラムマネージャー)

DPMは、DesignOpsリーダーの戦略とロードマップを実行する責任を担っており、UXチームや製品チームと連携してデザインに集中するために必要なサポートを提供します。

これを効果的に行うべく、DPMは通常、デザインのバックグラウンドを持ち、それによってエンドツーエンドのデザインプロセスを理解し、障害の特定ができます。

また、DPMはチームやプロジェクト間の橋渡し役として、連絡や連携を向上させる役割も担っています。

デザインプロデューサー

デザインプロデューサーは、デザイナーがデザインに専念できるよう、管理・運営上のタスクを管理しながら、プロジェクトに直接携わります。連絡と連携を促しながら、すべてがきちんとスムーズに進むよう、エンドツーエンドのデザインプロセスを管理します。

DesignOpsリーダーのスキルセット

designops エキスパート スキルセット

DesignOpsリーダーがデザインを理解していると有利ですが、もっと重要なのはDesignOpsリーダーに変更管理のバックグラウンドがあるかです。つまり彼らは、変更の実装や人材採用の促進をする方法を理解していないといけません。

DesignOpsリーダーは、予算、戦略、および実行に関する優れたビジネス管理スキルを備えていなければならず、また、人を管理し、Opsのビジョンに導く必要があります。

コミュニケーションと人脈作りは、DesignOpsの重要なスキルです。リーダーは、デザインを提案し予算の賛同を得るために、多くの時間をかけてステークホルダーや幹部とのやり取りをし、組織の他のメンバーに対してデザインの意見を述べ、同僚と会って連携の機会を探ったりします。

DesignOpsリーダーの責任

パトリツィア・ベルティーニ氏は、「Measuring DesignOps Impact」(弊社主催ウェビナー)の中で、以下のDesignOpsの3つの分野について述べています:

  • ビジネス運営
  • ワークフローとデザインの運営
  • 人的運営

ビジネス運営

予算、リソース、その他ビジネス関連のデザイン機能を管理し、例えば以下のようなものが挙げられます:

  • 予算管理/支出の最適化
  • 支出政策の概要
  • エンド・ツー・エンド調達と3PRM(パフォーマンス&リワードマネジメントの実践)
  • 契約交渉
  • ベンダーの導入と3P(Process、Product、People)リスクアセスメント
  • 支出ROI(投資収益率)の計算
  • ツールROI/インパクトアセスメント
  • リソースの要求アセスメント(ツール+人)
  • CW/FTEの順序付け

ワークフローとデザインの運営

エンド・ツー・エンドのデザインプロセスの全体像であり、デザイナーはどのようにしてコンセプトから最終製品まで到達するのか?その例をご紹介します:

  • エンドツーエンドデザインプロセスの最適化
  • ツールエコシステム管理
  • ツールのオンボーディング/オフボーディング
  • 部門を超えた連携の最適化
  • デザインシステム管理
  • データガバナンス
  • 参加者調達プロセスマネジメント
  • リサーチおよびデザインアセットマネジメント
  • デザイン基準

人的運営

スキルアップ、コミュニケーション、文化など、デザインチームの人間的側面についての考察。例としては、以下のようなものが挙げられます:

  • キャリアパスの方向性
  • スキルマトリックス/チーム構成アセスメント
  • 育成プログラム、チームトレーニング
  • チーム文化
  • 知識・経験トレーニング
  • 随所に部門間連携の効率化
  • オンボーディング/オフボーディング
  • 社内コミュニケーション
  • チェンジマネジメント
  • エンゲージメントモデル
  • 採用・業務仕様・タスクの見直し

DesignOpsの エキスパート を今雇うべきか

designops increasing collaboration talk

ここでは、あなたにDesignOpsのエキスパートが必要であるかを判断するサインをいくつかご紹介します:

  • サイロ、連絡、連携に問題があり、その結果、プロジェクトの納品にまとまりや一貫性がない。
  • ツールが多すぎて、ワークフローが混乱を招いたり、エラーが発生したりする。
  • デザインチームが納期に間に合わないことが頻繁に起こったり、高い手直し率が市場投入までの時間に悪影響を与えたりしている。
  • デザイナーが、運営や管理業務でデザインに集中できないことに不満を抱いている。
  • デザインリーダーは、デザイン関連の業務よりも新入社員の受け入れ、オリエンテーション、トレーニングに多くの時間をかけすぎている。
  • デザイナーは、UIデザイン、リサーチ、テストなど、1つの主要な業務に集中または特化する代わりに、多くの他の業務の負担がかかりすぎている。

DesignOpsについて、また組織におけるその役割について、以下の資料でご確認ください:

当社のウェビナーをご覧ください

当社では、デザインとDesignOpsの エキスパート を招いたウェビナーが定期的に開催されており、今回のウェビナーは、エンタープライズデザインシステムの構築とスケーリングについてです。スピーカーはDelivery HeroのDesignOpsリーダーであるアンバー・ジャビーン氏で、一元的デザインシステムの構築方法についてご紹介しています。

こちらからご覧ください: Enterprise Design System–How to Build and Scale.

UXPin Mergeによるデザインの最適化

デザインシステムの管理は、DesignOpsのエキスパートにとって最大の課題の1つであり、デザインシステムのUIキットをコンポーネント・ライブラリと確実に同期させるには、かなりの時間と労力が必要です。

Mergeを使用すると、デザインシステムをレポジトリからUXPinのエディタに同期させ、デザイナーはエンジニアと同じコンポーネントを使用し、組織全体で信頼できる唯一の情報源(Single source of truth)を作成できます。レポジトリに変更があると自動的にUXPinに同期され、デザインチームに新しいリリースが通知されます。

UX ワークフローを 1 つのツールで最適化してみませんか?無料トライアルにサインアップしてUXPin の MUI 統合による Merge を体験してください。

Design Value Conference 2022のまとめ:世界企業のDesignOps課題への取り組み

DVC Scaling

2022年3月に開催されたUXPinの第1回デザインバリュー会議では、世界最大級の企業におけるデザインとDesignOpsを理解すべく、デザイン業界のリーダー5人が招かれました。

本記事では、「デザインバリュー会議2022」で取り上げられた内容がすべてまとめられ、各講演のあらすじと30分の動画にリンクしています。

デザインバリュー会議 2022は、世界最先端のコラボレーティブプロトタイピングツールであるUXPin Mergeの提供で行われました。無料トライアルにサインアップし、MUI Storybookとの統合を通じてUXPin Mergeをご体験ください。

Merge Component Managerについて:ユーガ・コーダ氏(UXPin CEO)

  UXPin CEOのユーガ・コーダ氏は、デザインバリュー会議 2022の開幕にあたり、エンジニアに頼ることなくコンポーネントライブラリを同期させる新しい方法である、UXPinの新製品「Merge Component Manager」を発表しました。

現在の形態の Merge では、UXPin と同期するコンポーネント ライブラリおよびレポを準備すのにエンジニアの助けが必要ですが、Merge Component Managerだと、コンポーネントを取り込む際のコードは不要です。

Merge Component Manager では、NPM パッケージを通じてコンポーネントのインポートおよび設定ができ、デザイナーはコードレスプロセスにより、UXPin内でコンポーネントのプロパティを設定および管理し、プロトタイプの構築時にコード化されたインタラクションの力を発揮することができます。

ぜひ、まずはあなたからUXPinのMerge Component Manager試してみてください– これでデザイナーはコードコンポーネントを使ってプロトタイプを簡単に作成できます。

マギー・ディエンジャー氏(Uber Eats)

UberのシニアDPM(デザインプログラムマネージャー)であるマギー・ディエンジャー氏が、UberにおけるDesignOpsについて貴重な見解を語ってくれました。

Uberの様々な製品に携わってきたマギーは、複数のチームの規模とあらゆる成熟度において、どのようにDesignOpsに取り組んだかの事例を紹介しました。

こちらが、彼女の講演のポイントです。

フレーミングとスケーリング

マギーは、DPMが効果を最大限発揮するのにどこに時間をかけるべきかを決めるフレームワークとスケーリングプロセスを採用しています。彼女は、組織を正確に捉え、十分な情報を得た上で意思決定を行うために、3つのフレーム化要素を使用しています:

  • デザイン組織の規模と状態
  • デザインチームのリソース
  • 提携のレベル

DPMのインパクトを上げる

組織とその問題を明確に理解した上で、彼女は適切な 「関与のレベル 」を選択します。DPMは、ズームインしているときはより実践的で、チームと一緒に日々の仕事に取り組みますが、ズームアウトしているときは、アドボカシー、戦略、プランニングに重点を置きます。

DPMの軌道をサポート

最後に、彼女は長期目標でのDesignOpsのロードマップを作成し、フレームワークのエクササイズを使って、以下の重要な軌道の質問3つに答えたいと考えています:

  • 今日どこにいますか?
  • どこにいたいですか?
  • チームはどこにいたいですか?

サロメ・モルタザヴィ氏(SiriusXM)

SiriusXMのDesignOpsディレクターであるサロメ・モルタザヴィ氏が、DesignOpsのロードマップを作成するためのフレームワークの使用について語っています。

彼女はSiriusXMやフォーチュン500の多くの企業との仕事を通じて貴重な知識と経験を得ており、今回の講演でそれをシェアしてくれます。

こちらが、サロメのトークのポイントです。

初心者のためのアドバイス

初心者のDesignOps実践者が犯しがちな間違いの1つは、なんでも屋なってしまうことです。彼らは、より大きな絵に焦点を当てる代わりに、あまりにも多くの日常的な業務を引き受けてしまいます。

始めるにあたって、サロメはこれを克服するために3つの提言をしています:

  • 価値を見出す:自分が最も付加価値の高い分野を探す
  • 効率と有効性:ベースラインの特定に正しい測定基準を使用して問題のフレームワークから始める
  • 話を聞き、メモを取るあなたが必要だと思う改革に飛びつくのではなく、チームメンバーにインタビューし、彼らの課題を把握する

DesignOpsフレームワーク:デザイン成熟度指数

サロメは、「デザイン成熟度指標」を使ってテーマや問題を特定し、以下の2つの “バケット “に分類しています:

  1. DesignOps(デザイン組織運営)
  2. デザインリーダーシップ/デザインチーム/プロダクト (デザインプラクティス運営)

彼女は、これらのテーマや問題をメニューツールで適宜割り当て、分類しています。

DesignOpsロードマップの作成

確定され割り当てたられた問題を元に、サロメ氏は、3つの時間軸といくつかのカテゴリでDesignOpsのロードマップの概要を作成し、【構築】、【測定】、【学習】の方法論を使って実装・進化させます。

彼女の講演の模様は、ブログでご覧いただけます。

エリカ・ライダー(Paypal)

PayPalのUX Lead EPXであるエリカ・ライダー 氏が、デザインの拡張のために従来の DesignOps モデルをどのように修正し、UX の責任を企業全体に移したかについてお話します。

従来のDesignOpsとDesignOps 2.0の比較

エリカのDesignOps戦略は、デザイン部門ではなく、デザインプラクティスを拡張する必要がありました。これを実現するために、彼女とチームは、DesignOpsの構築の代わりにDevOpsの中でデザインを運用しようということで、DesignOpsとDevOpsのハイブリッドフレームワークを作成しました。

責任の進化

このハイブリッドシステムを成功させるために、エリカはプロダクトチームにデザイン、プロトタイプ、テストの権限を与えるとともに、プロダクトマネージャーやエンジニアにUXの重要性を説く必要がありました。

PayPalのDesignOps 2.0プロセスを進化させる

2019年からDesignOps 2.0に取り組んできたエリカと彼女のチームは、より良い製品の提供のために、製品チームのプロセスを進化させることに取り組んでいます。

彼女は、ユーザーリサーチ運用のためのシステムに取り組んでおり、PayPalのハイブリッドな運営モデルにおいて、製品、デザイン、エンジニアリングがUXの責任を共有できるよう、コントロールとアカウンタビリティのバランスを整えているところです。

PayPalのUXチームは、UXウィザードツールを使って、このDesignOps 2.0の次のイテレーションを測定し、進化させています。

エリカ・ライダー氏は、PayPal の DesignOps 2.0 の基盤として UXPin Merge を使いました。無料トライアルに登録し、Merge がどのようにデザイン運用を拡張できるかをご確認ください。

オムカー・チャンドガドカー氏(Amazon)

Amazon Alexa Smart HomeのシニアUXデザイナーであるオムカー・チャンドがドカー氏が、自身の2つのフレームワークを用いて、よくあるデザイン上の課題を克服することについてお話します。

オムカー氏は、ハイテク大手のIBMやアマゾンでの経験から、これらのフレームワークを開発し、積極的に行動することで、戦術的アプローチ(オムカーが言うところの「飛びながら飛行機をデザインする」)から戦略的アプローチへと移行しました

デザインチームのよくある課題

オムカー氏は、デザインチームが大企業で経験する3つの一般的な課題について概説しています。つまり、デザインチームは長期的な戦略に取り組むというより、躍起になっていることが多いのです。

オムカーは、この「躍起になる問題」の克服のために、2つのフレームワークを使用しています。

フレームワーク1:オムカー氏の「点と点をつなげるマップ」

点と点をつなげるというのは、プロダクト、デザイン、エンジニアリングの各活動とフレームワークを連携させ、ソフトウェア開発プロセス全体を通じて連絡と連携を改善することです。

点と点をつなげるマップの目的で、あなたの企業がどのように意思決定し、これらの意思決定がどのように相互依存しているかを特定しやすくなります。そうすると、DesignOpsは、デザインを組織の他の部分と連携させる戦略を実施し、より合理的な製品提供が可能になります。

フレームワーク2:オムカー氏が提供するデザイン

オムカーの積極的なDesign Offerings戦略は、DesignOpsがプロジェクトのプロダクトマネージャーを販売する製品を作るプロセスです。

これらの製品は、プロジェクトの取り込みを合理化し、デザインチームに実用的な最初のステップを提供します。DesignOpsの実践者は、新規プロジェクトや製品バックログにDesign Offeringsフレームワークを使うことができます。

オムカー氏のフレームワークの使い方

点と点をつなぐマップ:

  • プロジェクトの進め方やプロジェクト計画作成の参考として
  • 過去の決定事項とのギャップを確認するための仕組みとして

デザインの提案:

  • パートナーがデザインからどのような利益を得ることができるかを教育する手段
  • 戦術的なプロジェクトと戦略的なプロジェクトのバランスをとるための取り込みメカニズム

UXPinでは定期的にさまざまな業界からのゲストをお呼びしたウェビナーを開催しています。

Delivery Hero MENA(talabat)のDesignOpsリーダー、アンバー・ジャビーン氏を招いた新しいウェビナーをご覧いただけます。彼女は、異なる市場にまたがって機能する集中型デザインシステムのための企業の賛同を得ることについてお話しています。

こちらも是非ご覧くださいませ。

 

DPM(デザインプログラムマネージャー)が与える影響とは?

DPM Uber

Uberのシニア  DPM (Design Program Manager)であるMaggie Dieringer(マギー・ディエリンガー氏)様に、2022年3月にUXPinが主催したデザインバリュー会議で登壇いただきました。

彼女は2016年からUberで DPM としてRidesとEatsのプロダクトに携わり、世界最高の技術者たちと一緒に働くという貴重な経験を積んできました。

デザインバリュー会議 2022 での30分の講演で、彼女はUberの DesignOps を一から構築するのに貢献した方法についてインサイトを語りました。デザインチームやステークホルダーと連携する際にDPMが考慮すべき3つの重要な「フレーミング要因」など、 DesignOps に対する彼女の実践的なアプローチについて話しています。

​​デザイナーとエンジニアが、デザインとコードにおける信頼できる唯一の情報源(Single source of thruth)を使用できるようにし、UXPin の革新的な Merge 技術を使用して、DesignOps の最大の課題を解決します。UXPin Merge がどのようなものであるかをご覧ください。

 DPM (デザインプログラムマネージャー)とは

ここでは、DPMという職種に馴染みのない方に、より理解していただくべく以下に定義を簡単にご紹介します。

DPM(デザインプログラムマネージャー)は、UXチームと密に連携し、タスクやプロジェクトを完了するのに必要な運営面でのサポートを提供します。DPMの仕事は、DesignOpsのビジョンとロードマップの実行であり、通常は DesignOps リーダーの指示のもとで行います。

Uberの DesignOps 

マギーがUberに入社したとき、DesignOpsチームには自身を含めて2人が所属しており、チームは7つのカテゴリーをカバーしていました:

  • DesignOps:ツール、設備管理、組織管理、DPMブランドなど。
  • ポートフォリオ計画:年間計画、半年計画、チームを超えたスケーリングプラクティス、MTR、ヘッドカウントコミュ二ケーションなど
  • ロードマップ管理:優先順位付け、カットラインの管理、リーダーシップとのスタックランキング、スコーピング、シーケンス、QA、品質の支持者など。.
  • コミュニケーションとイベント:外部ブランド、採用経験、オフィス文化、チーム/社内/業界イベント、チームミーティング、祝賀と表彰、チームの健康、など。
  • モデリング、トラッキング、レポーティング: リソーシング&アロケーション、作業の交渉、依存関係のトラッキング、作業の取り込み、UXアロケーションの報告、キックオフ、クリット管理、デザインレビューのテンプレート化、など。
  • 財務と成長:予算/T&E/モラールトラッキング、人員配置、成長シナリオ、プレイブックとツールキットなど。
  • L&D:トレーニング、社内外のスキルシェア、社外デザインイベント、オンボーディング、タレントレビュー/プロモ管理、キャリアパス、コンペテンシー、インスパイアチーム、外部スピーカー、など。

2022年3月現在、UberのDesignOpsチームは、北米、ヨーロッパ、中東、アフリカ、南米にある6つのオフィスをサポートする16人のチームメンバーに成長し、さらに4人のチームメンバーがチームの垣根を超えてDesignOpsの戦略ポジションで仕事をしています。

  • TeamOps & ResearchOps × 6名
  • プロダクトDPM x 12名
  • ディレクター&ストラテジック x 4名

Uberの DPM の役割のフレーミングとスケーリングへのアプローチ

マギーは、様々なレベルでDPMの影響力を高めるためのチームの戦略について以下の3点について話しました。

  1. (企業の現在の優先順位に応じたニーズに応じた)DPMのフレーミング及びスケーリング
  2. DPMのインパクトの向上
  3. DPMの軌道のサポート

 DPM のフレーミング及びスケーリング

「どこに時間を使うのがベストなのか」「その時間で確実に最大の効果を発揮するにはどうすればいいのか」と自問してみてください。

マギーは、何かをするのにやり方に正解も不正解もなく、インパクトに焦点を当てた仕事を組み立てていくべきであると考えています。このアプローチは、「我々の成功は、自らの仕事が製品、ビジネス、デザイン、そして顧客体験に与えるインパクトに基づいています。このインパクトは、組織的、戦略的、あるいは実行的なものであるかもしれません」という、UberのDesignOpsの原則の1つと一致しています。

彼女は、日々最も影響を与えるフレーミングの要因を3つ挙げています:

  • デザインチームの規模や組織の状態
  • どんなリソーシング、アロケーション環境なのか
  • 主要なデザインパートナーのレベル

フレームワーク要因1:デザイン組織の規模と状態

designops increasing collaboration group collab

組織の状態や規模は、どのレベルのチームを管理・サポートするかに大きく影響します。

「組織の状態やチームの規模に関係なく、チームの現状を把握します。」 シニアDPMー マギー・ディエリンガー氏(Uber)

状態:

  • チームの歴史の長さ
  • 組織の成熟度

規模:

  • サポートするデザインチーム、エリア、サブエリア、ポートフォリオの規模

デザイン組織の状態

マギーは、チームの状態と成熟度を、初期段階から確立段階までで定めています。DPMのアプローチはスペクトルの両端では全然違ってくることから、この定義は重要になってきます。

例えば、DPMは、できて間もない組織では、成長と発展を促すためのプロセスやフレームワークの導入に重点を置くことになりますが、既存のチームでは、成長に対応するために、進化、反復、伝道、既存のプロセスやフレームワークの改善に焦点を当てます。

デザイン組織の規模

規模は、最初のフレーム要因のもう一つの要素であり、マギーは、チームメンバーが10~15人の場合を【低】、30~50人の場合を【高】にして、同じようなスペクトルを使用しています。

業界標準では、10~15人のデザイナーにつき1人のDPMが必要ですが、多くのDesignOps専門家にとってこの比率は現実的ではありません。

15対1の割合で、DPMはデザインチームと統合して、以下のようなタスクを含むきめ細かいサポートを提供することができます:

  • ICデザイナーとの毎日のミーティング
  • チームミーティングの管理・運営
  • デザインレビューへの参加と運営
  • プロジェクト管理
  • ミクロレベルでの連携の最適化

比率が高くなるにつれて、DPMはハイレベルなアプローチに向かいます:

  • ICデザイナーとの月例ミーティング
  • マネージャーと毎日のミーティング
  • 数ヶ月に一度、クリットに参加
  • デザインレビューに参加し、点と点を結ぶ手助けをする
  • マクロレベルでの連携
  • ビジョンエクササイズ

フレームワーク要因2:デザインチームの人材

DesignOps DPM

エンゲージメントとスタッフィングモデルの設定方法、およびアロケーションと組織戦略は、DesignOpsをどのように活用できるか又は活用していくかに非常に大きな影響を与える可能性があります。

エンゲージメントモデル:

  • チームはどのようなタイプの人材配置を行っているか

アロケーション:

  • 自身がサポートするチームは、十分な人員配置や無駄のない運営がされているか?

エンゲージメントモデル

Maggieは、組織の人材配置モデルを特定するために、【フレキシブル】と【フルタイム】の2種類のスペクトルを使用しています。フレーミング要因1の「サイズ」と同様、人材配置モデルによって、DPMがどのレベルでチームと関わることができるかを判断することができるのです。

フレキシブルモデルでは、DPMは1つの分野に深く入り込む必要があるかもしれませんが、完全な専用モデルでは、多くの分野にわたってより全体像に焦点を絞ることができます。

アロケーション

リソーシングに関するもう一つの考慮点は、その企業が人材確保に制約があるのか、成長モード(積極的な採用)にあるのか、あるいはその中間なのか、ということです。人員配置に制約がある場合、DPMは利用可能なすべての人材を駆使して、クリエイティブに仕事を進めなければなりません。

成長モードでは、DPMはより自由に、高いレベルのビジョンや組織の成長戦略を見ることができます。

フレームワーク要因3.業務提携のレベル

designops increasing collaboration talk

レベル:

  • 主にIC(個人貢献者)、リード、マネージャー、またはディレクターとの業務提携を組んでいるか?

経験:

  • 提携パートナーはDPMと仕事をしたことがあるか?

レベル

デザインマネージャーや中間管理職と仕事をするとき、マギーは、負荷分散、チームの健康、デザインとの連携方法に関する教育、その他のサポート役など、一つの分野や活動に集中することが多いことに気づきました。

一方、ディレクターレベルでは、ディレクター直属のリーダーシップチームの編成、組織戦略、チーム間の依存関係の検討、プログラムの拡張、より広範なチーム全体の活動などに取り組みます。

経験

要因3の2つ目の考慮点は、提携パートナーがDesignOpsに触れているか、また、以前にDPMと仕事をしたことがあるかということです。パートナーがDesignOpsに馴染みがない場合、DPMの役割について教育し、どこまで求めるかを決めるのが非常に重要です。

マギーは、DPMは業務提携の開始時に、何を担当しないかを含め、それぞれの役割と責任を概説し、明確な境界線とビジョンを設定することが重要であると述べています。

 DPM の影響力を高める

designops efficiency speed optimal

DPMとしての影響力を高めるには、あなたやあなたのチームがどの程度関与するのが望ましいかによって違ってきます。ここでもマギーは、活動の評価のためにスペクトルを使っています。

ズームインしているときは、DPMはより実践的で、チームと協力して日常的な作業を行いますが、ズームアウトしているときは、アドボカシー、戦略、プランニングに重点を置いています。

DPMがズームインとズームアウトのどちらのレベルで活動できるかは、チームの規模やデザイナーとDPMの比率が大きく影響します。

我々はその規模を利用して、望ましいDPMの関わり方を促します。」 – シニアDPM マギー・ディエリンガー氏(Uber)

DPMの軌道をサポートする

designops efficiency person

DPMの長期的な目標を考えるとき、マギーはこの5つの重要な質問をよく投げかけます:

  1. 日々どのような活動や環境が、自分に仕事のやりがいをもたらしてくれるのか?
  2. 自分がサポートするチームに対して、何が今最もインパクトと影響力を持つのか?
  3. 自分のキャリアにとって重要なことに取り組むには、提携パートナーをどのように活用すればいいのか?
  4. 望ましい行動や関わり方に影響を与えるには、チームの規模をどのように利用すればいいのか?
  5. 自分は戦術的な活動か戦略的な活動か、あるいはその両方が得意なのか?

彼女は、DPMが上記の3つの要素を使ってフレームワーク演習を行い、自分たちが最も影響を与えられると思う場所をプロットすることを勧めています。

この3つのフレーム要因に記載された活動を踏まえて:

  • 今日のあなたはどこにいますか?
  • あなたはどこにいたいですか?
  • あなたのチームはどこにいたいですか?

マギーの30分間のDesignOps Layers of Impactウェビナー全編をYouTubeでご覧ください。読むのが好きな方は、カンファレンスの全容をまとめたブログ記事をご覧ください。

UXPin MergeでDPMのインパクトを高める

UXPin Mergeで、デザインの一貫性とデザインチームと開発チーム間の連携の強化が実現します。デザインプロセスを最適化し、より早くインパクトを与えるために、DPMなら誰でも備えるべきツールの1つです。UXPin Merge をチェックして、あなたの組織でどのようにデザインを成熟させることができるかをご覧ください。

DesignOpsで企業内のコラボレーションを改善するには?

2022年2月、UXPinはDesignOpsのエキスパートであるデイブ・マルーフ氏を迎え、「Holistic Design Operations」と題した無料のWebセミナーを開催しました。彼は、彼と自身のチームが、大企業やエンタープライズ企業に共通するサイロ(情報が連携されていない状態)の解消のために、「人の動かし方問題」をどのように解決したかについて話しています。

2022年5月、企業向け集中デザインシステム構築に関するウェブセミナーに参加しました。「Enterprise Design System–How to Build and Scale. 」から無料でご覧ください。

世界最先端のコードベースのデザインツールで、自社のUXの価値を上げましょう。デザイン、プロトタイプ、テストをより速く行い、凝集性と一貫性を向上させます。無料トライアルにサインアップし、コードベースデザインによってUXのワークフローがどのように強化されるかをご確認ください。

企業はサイロ化しやすい

designops increasing collaboration group collab

多くの企業にとって、サイロ(情報が連携されていない状態)は重要な問題です。このような縦割りのサイロは、チーム、プロジェクト、業務の間に横の隔たりを生み、デザインチームがいい仕事をできなくなります。

企業は、3つのレベルでの個々のワークストリームの作業の管理が必要です:

  • プロジェクトレベル
  • プログラムレベル(プロジェクト群)
  • ポートフォリオレベル(プログラム群)

組織の規模が大きくなると、このようなサイロが拡大し、問題が発生・深刻化します。このサイロを構築した基盤は崩壊し始め、一貫性、結束力、最適化、効率性、スピードが低下し始めます。

組織は、このような縦割りのサイロに気を取られ、全体的なデザイン実践のサポート構造を維持する能力を失ってしまいます。一度にこれらのサイロのうちの1つだけに焦点を当てることは、拡張性のある解決策ではなく、問題を悪化させるだけです。

たとえば、デリバリーを拡張しようとすると、実務やビジネスなど他の運用プロセスにボトルネックが発生し、このサイロ間のギャップを埋めるには、全体的なDesignOpsのアプローチが必要です。

全体的なDesignOpsの導入

DesignOps(Design Operationsの略)とは、デザインプロセス、人材、テクノロジーを最適化し、製品のデザインやビジネス価値を向上させるとともに、従業員にとってより良い、実りある、効率的な労働環境を構築することを指します。

デイブ・マルーフ氏は、DesignOpsを3つの柱で表現しています:

  • デリバリー運営:プロセスとプログラム-通常、DesignOpsが最初に着手する場所。効率性、速度、コスト削減を最適化し、どのようにデリバリーするかに焦点を当てる運営
  • プラクティス運営: 人、スペース、方法、ツールでデザイナーによるデザインが可能になる。品質、コミュニティ、エンゲージメントに焦点を当てる運営
  • ビジネス運営:デイブ・マルーフ氏曰く、”誰も話題にしたがらない業務“。チームが対処しなければならない官僚的な業務。財務、IT、調達、コンプライアンス、法務などに焦点を当てる運営

前述したように、DesignOpsの3つの柱は互いに影響しあい、絡み合っています。デザインオペレーションを最適化するのであれば、全体的なアプローチで、これらの分野すべてに優先順位をつける必要があります。何かを省いてしまうと、問題を解決するのではなく、問題を増やしてしまう可能性があるのです。

DesignOpsは運営上の問題をどのようにサポートするのか?

designops increasing collaboration group

このような運用上の問題は、例えばデザインシステム、プラットフォームレイヤー、再利用可能なコアコンポーネント、共通のブランディングなど、アーキテクチャ上のソリューションで解決できると誤解されています。

これらは合理的な解決策ですが、問題は技術的なマッピングではなく、人の問題なのです。

運営上の問題の発見

デイブ氏とDesignOpsチームは、プラットフォームやツールが増えると、人材を考慮せずにプロセスの最適化に注力するため、解決しようとする問題が大きくなることが多いことに気づきました。

問題はデザインではなく、サービス管理の問題だったのです。

彼は自身のDesignOpsチームと、この人材の問題に対する発見プロセスを開始しましたが、解決策に行き着くには、複数の部署のチームメンバーとの共同作業が必要でした。

そこで彼のDesignOpsチームは、ジャーニーマッピングのサービスの青写真を用いて、4つの鍵となる分野を調査しました:

  • 規模
  • サイロ
  • 橋渡し

プラットフォームとコンポーネントはあっても、真の問題は運営の欠如にあったのです。つまり、人間同士で話されたことを実践とプログラムに絡ませる方法を見つけなければならず、彼とチームのソリューションは、デザインの意図からデザインの実行に至るまで、話を動かす必要があったのです。

調査を終えたデイブのDesignOpsチームは、垂直サイロという難問に再びたどり着きました。

この運用上の問題は、サイロの中にいる人たちが、サイロのメンテナンスも行っているため、ツールだけでは解決しにくいという問題がありました。技術的な意味での橋渡しはあっても、運用や話のレベルでの橋渡しはほとんどなかったのです。

彼らは、人々が目隠しをしていること、つまりトンネルビジョン的な考え方があることがわかったのです。サイロの視点で物事を判断し、それが他のサイロや会社と一致しないのです。

このような個々のサイロに根本的な問題があったわけではありません。チームはデータを使って意思決定を行い、システムやプロセスを最適化していましたが、それぞれのサイロが独立して運営されているため、納品物のまとまりや一貫性に欠けるのです。

彼のチームは、ユーザーの視点から物語レベルの接続点を作るために、運用モデルを変更する必要がありました。

デイブ・マルーフによるオペレーション最適化戦略

designops efficiency speed optimal

デイブ氏とDesignOpsチームは、業務プロセスの親ジャーニーを作成し、それぞれの親はチャネルと意思決定ツリーを持つ2Dのジャーニーマップを作成しました。

彼のチームは、各段階でメタデータを作成し、チームメンバーが業務上の意思決定の背後にある意味を掘り下げることができるようにしました。このメタデータは、ビジネスチームとデリバリーチームに伝えられ、優先順位の決定とより良い意思決定に役立てられました。

メタデータには、作業へのリンク、インサイト、プロジェクトが発展するにつれてチームがモニタリングしなければならないメトリクス、機会などが含まれていました。彼のチームは、連携と連絡のためのコメントシステムも用意し、プロジェクトの要件に合うようにペアレントジャーニーを動的なものにしました。

​​このダイナミックなジャーニーマップにより、プロジェクトの現状と複数の将来の状態案が可視化され、チームメンバーは優先順位をつけて意思決定を行うことができるようになりました。

オペレーションチームは、DPM(デザインプログラムマネージャー)をジャーニーの作業に、別のDPMをデリバリーに割り当てました。これらのDPMとチームのジャーニーマップシステムを組み合わせることで、サイロ間のギャップを埋めることができ、プロジェクト、プログラム、ポートフォリオ間の結束と連携を向上させることができたのです。

デイブ・マルーフ氏のアプローチの詳細については、UXPinが主催したウェビナー「Holistic Design Operations」でぜひご確認ください。

UXPinで連携を改善

UXPinでUXワークフローを最適化し、連携、結束力、一貫性を上げましょう。UXPinのコードベースのデザインツールを使用すると、デザイナー間の連携がよくなり、エンジニアとのデザインのやりとりが合理化されます。

UXPinをあなたのチームでお試しください。今すぐ無料トライアルにサインアップを!

5人のエキスパートが語る「DesignOps」とは?

本記事は、5人の業界エキスパートによる戦略とプロセスを分析し、ブログ記事、インタビュー、ウェビナー、講演を通じて、このDesignOpsの先駆者たちが共有している知識をまとめたものです。

DesignOpsの多くの課題を解決してUXワークフローを最適化する、コードベースのデザインツールであるUXPinで、企業内のデザインに革命をもたらしましょう。無料トライアルにサインアップして、MUIライブラリ統合による Merge をご体験ください。

デイブ・マルーフ氏 (Teladoc Health) – デザイン・オペレーションズ・ディレクター

デイブ・マルーフ氏は、デザインオペレーションの黎明期から活躍するベテランのエキスパートです。-Supersideによると、「DesignOps」という造語は彼によって作られたそうです。

彼はDesignX Communityの有名な講演「Amplifying Design Value」(自身のメディアのアカウントでも公開)で、企業内でOpsがデザインの価値を高めるための方法を概説しています。

  • 形が与えるもの:線、レイアウト、構成、色、文字、質感、ボリューム、ネガティブスペース、並置、整列、フローなど、形が価値を生む仕組み
  • わかりやすさ:ユーザーがデジタル製品を使いこなすための情報アーキテクチャ
  • 行動への適合性:実世界の活動を効率化、あるいは補完する直感的なユーザー体験の提供方法
  • 探索:デザイナーがスケッチやトライアルを通じて可能性を発見する方法

Supersideのインタビューの中で、彼はDesignOpsが解決しなければならない重要な課題を以下のように挙げています:

  • 技術・手法・工程の改善
  • ベストなツールを見つける
  • 最高のチームを雇う
  • 最適なチームの管理
  • 適切なコミュニケーション・チャネルの構築
  • 素晴らしい仕事をしたチームメンバーへの報奨方法
  • 部門を超えたステークホルダーとの連携プロセスの開発
  • アセット管理のワークフロー
  • 納品プロセス
  • ベストプラクティスのデザイン
  • ガバナンスとポリシーのデザイン

DesignOpsに対する彼のアプローチについては、デイブがUXPinと行った1時間のウェビナー「Holistic Design Operations」で詳しくご覧ください。

パトリツィア・ベルティーニ氏 (Babylon Health) – デザイン・オペレーションズ・アソシエイト・ディレクター

パトリツィア・ベルティーニ氏は、Babylon Healthのデザインオペレーション担当アソシエイトディレクターです。2021年12月にUXPinとウェビナーを行い、「Measuring DesignOps’ Impact」のハイレベルな戦略について説明しました。

彼女は、”DesignOpsは、デザインに関わる非効率性を解消し、より生産性の高いデザイナーを生み出すことを目的としている”ため、DesignOpsリーダーはその効果を測らなければいけないと述べています。

DesignOpsの測定には、有効性効率性の違いを認識した上での問題の確定が必要です。

  • 有効性: 行動や仕事の進め方を測定し、定性的に結果を出す
  • 効率性:パフォーマンスや変化を測定するための定量的なデータを作成する

彼女は、3つのステップを経て改善点を洗い出します:

  1. ユーザーを特定し、問題を確定する。パトリツィアは、そのユーザーを【ビジネス】、【デザインリーダー】、【デザインチーム】に区分しています。問題が特定されたら、その問題が3つのユーザーセグメントにどのように影響するかの評価が必要です。
  2. 品質、コスト、時間で測定される重要な次元を確定する。効率にインパクトを与え、パフォーマンスを上げるには何ができますか?
  • 最後に、問題の規模を理解し、最善の行動方針の決定のために、定量化可能で定性的なデータを使用して問題を評価するプロセスという「インパクトを与えます」。

彼女の1時間に及ぶウェビナー「Measuring DesignOps’ Impact」、または要約記事「ROI of DesignOps: All You Need to Know About Quantifying DesignOps’ Impact」をぜひご覧ください。

エリカ・ライダー 氏 – Developer Tools and Platform Experience UXシニアマネージャ

エリカもまた、世界有数のハイテク企業での豊富な経験と素晴らしい経歴を持つベテランUXデザイナーです。現在はPayPalでDesignOpsの職務に就いています。

彼女はPayPalのDesignOps 2.0を担当し、UXPin Mergeを基盤として社内の製品デザインを拡張・最適化しました。5人のUXデザイナー、1000人以上のデベロッパー、60以上の製品を抱えるPayPalは、チームメンバーを増やすことなくMergeを使って新製品を8倍速く出荷できるようになったのです。

UXPin Mergeでは、PayPalの製品チームが新製品のデザイン、プロトタイプ作成、テスト、提供を担当し、小規模なUXデザイナーチームは、ハイレベルなユーザーエクスペリエンスに集中できるようになりました。

詳細については、彼女の1時間のウェビナー「Scale design efficiently with DesignOps2.0」、または「How PayPal Scaled Their Design Process with UXPin Merge」をご覧ください。

レイチェル・ポスマン氏  (Salesforce) – デザインオペレーション、シニアディレクター


レイチェルはCapital One、Uber、Salesforceなどの企業で、DesignOpsやResearchOpsのポジションで10年近くデザインの仕事に携わってきました。

彼女は、「DesignOps 101:Guide to Design Operations」の第2章を手掛け、DesignOpsの重要性について語っています。

「デザインオペレーションは、デザインチームが直面する課題の軽減をサポートするために存在します」:

  • デザインチームの時間に対する作業量と需要の増加
  • 単独での作業か、ワークフローまたは手順のサイロ化
  • デザインチームがよりスマートに働けるようにするためのデザインツールの欠落
  • プロジェクトの初期戦略から外れたことによる誤解
  • 早く作るためのスピードと効率の追求

Postcards from the Future (of DesignOps)』で、「現在の製品やサービスに対する未来の文脈やシナリオ」を思い描くための戦略を明らかにしています。

レイチェルは、Future Today Instituteのコーンに基づき、未来を4つのセグメントに分けています。

  • 戦術:12〜24ヶ月
  • 戦略的計画:2〜5年
  • ビジョン: 5〜10年
  • システムレベルの破壊と進化: 10年以上

レイチェルと彼女のチームは、未来について話し、未来を描くことで、未来の世界をつくるための戦略を立てることができることに気づきました。

レイチェルのプランニング戦略を実行するためのステップバイステップガイドは、「Postcards from the Future (of DesignOps) 」をぜひご覧ください。

また、無料の電子書籍「DesignOps 101: Guide to Design Operations」では、レイチェルをはじめとする6人のDesignOpsエキスパートから貴重な所見が得られます。

サロメ・モルタザヴィ氏 (SiriusXM) – DesignOps担当ディレクター

サロメは、フォーチュン500社に名を連ねる企業のコンサルティングに長年携わり、ソフトウェア開発手法の改革をサポートしてきました。現在は、SiriusXM社でDesignOpsのディレクターを務めています。

彼女は、成果を得るための手法やフレームワークである、プラクティス主導型のDesignOpsアプローチを採用しており、プロセスはプラクティスに従うため、前者を最適化すると、より非効率になることが多いと指摘しています。

サロメは、プラクティス主導型のDesignOpsリーダーに必要な4つの重要なスキルを定めています:

  • 曖昧さの受容:すべてをコントロールしようとせず、問題解決と最適な解決策を見出すプロセスを受け入れる
  • リサーチ&サービスデザインのスキル:リサーチとサービスデザインのツールを活用し、エコシステム全体の課題を可視化する
  • デザインおよびプロダクトプラクティスの強いバックグラウンド:チームメンバーとの効果的なコミュニケーションのために、DesignOpsリーダーには、製品に関する実践的な経験が必要であり、この経験によって、問題の特定と診断が容易になる
  • プログラム管理のスキル:長期的な成功には、ソリューションの進化・拡張の方法を知っていることが不可欠であり、フィードバックループの構築により、運用担当者はソリューションの改善と最適化のための学習と反復を繰り返すことができる

彼女のプラクティス主導型アプローチについては、このメディアの投稿をお読みください。また、UXPinのデザイン値会議での彼女の様子もご覧ください。

読んでいただきありがとうございます。

いくつもあるデザインツールをUXPin Mergeに一本化することで、デジタルプロダクトをより速くリリースしましょう。

無料デモ予約はこちらから

レスポンシブデザインガイド – 簡単な8ステップ

responsive design

このレスポンシブWebデザインガイドは、複数のビューポート幅に対応するデザインのプロセスを段階的に説明するものです。このプロセスをUXワークフローに組み込むことで、デザインチームがユーザーインターフェースをデザインする際に、さまざまな画面幅を考慮することが可能になります。

UXPinでデザインする場合、ウェブ、iOS、Android、カスタムキャンバスの各サイズから選択できます。無料トライアルにサインアップして、UXPinを使った色々なデバイス向けのデザインがいかに簡単であるかをご確認ください。

レスポンシブデザイン とは

レスポンシブデザインとは、複数のビューポートに対応するユーザーインターフェースをデザインするプロセスです。使用するデバイスに関係なく、一貫したユーザーエクスペリエンスの提供を目的としています。

従来、レスポンシブWebデザインは、携帯電話、タブレット、デスクトップという3つの主要スクリーンを考慮していましたが、現在ではスマートウォッチ、テレビ、車のダッシュボード、冷蔵庫など、デザイナーが手掛けるスクリーンやデバイスの数は増えています。また、製品によっては音声も含まれるため、デザインチームはVUI(音声ユーザーインターフェース)も取り入れなければなりません。

ステップ1: レスポンシブデザイン の理解

デザイナーは、レスポンシブUIのデザインを始める前に、レスポンシブデザインと、デベロッパーが製品に用いる技術の理解が必要です。

例えば、エンジニアはCSS(カスケーディングスタイルシート)を使ってユーザーの画面サイズに応じた画像を提供することもできますし、自動的に最適化するツールを使うこともできます。前者の場合、デザイナーは複数の画面サイズに対応したアセットを用意しなければなりませんが、後者の場合は1つで済みます。

responsive screens

そのため、デザイナーはプロジェクト始動前にエンジニアと相談し、以下のような質問をして、技術的な要求や制約を理解しておく必要があります:

  • 製品はレスポンシブグリッドかフルードグリッドを採用していますか?
  • 製品のブレイクポイントは?
  • オペレーティングシステム(Apple iOS、Android、Windows)は、製品のレイアウトに影響を与えますか?
  • エンジニアはどのように画像のスケーリングや配信をしていますか?
  • エンジニアが使用する動画や画像、アイコンなどのメディアはどのような形式ですか?
  • 製品はどのようなグリッドシステムを採用していますか?
  • 製品にFlexboxや通常のCSSが使われていますか?

レスポンシブ グリッドとフルードグリッド

レスポンシブグリッドは、ピクセルを使用した標準の12列グリッドシステムを使ってサイズ設定します。ピクセルの使用というのは、エンジニアがCSSメディアクエリでのみ変更されるコンポーネントまたはコンテナのサイズを設定するということです。フルードグリッドは、パーセンテージを使用し、利用可能なスペースに応じてUI要素のサイズを変更することができます。

ステップ2:ブレークポイントの確定

例えば複雑な機能の中には、モバイル版とデスクトップ版のアプリケーションでできることが制限されるものがあるように、ブレークポイントをリストアップすることで、デザイナーは、各デバイスに対応した情報アーキテクチャ、レイアウト、機能を計画することができます。

最も一般的なブレークポイントは以下の通りです:

  • デスクトップパソコン – 最大幅: 1200px
  • ノートパソコン – 最大幅: 991px
  • タブレット – 最小幅: 768px, 最大幅: 990px
  • スマートフォン – 最大幅: 500px

例えば、iPhone 13は390ピクセル×844ピクセルで、横長と縦長では幅が2倍以上違うといったように、デザイナーは、画面の向きやランドスケープレイアウトでのデザインの調整についても考慮が必要です。

ステップ3:コンテンツ優先のアプローチ

コンテンツを中心にレイアウトをデザインすることで、直感的で操作しやすいUIを構築でき、コンテンツの階層を確定することで、ブレークポイントに応じたレイアウトの整理が可能になります。

デザイナーは、ユーザーにやって欲しいアクションに関連する階層の考慮が必要です。例えば、ブログフィードの目的は、ユーザーに記事の一覧を表示し、興味のあるものをクリックしてもらうことであり、そのためには、記事のクリックを促す画像と見出しが最も重要な要素となります。

デスクトップフィードでは、記事の抜粋、公開日、著者、カテゴリータグなど、より多くの情報を含めるためのスペースがあり、ユーザー調査やインタビューは、ユーザーにとって何が最も重要であるかに応じて、レスポンシブデザインを導くことができます。

ステップ4:モバイル優先のデザイン

モバイル優先のデザインは、最小のスクリーンサイズから始めて、拡大していくプロセスですが、このデザイン戦略には、主に2つの利点があります:

mobile screens pencils prototyping
  1. 小さな画面という制約の中で、デザイナーは最も重要な機能とUIコンポーネントのみを搭載することを余儀なくされます。不要な機能を削減することで、コストと市場投入までの時間が短縮されます。
  2. モバイルレイアウト(小画面)を大画面に変換する方が、その逆よりも速くて簡単です。デスクトップ優先のデザインは、しばしばモバイル版へのスケールダウンのために妥協やデザインの変更を余儀なくされます。

モバイルファーストのアプローチは、ウェブデザインにおいてもビジネス的な意味を持ちます。例えば、Googleはモバイルフレンドリーなコンテンツを優先します。つまり、レスポンシブデザインはSEOに有利で、上位に表示され、より多くのクリックを生み出す可能性があります。

ステップ5: コンテンツの優先順位付け

モバイル優先とコンテンツ優先のアプローチの一環として、小さなデバイスで常に見えるコンテンツを優先し、ナビゲーションの引き出し、ドロップダウンメニュー、アコーディオンの後ろに隠すべきものを選択します。

例えば、デスクトップのレイアウトでは、デザイナーはFAQセクションの質問と回答をユーザーに表示することがよくありますが、このようなレイアウトでは、モバイル端末でユーザーが目的のものを見つける場合、すべてのQ&Aをスクロールしなければならないことになります。その代わりに、小さな画面に質問を表示し、答えをアコーディオンの後ろに隠すことで、モバイルユーザーのスクロールを減らすことができます。

ステップ6: レスポンシブ な画像と動画

プロジェクト始動時にメディアフォーマットを決めておくと、後々のデザイナーの手直しを省くことができます。例えば、デザイナーはアイコンにPNGを使うかもしれませんが、エンジニアはレスポンシブレイアウトに対応しやすく、パフォーマンスも高いSVGを使うかもしれません。

複雑なレスポンシブデザインでは、デバイスやビューポートに応じて異なるメディアを提供するのに、複数のサイズとフォーマットが必要になる場合があります。これらのフォーマットについて最初から合意しておくことで、デザイナーはプロトタイプを正しくテストし、よりスムーズなデザインのハンドオフのためのアセットの準備ができます。

ステップ7: レスポンシブ ・タイポグラフィ

タイポグラフィは、ブランド/アイデンティティ、読みやすさ、音声、読みやすさに影響を与える重要なデザイン要素です。デザイナーは何時間も何日も、あるいは何週間もかけて熟慮を重ね、複数のデバイスに対応する書体を選択します。

text typing input 1

A guide to responsive typographyでは、UXデザイナーのオーガスティン・トーマス氏が、レスポンシブ・タイポグラフィーのためにデザイナーが考慮しなければならないことを、以下のように挙げています:

  • 正しいタイポグラフィの選択
  • タイポグラフィーのスケールの選択
  • アライメントとスペーシング

画像、ビデオ、グラフィックなど、プロジェクトのコンテンツは、上の3要素に大きな影響を与えることから、正確な結果を得るには、ダミーテキストを避け、必ず実際のコンテンツで書体の組み合わせをテストしてください。

ステップ8:レスポンシブ デザイン・パフォーマンスの最適化

パフォーマンスはデベロッパーの仕事であることが多いのですが、デザイナーの負担を減らすためにできることがいくつかあります:

システムフォントの使用

iOSではSan Francisco、AndroidではRoboto、WindowsではSegoe UIが使用されています。このデフォルトフォントを使用することで、レスポンシブWebサイトやアプリケーションは追加のリクエストの必要がなく、パフォーマンスを向上させることができます。

美しさよりもパフォーマンスを優先する製品の場合は、カスタムフォントの代わりにシステムフォントを使用することを検討してください。すべてのオペレーティングシステムで一貫した結果を得るには、必ずそれぞれのフォントで製品をテストをしてください。

アニメーション

CSSやJavascriptのアニメーションは、パフォーマンスに影響を与え、ユーザーエクスペリエンスに悪影響を与える可能性があります。逆に、エンジニアが機能のロードに数秒を要する場合、デザイナーはアニメーションを使用することができます。この2つの適切なバランスを見つけるには、デザイナーとエンジニアの連携とテストが必要です。

まとめ

RWD(レスポンシブWebデザイン)と最適化は、デザイナーとエンジニアの連携に大きく左右されます。画像ベースのデザインツールを使用すると、デザイナーが正確に応答性をテストするのは不可能になります。

デザイナーは、いくつかのレスポンシブ要素を考慮し、コンテンツ、レイアウト、タイポグラフィー、その他のUI要素が複数のビューポートでどのように相互作用するかの考慮が必要です。

Mergeによる レスポンシブデザイン

uxpin merge component responsive 1

レスポンシブデザインの課題のひとつは、画像ベースのデザインツールの静的な性質により、デザイナーが複数のビューポートでUIやコンポーネントを正確にテストできないことです。

ウェブページの正確なテストには、デザイナーにはほとんど知られていないHTML、CSS、Javascriptを使うしかないのです。

UXPin Mergeはコードベースのデザインツールで、デザイナーはエンジニアが使用するのと同じコンポーネントを使用してプロトタイプとテストを行うことができます。また、エンジニアはレスポンシブ・プロパティをプログラムすることができるので、UI要素がプロトタイプでも最終製品と同じように機能します。

UXPin Mergeとは

UXPin Mergeは、製品のコンポーネントライブラリをUXPinのデザインエディタに同期させ、デザイナーが完全に機能するコードコンポーネントを使用してプロトタイプを作成できるようにするものです。

Git または Angular、Ember、Vue、およびその他のフロントエンド フレームワーク用の Storybook 統合を使って、React コンポーネント ライブラリを Merge に直接接続することができます。

Mergeを使用したレスポンシブコンポーネントの作成

Reactコンポーネントライブラリを用いて、エンジニアは、IFrameコンポーネントがレスポンシブプロパティ、メディアクエリ、スタイリングに反応するようにプログラムし、最終製品のコンポーネントと同じレスポンシブ機能を提供することができます。

UXPin Merge を使ってレスポンシブなコンポーネントを構築するためのステップバイステップのチュートリアルをご覧ください。

テストの強化

複数のフレームを使用する代わりに、単一のフレームとコンポーネントを使用して、コードと同じレスポンシブな機能の実現ができます。また、これらのUI要素は、最終製品と同じ忠実度と機能を持ち、デザイナーはユーザビリティテストやステークホルダーからの有意義なフィードバックが得られます。 Merge を使用すれば、デザイナーはコードを書いたり、エンジニアに頼ったりすることなく、コンポーネント ライブラリからきちんと機能する応答性の高い UI 要素を使用してプロトタイプやテストの作成ができます。

デザインハンドオフの効率化

これらのレスポンシブ Merge プロトタイプは、デザインのハンドオフの効率化を実現し、市場投入までの時間が短縮されます。エンジニアは、デザインをレスポンシブ コードに変換するための複数のモックアップやドキュメントの検査が必要なくなり、レポジトリからコンポーネントをコピーして貼り付け、UXPin から JSX の変更を行うだけで、ウェブ開発プロセスを開始することができます。

世界最先端のデザインツールで、レスポンシブプロトタイピングとテストを改善しましょう。無料トライアルにサインアップし、MUI 統合による UXPin Merge をお試しください。

UXPin Merge Controlでのプロパティ解析

Parsing Props for UXPin Merge Controls

  友人であるPaypalのアンソニー・ハンド氏に、UXPin Mergeでのプロップの解析でデザイナーの仕事が楽になる方法をシェアして頂けることになりました。

MergeはUXPinの革新的な技術で、デザインツールのコンポーネントライブラリからデベロッパーのUIコンポーネントをインポートして同期できます。コンポーネントは、Storybook 統合または Git レポジトリ経由で持ってくることができ、開発リソースが不足している場合は、Merge コンポネントマネージャーを使って、エンジニアの助けを借りずにコンポーネントのインポートおよび管理ができます。

デザインのプロセスで使うUI 要素がライブ コードであるため、完全にインタラクティブなプロトタイプの、極めて迅速なデザインが可能です。UXPin Merge へのアクセスをリクエストして、より良いデザインプロセスを構築しましょう。

UXPin Mergeでは、チームのニーズに合わせたエクスペリエンスの最適化ができます。これはまさに アンソニー・ハンド氏 が書いていることです。彼がどのようにスマートな解析を使って Merge のエクスペリエンスを彼のチームに合わせて調整したかをご覧ください。

AnthonyHand

UXPin Merge Controlのためのプロップパーサ

UIのデベロッパーなら誰でも知っているように、ユーザー入力の解析と検証は、科学的であり芸術的です。大抵のユーザーは大抵期待通りの値を入力するかもしれませんが、私たちは常に、エラー処理と同様に、少し優雅なマッサージや微調整の準備を常にしておかなくてはいけません。

私はPayPalのDevOpsチームのシニアUXデザイナーで、手掛けるプロジェクトはすべて社内のウェブベースツールです。2年前、次世代ウェブアプリのためにMicrosoft Fluent UIライブラリに決めた後、UIライブラリをUXPinのMergeテクノロジーを使ってインポートするプロセスに乗り出しました。このプロセスはとても簡単でしたが、少し学習が必要でした。

uxpin merge react sync library git

UXPin Merge で、標準的な構文解析と検証の適用が必要だということを最初に学びました。UXPin のプロパティパネルは、結局のところ、たとえば私たちがいくつか開発した、色や日付のような基本的なユーザー入力のための標準的な解析ユーティリティのような、単なる凝ったユーザー入力フォームにすぎません。

UXPin Merge の準備を進めるにつれ、より複雑な UI コントロールには、基盤となるコントロールに複雑な JSON が必要であることにすぐに気づきましたが、UXPinで技術者でない人に生のJSONを表面化させると、ユーザーの採用率がすぐに低下してしまいます。

JSONは文字列で表現される複雑なデータモデルで、人間ではなくコンピュータのために作られたものです。その結果、プレーンテキストのユーザー入力を収集して、ドロップダウン、ナビゲーションリスト、データテーブルなどの複雑なUIコントロールを構成できる高度な多目的パーサの作成が、私たちの最も重要なイノベーションの一つでした。

基本的な解析

日付数字などの一般的なユーザー入力の検証を処理するために、JavaScriptで基本的なパーサ関数をいくつか作成しました。これは主にUXPinでUIコントロールを簡単に設定するために作成されましたが、こういったユーティリティの一部は、内部で広く使われています。

パーサは文字列 「50」 を整数に変換し、16 進数の色を検証し、必要な # マークを追加して戻します。Merge ラッパーはアイコン名の先頭と末尾の空白を切り落としました。(UXPin Editor と Props Panel のビュー)

詳細:色の解析とフォーマット

Microsoft Fluent UI コントロールは、【#0078d4】(美しい青色)のような 16 進値を必要としますが、私たちは、【themePrimary】など、ユーザーが 16 進値と覚えやすいテーマ・トークンの両方を使用できるようにしたいと思いました。さらに、【success】などのセマンティックトークンと、【white】や【transparent】などの一握りの基本色もサポートしたいと考えました。エラー処理に関しては、入力テキストから空白を取り除き、たとえ#マークで始まらなくても有効な16進数値を受け入れるようにしました。

私たちのカスタムカラーパーサは、ユーザーに大きな自由度を与え、この種の値をすべて受け入れ、UIコントロールでの使用に有効な16進数値か、エラーフラグとして「未確定」のどちらかを返します。

カラーパーサは 【themePrimary】がテーマのカラートークンであるかどうかをチェックし、その 16 進値を取り出してアイコンオブジェクトで使用しました。

同様に、カラーパーサは特別なセマンティックカラートークンである【success】を調べ、同様に16進数に変換しました。【success 】は任意の16進数値よりも覚えやすいのです。

複雑な解析

前述のように、メニュー、ナビ、ドロップダウンなど、基盤となるUIコントロールの多くは、設定に複雑なJSONを使用していますが、JSONは人間にとって読みづらく、壊れやすいものです。そこで私たちは、JSONの代わりに、人間が使いやすい革新的な構文を考案しました。平文に加え、私たちが開発した構文トークンには、以下のようなものがあります:

  • icon(Icon_Name|色): マイクロソフトのアイコンライブラリにある任意のアイコン
  • link(表示文字列|URL)
  • Dividerまたは–。リストに仕切りの表示
  • * : ナビやメニューのようなセクションの子マークを付ける場合
  • CSVのパース:テーブルの行や、特定のコントロールで平文にカンマが必要な場合など

: ほとんどの場合、この特別な構文は、デザイナーや(一般的に)技術者でない人が簡単にプロトタイプを構築できるように、UXPin内で使用するためだけのものです。実際のWebアプリの構築には、デベロッパーがJSONやイベント処理などを使用して、これらのUIコントロールを標準的な方法で設定します。

ケーススタディ:メニューのアイコンとテキスト

UXPinのCommandButtonコントロールにユーザーがポップアップメニュー項目を追加する方法を見てみましょう。この例では、ユーザーが【New】というテキストを含むボタンをクリックすると、さまざまなファイルタイプ、フォルダ、ユーザーなど、ユーザーが追加できるオブジェクトの種類のポップアップ リストが表示されます。

UXPin エディタでは、ユーザーはメニューアイテムのプロップをクリックして、大きなテキストエディターを表示します。改良されたパーサは、「File」 のような文字列が通常のメニュー項目であるか、セクションの見出しであるかを判断するために、先読みするようになりました。星印( * )は、「Document」 が子であることを示しますので、「File」 はセクションの見出しである必要があります。icon() トークンの使い方と、区切り文字を示す2つの直感的な方法に注目してください。

この強力で革新的な構文は、リスト形式のビューをサポートする、他の1ダース近くのUIコントロールに再利用されました。プルダウン、コンボボックス、ピボット(タブストリップ)、ナビゲーション、チョイスグループ(ラジオボタン)、グループボタン、スプリットボタン、パンくずリスト、その他多数です。

アイコンや仕切り、グループのサポートはコントロールによって異なりますが、UXPinユーザーがこの基本的なアプローチに慣れると、JSONの知識がなくても、大量のコントロールに同じアプローチを簡単に適用して、豊富でインタラクティブなプロトタイプの作成ができるようになります。

ケーススタディ:データテーブル

ご想像のとおり、社内のWebアプリケーションはデータ集約型で、データ テーブルは極めて一般的です。そのため、この高度な解析エンジンを開発した主な理由の1つは、プロトタイプで現実的な(そして適度に機能する)データテーブルを簡単に作成できるようにすることでした。

それなりに高度な機能を持つ豊富なプロトタイプの作成のためには、私たちのワークフローはExcelから始まります。まず、Excelでビューのモデルを作成し、各セル内で前述のlink()icon()構文を使用します。そして、そのワークシートをCSVファイルとしてエクスポートします。任意のテキスト エディタを使って CSV ファイルを開き、ヘッダーまたは行のデータのみを UXPin の 「ヘッダー および 行」プロップにそれぞれコピーできます。この合理的なワークフローを、他のプロトタイピングツールのテーブル作成に行っていたことと比べてみてください。

UXPin エディタ の DetailsList の 「行」 プロパティに、カンマ区切りのセル (CSV 形式) と革新的な link() icon() 構文が表示されます。

デザイナー目線での解析

パーサのソースコードに目を通すと、コードのデザイン上の決定や、(比較的)非効率的なコード、くどいコードについて、何らかの意見をお持ちかもしれません。また、いくつかのエラーにお気づきになるかもしれません。その決定については、私が責任を負います。

私はUXデザイナーであり、プロのプログラマーではないことを心に留めておいてください。さらに重要なのは、私のJavaScriptの知識が限られているため、効率性よりも読みやすさ、モジュール性、メンテナンスのしやすさを重視することを明確に決めたことです。これはオープンソースのコードなので、コードの一部または全部を借りたり、修正を加えたり、アップデートやバグフィックスを提供することは歓迎されます。

UXPin Mergeの最適化について

UXPinのMergeテクノロジーは、どの企業でも開発で使用しているものと全く同じUIコンポーネントライブラリをUXPinにインポートし、チームの誰もが豊富でインタラクティブなプロトタイプを作成できるようにするものです。ユーザーフィードバックやステークホルダーのレビューのためのデザインの、速度の劇的な向上や、デベロッパーのハンドオフの改善ができる強力な技術です。

logo uxpin merge

しかし、うちのチームが学んだように、UXPinで成功するためには、エンドユーザーエクスペリエンスの設定に適度な投資が必要なのです。私たちは、エラーを最小限に抑えながら最大限の力を発揮するスマートな解析によって、UXPinのユーザーエクスペリエンスを最適化するという明確な決定を下しました。

この度、独自のMicrosoft Fluent UIライブラリをオープンソースライブラリに移しました。このライブラリを使用して、チームで色々と試してインスピレーションを得てください。 また、自身のUXPin Mergeプロジェクト用に、パーサを自由にご利用ください!

プロトタイプを作成してビジネスを成功させるには

How to create a product prototype and set your business for success

お金を払って利用するサービスに対して消費者がますます厳しい要求をするようになっていることは、周知の事実です。実際、マイクロソフトの最近の調査によると、回答者の55%が前年よりも良いCXを期待していることが明らかになっています。また、34歳以下の顧客については、さらに高い数値を示しており、70%に達しています。

では、「より良い顧客体験」を作るとは、本当はどういうことでしょうか。ユーザーのニーズに合わせて製品を作ることが重要であり、たった一度のよくない経験で、ユーザーは競合他社に寝返ってしまうかもしれないのです。

このようなペースに遅れをとることなく注目の製品を開発するには、製品のプロトタイピングへの取り組みが不可欠です。

本記事では、「プロトタイプとは何か」、「なぜプロトタイプがビジネスに不可欠なのか」、「どのように始めればいいのか」についてお答えします。

では始めましょう!

プロトタイプとは

自分の頭の中で考えていることがなかなか人に伝わりにくかったことはありませんか?そうだとしたら、自分のビジョンを他の人に見てもらえず理解してもらえないのが、どれほどもどかしいかおわかりいただけるでしょう。そんな時は、プロトタイプをデザインして、アイデアを形にするのが一番です。

プロトタイプは、最終製品のサンプルバージョンであり、マーケットの潜在的な可能性を評価するのに役立ちます。これは、MVP(Minimum Viable Product)開発に取り組む前の良い出発点となります。プロトタイプは物理的な製品とデジタル製品の両方で作成できますが、この記事ではデジタルのみに焦点を当てます。

構築できるプロトタイプの種類は主に2つのタイプがあります:

  • Lo-Fi(低忠実度)プロトタイプ

Lo-Fiプロトタイプは、デジタルでも手描きでも作成できるシンプルなワイヤーフレームで、詳細や色彩がないため、紙とペンがあればすぐに始められます。Lo-Fiタイプとも呼ばれ、決済やウィッシュリストへのアイテム追加など、基本的な機能やユーザーフロー全体を視覚化するのに適しています。

このようなプロトタイプは、迅速なテストに最適で、デザイナーが一つのビジョンにコミットする前に、フィードバックを集めて製品について議論できるようになります。

  • Hi-Fi(高忠実度)プロトタイプ

高忠実度プロトタイプは、デザイナーがあなたのビジョンを忠実に再現したモックアップの作成ができます。Lo-Fiデザインよりもコストがかかりますが、Hi-Fiプロトタイプはカラフルで魅力的であり、リンクやCTAボタンなどのインタラクティブな要素も含まれています。また、正確な機能により、ユーザーやステークホルダーから、より多くの実用的なデータが得られます。

製品プロトタイプを作るべき4つの理由

ここで、プロトタイプ開発がもたらすメリットについて、少し見てみましょう:

1. PMF(プロダクト・マーケット・フィット)の探求

プロトタイプは、ユーザーのニーズを満たさないもののデザインに無駄な時間と費用を費やすことなく、製品の実現可能性を評価することができます。急いで発売するのではなく、プロトタイプを使うことで、一旦立ち止まって、状況を把握し、市場がどのように反応するかを調べることができます。そして、デザインを練り直し、未来を見据えた製品開発に投資することができるのです。

2. ユーザーへの付加価値提供

プロトタイプはユーザーありきであり、ユーザーにとってより良い製品を作るためのものですから(じゃないと使う理由がないですよね?)、デザインは徹底的なユーザーテストにかけられるべきです。ユーザーがどんな人なのか、何を求めているのかを理解せずに、ユーザーを満足させ、かけがえのない経験を与えるといった付加価値は付けられません。あなたが受け取るフィードバックの一つひとつは、それらに正面から向き合うためにどこを改良すべきかを教えてくれるデータなのです。

3. 投資家を惹きつける

新製品のための投資が必要だったら、プロトタイプはその資金確保に不可欠です。投資家は、あなたのデザインの実用版を見たいと思うでしょう。プロトタイプで、企業の主要なステークホルダーから賛同を得るのと同様に、投資家が最終製品をよりよくイメージしやすくなり、はるかに魅力的な製品になります。

4. デザインの絞り込み 

フィーチャークリープ(あるいはミッションクリープ)は本格的であり、コストがかかります。デザインを始めると、あっという間にアイデアに夢中になってしまいますが、プロトタイプを作成すれば、これらの追加機能に対するユーザーの反応や、投資する価値があるかどうかをすぐに判断することができます。ということはつまり、最高のユーザー体験の妨げになるものはすべて削ぎ落とされていかないといけないのです。

プロトタイプ開発に効果的にアプローチするためのヒント

さて、プロトタイプ開発を成功させるにはどうすればいいと思いますか。ここでは、そのヒントをいくつかご紹介します。

初期要求の合意

あなたとあなたのチームが最初に土台を築く時の目標は、アイデアの具体化に必要なものの決定です。MVP開発の下準備は、他のビジネスプロジェクトと同じように扱ってください。

チームと必要なスキルを決めましょう。必要なツールは?従うべき会社のガイドラインはありますか?どのようなインターフェースの設定がありますか?

基本的に、あなたは準備の準備をしているのです。何をするかははっきりしないかもしれませんが、この段階が終わるころには、着手に何が必要か分かるはずです。

何を達成したいかの把握

アイデアの革新、課題の克服、機能強化の実現、すべてプロトタイピングに取り組む大きな理由です。あなたはどんな理由ですか?

あなたの製品で問題を解決するには、以下の特定が必要です:

  • 製品プロトタイプの明確な目的:目標はデータ駆動型であり、より広いビジネス目標に沿ったものであるべき
  • 誰のためのものなのか:ユーザーかステークホルダーか、あるいはその両方か
  • 成功(および失敗)とはどのようなものか
  • 何をテストするのか 
  • フィードバックの収集方法

次に、このビジョンを伝えなければいけません。プロトタイプはデザインツールであると同時にコミュニケーションツールでもあり、目的を明確にすることで効率が上がります。つまり、チーム全員が自分たちに何が求められているかを理解しているため、作業が重複したり、当初のビジョンに合わせるべく延々と修正したりすることがないのです。可能な限り、主要なステークホルダーを会話や計画段階の早い段階で引き込みましょう。そうすることで、社内の賛同を得やすくなり、反対意見を最小限に抑えることができます。

目的が明確であれば、優先順位を見極め、それを実現できます。

これをプロジェクトマネジメントの三角形でイメージするとよいでしょう。「耐久性」「機能性」「美観」を各ポイントに置いてみましょう。

  • プロトタイプにライブデータ、リアルタイムの更新、ワークフロー、コーディングが必要な場合は、【耐久性】を優先しましょう
  • プロトタイプが新規または改良された機能とその動作に焦点を当てたものである場合、【機能性】を優先しましょう
  • プロトタイプの外観が美しく、ブランディングのガイドラインに適合していなければならない場合は、【美観】を優先しましょう

ここまでくればもうお分かりですね?では、その三角形のどこかに、プロジェクトに不可欠なものに一番近い星をつけることを想像してみてください。その星があなたの優先順位です。

ランディングページデザインを想像してみましょう。その際、最優先されるのは【美観】と【機能性】でしょうが、すべての機能性に対応したことを確認後、より多くのリソースを美観に集中させることになるでしょう。

プロジェクトマネジメントの三角形をガイドに、プロトタイプを始めるベストな方法が見つかるのです。

ワイヤーフレームについて覚えておく

ワイヤーフレームは、デザインプロセスの中核となる部分です。ワイヤーフレームの作成は、ついつい急いでしまいがちであり、ゴールが決まれば、すぐにでもプロトタイプを作りたくなるものです。それはとてもワクワクする瞬間ですが、プロトタイプの作成は、ブレーキをかけることでもあります。どの段階でも、「これは自社の製品にふさわしいか」と問いかけてください。

ワイヤーフレームはさっと作成でき、頭の中で考えているよりもずっとビジネス的な使い方ができます。デザイン推敲のためのガイドとして使用したり、時間を無駄にする前に実行不可能なコンセプトを捨てたりすることができますが、ワイヤーフレームの作成に時間をかけることで、製品開発プロセスのパフォーマンスと効率は向上します。

フィードバックの収集

先にもお話したように、プロトタイピングはユーザーありきです。ユーザーの本音を知ることで、最高の製品のデザインができるのです。正直は最良の政策ですが、傷つく(そして発売が遅れる)かもしれませんが、ユーザーのニーズを満たさない製品を展開するよりも、潜在的なユーザーの手に渡って痛手を負い、そのフィードバックに基づいて行動する方がよいでしょう。

必ず実用的な見解を得るための質問をしてください。ユーザーからのフィードバックを元に、さらに発展させることができる部分を探しましょう。より多くのデータが集まるほど、最終製品はより強力になります。フィードバックの収集法には、以下のようなものがあります:

フォーカスグループ

ユーザーを集めた、オープンな場での彼らの経験についての話し合いです。フォーカス・グループでの会話は、他の方法では語られなかったかもしれない回答を促すことがよくありますが、参加者を慎重に選ぶことが重要です。理想的なのは、全体像を把握するために、ユーザーの多様な面を使うことです。

アンケート

Survey MonkeyTypeformのようなプラットフォームで、簡単なアンケートを作成してバックエンドでデータを集め、集めたすべてのフィードバックを把握できますが、回答を得るのが最難関の一つです。そこは電子メールやSNSのチャンネルを利用しましょう。アンケートは使い慣れたフォーマットで短めに作成し、テスト終了後にアンケートを送るようユーザーに伝え、返信のないユーザーにはフォローアップを行いましょう。回答率を上げるのにインセンティブを使うのもありです!

電話インタビュー

製品についてのユーザーの話を聞いたり、彼らが使う言葉を聞いたりすることは、ユーザーに関する貴重なインサイトを与えてくれますが、電話で連絡を取るのは簡単なことではありません。まず最初に、試作品について電話で話したいことを予告して、メッセージでチェックインします。その際、予め質問を用意しておくのもいいですが、実際に会話をすることで見えてくることもあるので、そこは臨機応変に対応しましょう。

正しいツールの使用

正しいツールの選択は重要です。誰だって、期待していた性能を発揮しなかったり、ましてや何の役にも立たないようなソフトウェアへの投資などしたくありあませんからね。

UXPin Mergeのようなツールは、コラボレーションと効率化を促すことで、プロトタイピングプロセスを改善することができます。UXPin Mergeをデザインと開発の間のリンクとして考えてみてください。デザイナーは、デベロッパーが製品の構築のために使うのと同じ、完全にインタラクティブな「ライブコード」コンポーネントを使ってプロトタイプを構築します。

そうすることでアイデア実装が一致して、見たとおりのものができあがるのです。「同じ言葉で話す」ことで、プロジェクトでの連携がずっと簡単になります。

効率性の向上とプロセスの合理化を重視する場合、Mergeでプロダクション コードに基づくインタラクティブな要素でプロトタイプを作成し、製品開発プロセスをスピードアップできます。

さらに、UXPin Mergeはプロトタイプをよりインタラクティブにし、エンドプロダクトとの一貫性を持たせることで、ユーザーテストが改善され、より信頼性の高いデータが得られます。

チームおよびチームを交えての定例会議の開催

プロジェクトを軌道に乗せるのは簡単なことではありません。そのため、全員が目的をきちんと理解し、同じ目標に向かっていることを確認する機会として、チーム内やチームを交えてのミーティングをするといいでしょう。

これは、実際にプロトタイプの開発に携わる者にとって特に重要なことですが、デザイナーとデベロッパーを定期的に集めましょう。もしあなたのチームがすでにMergeのようなツールを使っているなら、デベロッパーがすでに準備したコンポーネントをデザイナーが作業することで、彼らの会話はより簡単で関連性が高くなるでしょう。

MVPの修正にフィードバックを適用する

プロトタイプがユーザーテストを通過したら、次はそのインサイトを実行に移す番です。製品に有益なフィードバックを集めることこそが、プロトタイピングの本質なのです。

フィードバックを検討し、次のステップを決定する際には、これらの修正が全体の目的にどのように合致しているかの考慮が必要です。プロジェクトのタイムラインに影響を与えていませんか?新しい機能が必要ですか?

再度プロトタイプを行った後、新しいバージョンをテストします。このとき、前回と同じユーザーを使うことを忘れないでください。このステップでは、ユーザーにとってなくてはならない製品になるまで、改良、改良、改良の繰り返しです。

まとめ

あなたのアイデアをユーザーにとって目が離せないものにしたかったら、プロトタイプは欠かせません。プロトタイプの開発段階では、ターゲットユーザーをデザインの中心に据え、データに基づく計画と準備に重点を置きます。プロトタイプ開発プロセスをスピードアップし、デザイナーとデベロッパーの連携を円滑にするツールをお探しでしたら、UXPin Mergeをぜひチェックしてみてください。

 

デザイナーとデベロッパーのためのより良いエクスペリエンスを創造するには?

Design handoff

デザインハンドオフは、どんなプロジェクトにも不可欠な部分です。どちらかのチームが何かを見逃すと、製品の欠陥や遅れにつながる可能性があることから、多くのデザイナーやエンジニアにとってデザインの引き継ぎは、ストレスのたまる作業です。

プロトタイプやアセット、ドキュメントの制作は主にUXチームが担当しますが、デザインハンドオフプロセスは、デザインの初期段階から共同作業で行われます。

デザインハンドオフを成功させるには、3つの段階があります。

  • ハンドオフ前(デザイン中)
  • ハンドオフ時
  • ハンドオフ後

UXPinは、デザインと開発の間のギャップを埋めるコラボレーションデザインツールです。デザインチームは、UXPinの自動化されたデザインスペック、CSS、スタイルガイドによりドキュメント作成の時間の短縮を実現でき、スペックモード機能でハンドオフの効率化や、Mergeテクノロジーでコードコンポーネントのパワーをデザインに活用することもできます。

ハンドオフ前(デザイン中)

デザインハンドオフは、デジタル製品のデザイン・開発における1つの出来事ではなく、むしろ、デザインの初期段階から始まり、デザイナーが最終製品を完成させた後に終了するプロセスです。

デザイナーとエンジニアは、デザインハンドオフプロセスを合理化し、コストのかかるエラーを軽減するために、連携・連絡が必須です。

発見

競争優位を築くにはイノベーションが不可欠ですが、デザイナーは会社のリソースと技術的制約の中で仕事をしなければならないことから、デザイナーとエンジニアは、デザインアイデアに関する技術的な制約について初期の段階で話し合うべきです。

開発チームの代表者は、ユーザー調査に参加して、デザイン決定の背景にある「なぜ」を学ぶ必要があり、そうすることで、デベロッパーはユーザーのニーズとUXデザイナーが解決しようとしている問題をより理解できるようになります。

企画

デベロッパーをデザインスプリントに参加させることも、技術とデザインを一致させる方法の一つです。デベロッパーは、スプリント中にデザイナーと協力して、技術的な制約に沿ったユーザーの問題に対する解決策を見つけることができます。

同時に、デベロッパーは新しい機能を作るのに必要なツールやパッケージを調べるために、メモ取りを始めることができます。

プロトタイプ

デベロッパーはプロトタイプの段階で、異なるブラウザ、デバイス、ビューポートでのデザインの見え方や機能など、貴重なフィードバックやインサイトを提供できます。

プロトタイプの段階でデベロッパーにデザインや機能について終了してもらうことで、最終的なデザインハンドオフにかかる時間とストレスを大幅に軽減できます。UXチームのビジョンと技術的な現実が一致しないために、「振り出しに戻る」ことほどつらいことはありませんからね。

また、開発チームの担当者が後期のユーザビリティテストに参加し、ユーザーが最終製品をどのように操作しているかを可視化するのも有効です。

ユーザーインターフェースデザイン

デジタル製品にとって、よく文書化されたデザインシステムは欠かせない要素です。コンポーネントベースのデザインシステムを構築することで、エンジニアは再利用可能な「ウィジェット」をコード化し、最終製品を効率的に開発できます。

デザイナーとデベロッパーが協力することで、デザインシステムの一貫性が確保され、サイズの規約を効果的にコードに反映させることができます。

また、デベロッパーはアセットのフォーマットやサイズに関する技術的な仕様を提供できるため、UXチームは製品やウェブの制約に合わせてコンテンツを最適化することができます。

ハンドオフ時

デザインプロセスにおいて、デザインチームと開発チームが効率よく連絡・連携すれば、ハンドオフはダブルチェックと整理調整を行うスムーズなプロセスとなるはずです。

デザイナーがデザインハンドオフをどのように見せるかは、ドキュメントやファイル、アセットそのものと同じくらい重要です

まずUXチームは、混乱を避けるために、使用されていないレイヤーとガイドの削除が必要です。また、コンポーネントを正しくグループ化し、ラベル付けしていることの再確認が必要です。

BEM表記などの一貫した命名規則を使うことで、デベロッパーはファイル、アセット、コンポーネント、エレメントをぱっと見つけることができるようになります。そしてエンジニアは、効率的な開発ワークフローに沿った推奨ファイル構造についてアドバイスをくれる場合もあります。

デベロッパーがモックアップやインタラクティブなプロトタイプを理解するには、コンテキストの提供や、デザインツールの能力を超えている可能性のある機能の説明といった、はっきりと明示されたアノテーションが不可欠です。

最後に、デザイナーは、デベロッパーが包括的なデザインハンドオフを受けられるように、ドキュメントを一通りチェックする必要があります。

ハンドオフ後

UXチームは、インタラクティブなプロトタイプやモックアップに対して最終製品をテストする、実装の品質保証(QA)において重要な役割を担っています。

最終製品が完成したら、デザイナーとエンジニアは、今後の製品や機能のためのデザインハンドオフプロセスを改善するための話し合いが必要になります。

デザインハンドオフチェックリスト47項目

以下の47項目のチェックリストは、次回のデザインハンドオフのためのガイドとして作成されたものです。

ハンドオフ前(デザイン中)

発見:

  • 可能であれば、デベロッパーをユーザーインタビューに呼ぶ
  • ユーザーインタビューから得たインサイトを箇条書きにしてデベロッパーにまわす
  • 30分から1時間のステークホルダーインタビューを少なくとも1人のデベロッパーと実施する。キム・グッドウィン氏の素晴らしい質問を使う
  • デベロッパーとともに無駄のないペルソナを作成し、さっとレビューする
  • デザインブリーフの技術的制約について、デベロッパーの意見を聞いて調整する

企画:

  • デベロッパー(または最低でも開発リーダー)がキックオフに必ず参加するようにする
  • デベロッパーとともにユーザーストーリーマッピングを行い、エピックとスプリントを計画する
  • プランニングポーカーなどの手法で、デベロッパーとともにユーザーストーリーの構築時間を見積もる
  • 開発プロセスの1、2個先のデザインスプリントまで計画する
  • デザインに使うフレームワーク(ブートストラップ、ファンデーション、カスタムなど)を確認し、それに応じてグリッドやエレメントを調整する
  • ブラウザの対応状況をデベロッパーに確認する 
  • 各スタンドアップミーティングの後、デベロッパーとバックログをすぐ見直す

プロトタイプ:

  • ユーザーフローとLo−Fiプロトタイプをひと通りチェックして、デベロッパーから実現可能性に関するフィードバックを得る
  • コンテンツの正確な「ブラケット」のために、極端なビューポート(最小と最大)のデザインを始める。想定より少し小さい、または大きい画面サイズに対して、デザインがどのように反応するかを検討する。
  • 最初の2回のイテレーションで、プロトタイプにLorem Ipsumではないラフなコンテンツを組み入れる。
  • 最低1回のユーザーテストに参加するようデベロッパーを呼ぶ  
  • プロトタイプがすべての相互作用状態、エラー状態、およびステート間の遷移を説明している
  • プロトタイプが、短い/長い名字、電話番号の形式、米国以外の郵便番号などの極端なデータを考慮している
  • ユーザーテストの記録はすべて、インサイトの箇条書きの要約とともにデベロッパーにまわす 
  • プロトタイプのイテレーションごとに、デベロッパーからのフィードバックと承認を集める

UIデザイン:

  • 繰り返しのたびに、v.1、v.2、などにデザインファイルの名前を変更する。ただし、「最新版」や 「New 」は名前の変更をせず、新バージョンはすべて共有レポジトリにアップロードする
  • メニュー、リンク、ボタン、パネルなどの再利用可能なパターンをできるだけ多く作成し、デベロッパーがコンポーネントベースのシステムを持てるようにする
  • ユーザーエクスペリエンスとコードベースの一貫性を生み出すUIの決定を行う
  • 画像フォーマットとサイズに関するデベロッパーの賛同を得る  
  • ガイド/オーバーレイを使ったグリッドシステムで、すべての重要なブレイクポイントにデザインを作成する
  • タイポグラフィの整合性を保つため、例えば15.75ではなく15のように、フォント全体の値およびリーディングの値を使う
  • 可能な限りウェブセーフフォントを使用し、カスタムフォントは複数使わない 
  • すべての写真とタイポグラフィの権利を所有していることを確認する
  • 最終的に承認されたモックアップをプロトタイプと一緒に30分から1時間程度レビューする:プロジェクトの目標、ユーザーストーリー、インタラクション、ステート、失敗の状態をひと通り確認する

ハンドオフ中

視覚衛生:

  • 使わないレイヤーをすべて「削除」する。デベロッパーを混乱させる可能性があるため、ただ隠すだけでなく削除する
  • 未使用のガイドをすべて削除する  
  • ナビゲーション、フッターなどのUIモジュールに基づき、レイヤーを適切にグループ化し、名前を付ける
  • 例えば、「ウィジェット」と「モジュール」は同じではないというように、デベロッパーと共通の命名規則に従う。BEM記法の使用を検討する。
  • アートボードに「FINAL」や「LATEST」といった名前を付けるのではなく、v.1、v.2などの標準的なバージョン管理プロトコルに従う
  • ナビゲーションをしやすくするために、デザインの送信前にすべてのレイヤーを折りたたむ

アセット:

  • メインプロジェクト内にサブフォルダを作成し、関連するアイコン、フォント、画像をすべて格納する
  • 可能な限りSVGを含める。ラスターファイルの場合、2倍速のバージョンを含める

ドキュメント作成:

  • プロトタイプにユースケース、障害状態、インタラクションのニュアンスなどの注釈を付ける
  • 各要素の横に、完全なコードスニペット(フレームワークではクラス)を注釈として記述する
  • 検査ツールを使って、カラーコード、寸法、フォントサイズ、マージン、パディングなどの視覚的な仕様を自動生成する。朱入れはできるだけ避ける。
  • すべてのドキュメントが、最終的なシステムの進化を反映するように更新されるようにする。デベロッパーは、最終プロトタイプを許容される動作の参考として、システムの深さと広さを理解するためにドキュメントを参照する

ハンドオフ後

ビルドの精度:

  • デザイナーは、最終プロトタイプに対するQAプロセスで、各ビルドの「実装監査」を実施する
  • デザイナーはPMと一緒にスプリントデモに参加する
  • 受入テストには、最終プロトタイプに基づくUXの基準が含まれる

デザインシステム:

  • アクセシビリティの要件と、開発プロセスへの影響について説明する。(例:Salesforce Lightning:「当社のフォームは、<fieldset>タグと<legend>タグの適切な使用と、入力コントロールの適切なラベリングを提供します。」)
  • メニュー、ボタンなどのすべてのUIコンポーネントのコードスニペットと、ユースケースの具体的な説明を含める
  • ダウンロード可能なUIキット、色見本、Githubなどのコードレポジトリへのリンクを掲載する

UXPinによるデザインハンドオフ

UXPinで多くの日常的なタスクが自動化されると、デザインハンドオフ時のUXチームの貴重な時間の節約になります。他のデザインツールとは異なり、UXPinは、ハンドオフドキュメントやアノテーションの作成のためのプラグインやサードパーティアプリケーションは必要ありません。

UXPinはツール内でデザイン仕様を生成するため、外部のドキュメントを必要とせず、誤解を回避することができます。デベロッパーはUXPinのスタイルガイドから直接アセットをダウンロードすることができ、DropboxやGoogle Driveのようなクラウドストレージでの共有は必要ありません。

デザイン、開発、プロダクトの各チームは、UXPinのコメントを使ってデザインハンドオフプロセスを通じての連携ができ、チームメンバーは互いにタグ付けし、タスクを割り当て、コメントをチームまたは一般公開のどちらで表示するかを選択できます。

デザインハンドオフを次のレベルに進め、製品のズレをなくしたいなら、Mergeテクノロジーはまさにピッタリでしょう。デザイナーは完全にインタラクティブなコンポーネントでプロトタイプを作成し、デベロッパーはそれを使って最終製品を作ることができます。デザイナーとデベロッパーが、レポジトリやStorybookに保存されている同じコード化されたデザインシステムから同じコンポーネントを使用するおかげで、同じページにいることができ、デザインハンドオフプロセスで出てくるすべてのエラーを回避することができるのです。

製品のズレを排除し、デザインシステムを最大限に活用するUXPin Merge の仕組みをぜひご覧ください。