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

コンポーネント駆動型のプロトタイプは、UXデザインの次なるイテレーションです。デザイナーはもはやゼロからデザインすることはなく、エンジニアが書くコードはより少なくなっています。  

これによってもたらされることは、機能横断的な連携の強化、市場投入までの時間短縮、一貫性、エラーの減少、より良いテスト、ステークホルダーからの有意義なフィードバック、そしてスムーズなデザインのハンドオフが実現します。  

UXPin Mergeを使うことで、これらのメリットがすべて実現可能です。詳しくはこちらのページをご覧ください。  

 コンポーネント駆動型 プロトタイプとは

  コンポーネント駆動型のプロトタイプは、デザイナーが既製のUI（ユーザーインターフェース）要素を使ってUIを構築する製品デザイン手法の１つです。ゼロからデザインするのではなく、インタラクティブなコンポーネントをドラッグ＆ドロップしてプロトタイプを作成します。  

このデザイン手法は、フロントエンドエンジニアがゼロからコーディングするのではなく、既存のコンポーネントライブラリを使ってUIを構築するコンポーネント駆動開発に由来するものです。  

Storybookはこの開発方法でよく使用されるツールであり、エンジニアはコンポーネントを分離して構築・管理することができます。

コンポーネント駆動型プロトタイプも同様に、ゼロからデザインするのではなく、オープンソースのUIライブラリや製品のデザインシステムを使って、既製のコンポーネントでUI構築に集中することができます。  

コンポーネントは通常、色、タイポグラフィー、サイズ、スタイルなどの定められたプロパティで完全にインタラクティブであり、それによってデザイナーはプロトタイプ作成、テスト、イテレーション、デザインプロジェクトの提供をより速く、より正確に行えるようになります。  

 コンポーネント駆動型プロトタイプ の手法

  コンポーネント駆動型のプロトタイプはコンポーネント駆動開発からヒントを得たものですが、ブラッド・フロント氏のアトミックデザイン原則がデザイン手法の基礎となります。  

アトミックデザインにおいては、UI構築の際に最小のUI要素から始めて徐々に規模を拡大していく段階的な取り組み方法を採用しています。ゼロからデザインするのではなく、要素を組み合わせ、より大きなコンポーネントやテンプレート、UI（ページ）を作成します。

アトミックデザインの5つの要素には、以下のようなものがあります：  

1. 原子（Atoms）：HTMLタグ、フォント、アニメーション、カラーパレットなど、UIの基礎となる要素。デザイナーはこれらの要素を分解することはできない。
2. 分子（Molecules）：原子が組み合わさって、フォームのラベルや入力フィールドのような小さなインタラクティブなコンポーネントを作る。
3. 生体（Organisms）：ユーザビリティやアクセシビリティの問題を解決するために、デザイナーが使うインタラクティブ性の高い複雑なUIコンポーネントであり、ロゴ、検索フィールド、プライマリーナビゲーションなどが例として挙げられる。
4. テンプレート：ブログのフィード、カルーセル、導入事例、フッターなど、さまざまなウェブサイトやアプリケーションの部門の構造を定めるものであり、テンプレートには、このような大きな構造を作成するための原子、分子、生体のグループ化が含まれている。
5. ページ：ユーザーのニーズとビジネスゴールを一致させ、まとまりのあるUIを作成するためのテンプレート集を使った完全な画面。

コンポーネント駆動型プロトタイプにおける8つのメリット

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

  コンポーネント駆動型のプロトタイプの最も大きなメリットは、デザインと開発の連携の強化であり、デザイナーとエンジニアは、レポジトリやnpmパッケージ、Storybookでホストされている同じコンポーネントライブラリを使って作業します。  

UXPin Mergeのようなツールは、デザインと開発の間の繋がりを促し、各部門が単一のコンポーネントライブラリにアクセスできるようにします。デザインチームが視覚的なUIコンポーネントを使う一方で、エンジニアはその背後にあるコードを見るというように、同じ要素を異なる視点から見ることができます。   

2. デザインの一貫性

  この信頼できる唯一の情報源（Single source of truth）は、デザインと開発全体の一貫性の維持に優れており、インタラクティブ機能とスタイリングが組み込まれているため、デザイナーはUIコンポーネントを組み合わせてUIを作成することだけを考えればよく、色、タイポグラフィー、サイズ、境界線の半径、正しいアイコンの使い方などのバリエーションといったよくある問題を排除することができます。  

また、デザインの一貫性は、複数のチームが同じ製品に取り組む際に重要な、承認され統一されたコンポーネントやUIを受け取るエンジニアにも利点があります。

3. 共有可能

  デザインチーム間でコンポーネントを共有することで、デザインの一貫性を維持しながら、UXワークフローとデザイナーの連携を効率化することができます。  

静的なUIキットで、デザイナーはUI要素の共有ができますが、そのようなキットは忠実性と機能性に欠けています。そうなると、デザイナーが自らセットアップしなければならず、それがインタラクションデザインの矛盾やドリフトにつながります。  

そこでコンポーネントライブラリを共有すれば、デザイナーはビジュアル要素、インタラクション、スタイリング、その他デザインシステムが設定するあらゆる制約を受けることができます。  

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

  デザインハンドオフは、デザイナーとエンジニアにとって、本来はストレスの多い、虚構に満ちたプロセスであり、デザイナーは、ツールやビデオ、ドキュメントや静的なデザインを使って、プロトタイプが「何をするはずなのか」を示します。  

UXPin Mergeでデザインハンドオフを行うと、エンジニアが同じコンポーネントを使うため、不確実性がなくなり、文書化を減らすことができます。デザイナーは、各コンポーネントのインタラクションやスタイリングのプロパティで技術的な制約を受けないようにできるので、エンジニアが再現できないデザインを目にすることはほとんどありません。  

5. 有意義なフィードバック

  ユーザビリティの参加者やステークホルダーも、コンポーネント駆動型のプロトタイプの恩恵を受けます。完全にインタラクティブなプロトタイプは、最終的な製品とその能力について、誰もが現実的に期待することができ、デザインチームは、より高い忠実度と機能性により、ステークホルダーとエンドユーザーから有意義で実用的なフィードバックを得ることができるのです。

6. より高速なイテレーション

コンポーネント駆動型のプロトタイプのワークフローにより、デザイナーはテストやステークホルダーからのフィードバックに対して、より速やかにイテレーションを行うことができます。ドラッグ＆ドロップによるデザインプロセスと簡単にできるプロパティへのアクセスにより、デザイナーはその場で変更を加えることができるのです。ちなみにPayPalは、UXPin Mergeに切り替えた後、以下のようにその効率性の向上を実感しました：

「忠実度の高いプロトタイプをより早く作り、セッション後にすぐにフィードバックが得られます。すぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。」- PayPal, UXシニアマネージャー、エリカ・ライダー氏

UXPin Merge のユーザーはPatternのようなツールの恩恵を受け、デザインチームは1つのコンポーネントが持つ複数のバージョンを共有のパターンライブラリに保存することができます。そしてデザイナーは、UXPinのPropaties Panel（プロパティパネル）を使う代わりに、UI要素とパターンを切り替えて、より速くイテレーションを行うのです。  

7. レスポンシブデザイン機能

  レスポンシブデザインは、デザイナーにとって時間のかかる作業です。1つの画面に対して複数のレイアウトの作成が必要があり、それによってデザインプロジェクトに多大な時間が費やされることになります。そこで、レスポンシブコンポーネントを開発することで、デザイナーはプロトタイプを１つ作成するだけで、すべてのレイアウトに対応できるようになります。  

Merge のコンポーネント駆動型のプロトタイプのソリューションでは、デザイン システムチームはコンポーネントをiFrameでラッピングして、複数のビューポートに対応させることができ、デザイナーはデザインをプレビューする際に、ドロップダウンを使ってこのようなレイアウトを切り替えることができます。  

8. デザインの拡張性

  コンポーネント駆動型のプロトタイプのドラッグ＆ドロップの特性とは、非デザイナーが、画像ベースのデザインツールを使う熟練のUXデザイナーよりも、高い忠実度と機能性でプロトタイプを構築することができるということです。  

PayPalが2019年にUXPin Mergeを使い始めた際に、製品チームをトレーニングすることでデザインプロジェクトの90%を完了させることができました。UXデザイナーは製品チームを指導し、複雑なユーザビリティの問題をサポートすることで、UX専門家を増やす必要性が下がるとともに、ハイレベルなUXの取り組みに集中できるようになりました。  

コンポーネント駆動のワークフローは、学習曲線を大幅に短縮し、プロトタイプを高速化することで、非デザイナーにもデザインプロセスがより身近なものになっているのです。  

コンポーネント駆動型のプロトタイプのワークフローを導入している会社

  PayPalとTeamPasswordは、コンポーネント駆動型のプロトタイプを使って不整合を排除し、顧客にポジティブなユーザー体験を提供しています。  

PayPalが巨大な多国籍企業であるのに対し、TeamPasswordは小規模なチームで運営されていることから、今回この２社を例に選びました。  

両社とも、UXPin Mergeに切り替え、コンポーネント駆動型のプロトタイプのワークフローを採用することで、大きなメリットを得られました。  

PayPal

  PayPalは、コンポーネント駆動型のプロトタイプのとてもいい成功例です。同社はUXPin Mergeに切り替えた後、画像ベースのデザインツールを使っていたときよりも8倍速くデザインプロジェクトを完成させました。  

「PayPalで使っている別のデザインツールで、1ページのベクターベースのデザインを行い、その後、UXPinでMergeコンポーネント ライブラリを使って全く同じプロトタイプを作成しました。Merge だと、デザイナーは約 8分間でできますが、他のデザインツールでは1時間以上かかりました。」

「社内でよくある問題は、製品チームがUXデザインをボトルネックと捉えていることです。まずはそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにする戦略を実行しました。」 – Paypal、エリカ・ライダー氏  

PayPalのコンポーネント駆動型のワークフローでは、製品開発に関わるすべての人がUXに責任を持つようになります。最も大きな影響として、コンポーネント駆動型のプロトタイプによって、PayPalの製品チームはより多くのデザイン責任を担うことができるようになった点です。  

Teampassword

  パスワード管理は、組織が顧客の確保および維持のために信頼を勝ち得なければならない、競争の激しい業界であり、デザインは、ブランドの強化や、顧客の信頼とロイヤルティを獲得する一貫したユーザー体験を生み出す上で、重要な役割を担っています。  

「お客様は私たちに「ログイン記録」という重要な情報を託しています。矛盾や時代遅れのデザインは、当社がその情報を安全に保つのに十分な最先端の技術を備えているかどうか、一部のお客様に疑念を抱かせてしまうことになります。フロントエンド開発は、バックエンドのパフォーマンスに対する信頼と自信を築くのです。」トニー・カッチャーボ氏、TeamPasswordオペレーションディレクター  

TeamPasswordはゼロからデザインする代わりにオープンソースのコンポーネント ライブラリを使い、プロトタイプとテストのためのデザイン チームは設けられてません。その代わりに、TeamPasswordのフロントエンドのデベロッパーは UXPin Merge を使って新しいUIや機能のプロトタイプとテストを行っています。  

このコンポーネント駆動ワークフローによって、TeamPasswordは製品のデザイン、テストなどが高い整合性で行うことができ、市場競争の中での運営において欠かせないものとなっています。  

コンポーネント駆動型のプロトタイプの始め方

  デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成することはこれまで以上に簡単になります。UXPin Mergeでを使用することで、組織はコンポーネント ライブラリをインポートでき、デザイナーとエンジニアは同じ UI 要素を使えるようになります。  

コンポーネントの取り込み

  デザイナーは、UXPinのNPM統合を使ってオープンソースのコンポーネントライブラリをインポートしたり、エンジニアの協力を得て、MergeのGitまたはStorybookの統合を使って製品のデザインシステムを同期させたりすることができます。

プロトタイプ

どの方法でUXPinとコンポーネントを同期させても、デザインの流れは同じです。

• MergeのUI 要素をキャンバスにドラッグして、プロパティパネルで変更する。また、より大きく、より複雑なコンポーネントを作成するのにUXPin Pattern（パターン機能）を使って要素を組み合わせることも可能。
• コンポーネントを接続してプロトタイプを作成し、ユーザビリティテストやステークホルダーへのプレゼンテーションを行う。
• 完璧なソリューションを見つけるまで、テストとイテレーション行う。UXPinでは、【プレビューと共有】を使ったブラウザでのテストや、【UXPin Mirror】を使ったモバイルでのテストが可能。
• プロジェクトに【ドキュメンテーション】を追加し、デザインハンドオフの時にコメント機能を使ってエンジニアと共同作業を行う。

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

UXPin Mergeは組織全体での「信頼できる唯一の情報源（Single source of truth）」として機能し、それによって製品のデザインシステムの管理および拡張のお手伝いをします。さらに、コンポーネントライブラリのレポジトリに変更があると、UXPinのデザインエディタに自動的に同期され、チームに更新が通知されます。

UXPin Mergeのバージョンコントロール機能で、リリースの追跡や、デザイナーによる以前のバージョンへの切り替えができるため、アップデートを完全にコントロールすることができます。

UXPin Mergeが提供するコンポーネント駆動型のプロトタイピングを試してみませんか？詳細とこの革新的なテクノロジーへのアクセス権のリクエスト法については、Mergeのページをぜひご覧ください。

The post コンポーネント駆動型 プロトタイプとは？ appeared first on Studio by UXPin.

強力な ビジョンステートメント によって、デザインチームの行動を後押し、製品や組織の成功へと導きます。本記事では、デザインチームの効果的なビジョンステートメントの作成方法を踏まえ、世界の有名企業の実例をもとに詳しく分析していきます。また、ビジョンステートメントを作成・実行するための段階的なフレームワークもみていきましょう。

UXPin Merge を使って、共有のビジョンでチームを調整し、デザイン業務を拡張しませんか。詳細とアクセスリクエスト方法については、こちらのページをぜひご覧ください。

ビジョンステートメントとは

デザインにおける「ビジョンステートメント」は、製品や組織のデザイン部門の長期的な目標や今後の展望を概説するものです。デザイナーに明確な方向性を導き、インスピレーションやモチベーションの源となります。

「ビジョン」と「ミッション」のステートメントの整合

「ビジョンステートメント」と「ミッションステートメント」を組み合わせることで、組織の目的や方向性を全体的に理解することができます。

ビジョンステートメントには、望ましい今後の在り方と長期的な目標が示され、ミッションステートメントには、組織の中核的な目的とビジョンを達成するための戦略を策定します。このようなステートメントは、意思決定のための道しるべとなり、連携の促進、共通の目標に向かってチームを団結させるまとまりのある体制を強化します。

チームに ビジョンステートメント が重要な理由

チームのビジョンステートメントを作成することで、デザインの方向性と意思決定プロセスの基盤が確立されます。例えば、インスピレーションを与えるビジョンステートメントだと、デザインチームの目標と願望に対する共通理解を深めることにより、創造性とチームワークを高め、イノベーションを促進します。

このビジョンステートメントでチームを支え、デザイナーは課題を解決し、部門の長期的な目標に沿った高品質でユーザー中心のソリューションを提供することに集中できるようになります。デザインのビジョンステートメントが適切に実施されれば、企業理念に沿った発展と成功を促進する強力なツールとなるのです。

ビジョンステートメント の作成におけるUX戦略の役割

企業のUX戦略は、望ましいUX（ユーザーエクスペリエンス）を明確にし、デザイン原則を指針にすることで、デザインのビジョンステートメントを作成します。理想としては、UX戦略がデザインのビジョンステートメントの青写真の役割を果たすため、企業は最初にUX戦略を策定し、デザインチームの目標が会社のビジョンステートメントやより広範な目標と確実に一致するようにします。

デザインまたは DesignOpsリーダーがチームのビジョンステートメントを形成する方法

デザインまたは DesignOps リーダーは、連携を促進し、イノベーション文化を育み、チームを共通の目標に向けて導くという点で、ビジョンの形成において極めて重要な役割を果たします。また、会社のUX戦略を実行可能な目標に置き換え、デザイン部門のビジョンが企業の価値観や理念と一致させる必要があります。

チームのビジョンステートメントの目的を理解する

目標と価値観を一致させる

チームのビジョンステートメントは、デザイン部門の「目標」と「価値観」を一致させ、確実にチーム団結で作業をし、組織のコアバリューに忠実でありながら、組織の全体的な目標に優先順位をつけられるようになります。

方向性の共有を図る

いいビジョンステートメントというのは、チームに明確なロードマップを提供し、望ましい未来の状態を示し、共通の目標達成に向けてチームメンバーが一丸となって取り組むようにさせることで、方向性における共有意識を育みます。

意思決定プロセスの指針

チームのビジョンステートメントは、選択と行動に影響を与えるフレームワークを設定することで、デザイン部門内の意思決定プロセスを導き、チームの長期目標との一貫性を保証します。

チームの効果的なビジョンステートメントの主な要素

明確さと焦点

明確なビジョンステートメントは、デザイン部門の目標を簡潔かつ効果的に伝え、共有された目標に向けて統一感のある取り組みが促進されます。

例：デザインチームが、自社のブランドを高め、顧客ロイヤルティを刺激するシームレスでユーザー中心の体験を提供できるようにする。

インスピレーションと向上心

説得力のあるビジョンステートメントは、インスピレーションを与え、向上心をかき立てます。チームのモチベーションを上げ、デザイン部門が目指すものを明確にするようなビジョンステートメントでないといけません。

例： 「ユーザーとテクノロジーとのやり取りの方法に革命をもたらし、業界の新たな基準を確立する革新的なデザインソリューションを生み出す。」

チームのコアバリューの反映

ビジョンステートメントは、チームのコアバリューを具現化し、デザイン部門の行動と決定、そのアイデンティティと目的を明確にする原則と一致させなければなりません。

例：直感的でインパクトのあるUXを創造するために、共感、連携、継続的な学習を重視します。

未来志向で順応性がある

うまくいくビジョンステートメントは、未来志向で、順応性があります。それによってデザイン部門は、明確な方向性を維持し、原則に忠実でありながら、進化する市場環境や優先事項の移り変わりを乗り切ることができるのです。

例： ユーザーのニーズを先取りし、デザイントレンドとテクノロジーの進歩の最前線に立ち続けることに尽力する。

デザインチームの ビジョンステートメント の作り方

１．チームメンバーやステークホルダーからインサイトを集める

まずは、チームメンバーや主なステークホルダーから意見を募ります。このような協働的なアプローチにより、賛同者を増やし、ビジョンステートメントに多様な視点を取り入れることができます。例えば、ブレーンストーミングセッションを実施したり、匿名アンケートを利用したりして、チームの目標、価値観、要望に関するインサイトを集めましょう。

２．共通のテーマおよび価値観を特定する

フィードバックを分析し、繰り返し現れるテーマや、チームに共通の価値観を特定します。フィードバックのパターンを探し、一貫して浮かび上がってくる側面を強調しましょう。例えば、チームメンバーが「共感」「連携」「革新」について頻繁に言及している場合、その価値観がビジョンステートメントに反映されるはずです。

３．部門の目的と願望を明確にする

ステップ２のテーマとパターンを使って、デザイン部門の目的と願望を確定します。このステップでは、チームの存在理由と、仕事を通じて達成したい成果を明確に示しましょう。例えば、デザイン部門の目的は、顧客満足とロイヤルティを高める、魅力的で利用しやすいユーザー体験を作ることかもしれませんね。

４．簡潔で印象的なステートメントを作成する

チームの目的、価値観、願望を集めたような、簡潔で印象的なビジョンステートメントを作成しましょう。このステートメントは、例えば「共感、コラボレーション、イノベーションを原動力に、感動、パワフルさ、インスパイアを与えるユーザー体験をつくる」など、明確で、実行可能で、覚えやすいものでないといけません。

５．ビジョンステートメントをテスト、改良する

ビジョンステートメントの下書きをチームメンバーやステークホルダーと共有し、フィードバックを求めます。この反復プロセスにより、ビジョンステートメントがチームや組織の共感を得られるようになります。

６．ビジョンを伝えて実行する

デザインチームのビジョンステートメントを最終決定したら、チーム全体で共有し、日常業務に組み込みます。このステップでは、チームのワークスペースにビジョンステートメントを掲示したり、プロジェクトの開始時に参照したり、業績評価の指針として使ったりして、チームのミーティング、目標設定プロセス、意思決定の枠組みにそのビジョンを組み込みます。

ビジョンステートメントをデザイン文化に組み込む

ここでは、ビジョンを組織のデザイン文化に根付かせるためのヒントを以下に挙げてみましょう：

• ビジョンステートメントを定期的にチームと共有し、常に新鮮な状態に保つ。（例：チームミーティングの冒頭でビジョンを再確認し、現在の取り組みとの関連性を明らかにする）
• ビジョンステートメントをオンボーディングとトレーニングに組み入れ、チームメンバー全員の足並みをきちんと揃える。（例：オンボーディングの際、ビジョンがデザイン部門の業務や意思決定をどのように形成しているかを説明する。）
• ビジョンステートメントを業績評価やフィードバックに組み込む。（例：業績評価の際に、デザイナーの仕事がビジョンの実現にどのように貢献したかを話し合う。）
• ビジョンに沿った成功を祝い、その重要性を強化する。（例：あるプロジェクトがビジョンステートメントの原則を現している場合、チームミーティングの中でそれについて述べ、チームの努力を称賛する。）

トップ企業のビジョンステートメントの例

IDEO

“We believe a better future is for all of us to design.”

デザインチームは IDEO のビジョンステートメントから、「We believe a better future is for all of us to design.」という考えを学ぶことができます。このステートメントは、デザイナーが自分たちを取り巻く世界の形成に積極的な役割を果たすことを促し、インクルーシブなデザインプラクティスの重要性を強調しています。

IBM Design

“IBMers believe in progress—that by applying intelligence, reason, and science we can improve business, society, and the human condition. Given our scale and scope, good design is not just a requirement, it’s a deeper responsibility to the people we serve and the relationships we build.”

日本語訳：「インテリジェンス、理性、科学を応用することで、ビジネス、社会、そして人間の状態を改善することができます。私たちの規模と範囲を考えると、優れたデザインは単なる要件ではなく、私たちがサービスを提供する人々と築く関係に対する、より深い責任なのです。」

IBM のビジョンステートメントは、インテリジェンス、理性、科学を仕事に活用することの重要性や、優れたデザインは基本的な責任であることの理解を強調しています。また、このステートメントでは、ビジネスと社会の両方におけるデザインの影響を強調し、それによってポジティブな変化を推進するデザイナーの役割が強調されています。

MUI

“We aim high trying to design the most effective and efficient tool for building UIs, for developers and designers.”

日本語訳：「私たちには、UIを構築するための最も効果的で効率的なツールをデベロッパーとデザイナーのためにデザインしようと高い目標があります。」

MUIのビジョンステートメントは、チームのツールやプロセスにおける卓越性の追求に焦点を当てています。このステートメントは、デベロッパーとデザイナーにより良いサービスを提供し、最終的に連携と効率を上げるために、UI デザインのソリューションを継続的に改善して最適化することの重要性を強調しています。

MUIコンポーネントをデザインプロセスに取り入れることで、最終製品のような外観や機能性のプロトタイプを作成できることをご存知ですか？

オープンソースのUIライブラリや社内デザインシステムをMergeを使い、UXPinにインポートすることで、デザインから開発まで「信頼できる唯一の情報源（Single source of truth）」をつくることができます。詳しくは こちらのページをぜひご覧ください。14日間の無料トライアルはこちらより。

The post デザインチームの ビジョンステートメント – 定義と手順 appeared first on Studio by UXPin.

急速に進化する今日のデジタル環境では、 デザインシステム は製品チームにとって欠かせない存在となっています。うまく実装されたデザインシステムだと、デザインの一貫性、開発協力者・関係者（デザインチーム、開発者、ステークホルダー）間のチームワークとコミュニケーションも円滑になります。デザイン・開発プロセスが早くなり、それによって拡張性や保守性は高まり、UX（ユーザーエクスペリエンス）や製品の品質の向上につながるのです。

そこで本記事では、製品開発で起きがちな８つの課題と、 デザインシステム での解決策をご紹介します。問題を認識し、効果的なデザインシステムを導入することで、チームは現代の製品開発の課題を乗り越え、優れたデジタル体験をユーザーに提供するためのより良い環境を手に入れるようになります。

UXPin Mergeで、高品質な製品をより早く提供し、コストのかかるエラーをなくしませんか？詳しくは Mergeのページをぜひご覧ください。

課題１．一貫性のないUI  / UX

問題点：一貫性のない UI（ユーザーインターフェース）や UX（ユーザーエクスペリエンス）は、ユーザーの混乱やフラストレーションを招いてしまいます。これは製品に対するイメージに悪影響を及ぼします。

そしてこのような矛盾は、製品の様々な部分や複数の製品に携わるデザイナーやデベロッパーの間で、デザインの断片化、意思疎通の行き違い、標準化の欠如に起因する場合があります。

デザインシステム ができること：デザインシステムは、再利用可能なUIコンポーネント、パターン、レイアウト、フォント、色、ガイドラインを統一して使うことで、万人に「信頼できる唯一の情報源（Single source of truth）」を提供します。そしてこれにより、製品全体で一貫したビジュアル言語と機能性が保証されます。

また、明確な基準とベストプラクティスを確立することで、デザインシステムは不整合のリスクを減らし、ブランドアイデンティティとユーザー満足度をより強いものにする、まとまりのある直感的なUXを促進します。

課題２．デザインおよび技術的なUI負債

問題点：デザインや技術的なUI負債とは、デザインや開発プロセスにおいて横着したりお粗末な判断をした時にもたらされる結果です。こうした妥協は、時間の経過とともに、矛盾やユーザビリティの問題、断片的なUXにつながり、結果として、後になってそのような問題を対処するのに大変な苦労をすることになります。

 デザインシステム できること：デザインシステムを導入することで、UXデザインの原則、コンポーネント、パターンライブラリの統一セットが確立され、デザイン負債や技術負債を防ぐことができます。この統一されたアプローチによって、デザイナーとデベロッパーは共通の理解をもって仕事に取り組むことができ、意思疎通の行き違いや矛盾の可能性が低くなります。

デザインシステム のガイドラインを遵守することで、チームはまとまりのある一貫したUXを実現し、長期的にはデザインや技術的なUI負債の蓄積を緩和することができるのです。

さらに読む：UXのビジネスケース：デザイン投資のための強力なケースを構築する方法

課題３．製品の維持や拡張がしにくい

問題点：製品のUIの維持と拡張は、その製品の進化とともにますます複雑になっていきます。デザイン上の負債が蓄積され、一貫したデザインパターンの欠如によって、更新や拡張は大変で時間がかかり、リソースを消費するものになる場合があります。

 デザインシステム ができること：デザインシステムは、再利用可能なコンポーネント、標準化されたパターン、メンテナンスと成長をより管理しやすくする明確なガイドラインを提供することによって、スケーラブルなデザインの基礎を築きます。

デザインシステムを導入することで、一貫性と品質を維持しながら、新機能の導入やデザインの更新を効率的に行うことができ、この効率的なアプローチによって、時間とリソースの節約が実現され、チームはイノベーションと優れたUXの提供に力を注ぐことができるようになるのです。

課題４．デザイナーとデベロッパーの間のコミュニケーションギャップがある

問題点：デザイナーとデベロッパー間のコミュニケーションにギャップがあると、製品開発の誤解や矛盾、遅れにつながることがあります。期待値のズレ、デザインモックアップの解釈の違い、不明確なドキュメントなどは、混乱を招き、非効率なプロセスとなり、最終製品の品質やUXにも影響を与えます。

 デザインシステム ができること：デザインシステムは、デザイナーとデベロッパー双方にとっての「信頼できる唯一の情報源」として機能し、明確なガイドライン、再利用可能なコンポーネント、標準化されたデザインパターンを提供することによって、コミュニケーションのギャップを埋めることができます。

デザインシステムでの基準があることで、両チームはデザイン言語や実装方法についての共通の理解を持つことによって、より効率的に作業することができます。このような連携の強化で、誤解を招く可能性は下がり、望ましいUXとデザイン目標を満たす、一貫性のある製品を確実に実現することができます。

課題５．オンボーディングでの課題

問題点：新しいメンバーが製品チームに参加すると、デザイン言語、UI コンポーネント、およびコーディングの実践を理解するのが大変なことがあります。このような学習曲線は、遅延や非効率の原因となり、新しいメンバーは、既存のデザインと開発のワークフローに追いつくのに、より多くの時間とリソースが必要になるかもしれません。

 デザインシステム ができること：明確なガイドライン、ベストプラクティス、再利用可能なコンポーネントをデザインシステムが提供することで、新規参入者は製品のデザイン原則、UI パターン、コーディング規約を速やかに把握することができます。

デザインシステムで、より速やかなオンボーディングのプロセスが実現し、それによって新しいチームメンバーがより効果的かつ効率的に製品開発に貢献できるようになり、最終的に全体の生産性と結束力が上がるのです。

課題６．市場投入までの時間がかかる

問題点：市場投入までの時間がかかるのは、デザインおよび開発プロセスの非効率性や、チームメンバー間の調整の煩雑さによるものかもしれません。

製品開発が遅いと、製品の市場投入や、新機能および改良の導入に時間がかかるため、納期の遅れ、コストの増加、競争力の低下につながります。

 デザインシステム ができること：デザインシステムは、デザインおよび開発プロセス全体を効率化することで、「市場投入までの時間がかかる」という問題を解決します。

UIライブラリの共有と明確なガイドラインにより、デザイナーとデベロッパーは効率的かつ協力的に作業でき、それによってデザイン要素の作成、改良、実装にかかる時間が短縮されます。

このワークフローの改善により、製品チームは新機能やアップデートをより速やかに提供できるようになることで、製品の競争力が上がり、市場の要求やユーザーのニーズに迅速に対応できるようになるのです。

課題７．デザインおよび開発業務の重複

問題点：一元化されたデザインシステムがないと、例えば複数のバージョンのアプリバーを作成する場合など、UI 要素の作成や更新の際に重複作業が発生しがちです。

デザイナーとデベロッパーがそれぞれ独立して、あるいはサイロ化しているため、このような非効率性が、時間、労力、リソースの浪費につながる可能性があり、それによって知らず知らずのうちに、お互いの努力を複製してしまったり、一貫性のないアセットを作ってしまったりしてしまいます。

 デザインシステム ができること：デザインシステムの導入によって、チームでの重複した作業は大幅に削減されます。

デザインシステムは、以下をもたらします：

• 信頼できる唯一の情報源
• 再利用可能なコンポーネントの UI ライブラリ
• 標準化されたパターン
• チームメンバー全員が簡単にアクセスし、適用することができるガイドライン

この「信頼できる唯一の情報源」によって、デザインと開発のプロセスが効率化され、誰もが確実に同じリソースを使って同じ基準で作業できるようになり、最終的に冗長な作業は排除され、より効率的で協力的、かつ結束の強いワークフローが促進されます。

課題８．デザインハンドオフが大変

問題点：デザインハンドオフは、大変で時間がかかり、デザイナーとデベロッパーの間に摩擦が生じることがあります。デザイナーにとって、デベロッパーに必要なアセット、仕様、ドキュメントをすべて提供するのは大変であり、誤解や遅延、手直しの可能性を招くことがよくあります。

 デザインシステム ができること：デザインシステムは、デザイナーとデベロッパー間のコミュニケーションに明確で標準化されたフレームワークを提供することで、デザインのハンドオフをシンプルにします。共有言語、統一されたコンポーネントライブラリー、スタイル、ガイドラインにより参照や理解が早くなります。

この効率的なアプローチにより、エラーの可能性は減少し、デザインは確実に正確かつ効率的にコードに変換されます。より円滑な連携のあるデザインシステムを促進することで、チームは最終的に、一貫した高品質の製品のより早い市場投入を実現できるのです。

ただ、デザイナーとエンジニアは、以下のように別々のデザインシステムを使っているため、どんなに優れたデザインシステムでも、「信頼できる唯一の情報源」のジレンマとまだ戦うことになります：

• デザイナー： UI キットを使用
• デベロッパー：コンポーネントライブラリを使用

デザイナーとデベロッパーが同じ UI ライブラリを使い、本当の意味での「信頼できる唯一の情報源」となるような究極の成熟を達成するには、何年もかかることがありますが、UXPin Merge を使えば、最初からそのギャップを埋めることができ、何年もの作業とリソースを回避することができます。

UXPin Mergeによるデザインシステムの構築と拡張

Merge では、レポジトリからコンポーネント ライブラリを同期することができるため、デザイナーはデザインプロセスにおいて、エンジニアが最終製品を開発する際に使うのと同じデザインシステムを使用できます。デザイナーはビジュアル要素で作業し、エンジニアはバックにあるコードを確認することで、組織全体で「信頼できる唯一の情報源」が作成されます。

また、この「コードからデザイン」のワークフローは、従来のデザインシステムや製品開発モデルで組織が直面する多くの課題を解決してくれます。デザインシステムチームは、単一のレポジトリにホストされた UI ライブラリのバージョン１つを更新および維持するだけでよく、デザイナーとエンジニアが別々のデザインシステムを維持することによる潜在的なエラーを排除しながら効率を最大化することができます。

Mergeは、デザインシステムを同期させるためのソリューションを３つ提供しています：

1. Git 統合：React UI ライブラリに直接接続し、パターン、バージョン管理、JSX オーサリングなど、 Merge の全機能への完全なアクセスが可能。
2. Storybook 統合： React、Vue、Angular、Ember のデザインシステムなど、あらゆる Storybook を UXPin に接続可能。
3. npm 統合：npmライブラリをUXPinと同期させる。

UXPin Merge の「信頼できる唯一の情報源」で、デザインシステムの構築、拡張、維持にかかる時間とリソースを節約しましょう。この画期的なデザインシステムテクノロジーの詳細とリクエスト方法については、Merge のページをぜひご覧ください。

The post デザインシステム が必要な理由「８つの課題」 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（ユーザーエクスペリエンス）、そして最も重要な組織のユーザーを支えます。会社のデザインビジョンを描き、デザイナーが目標やマイルストーンを達成するためのロードマップを明確にしてくれるのです。

そこで本記事では、UXPin、Microsoft、Google、Yammer、O’Reilly Media、GitHubでリーダー職を務めた経験豊富な業界エキスパート２名からのアドバイスを交えながら、デザインリーダーの役割についてご紹介します。

世界最先端のデジタル製品デザインツールでデザイナーが仕事をすることで、自信をもってリードしていきませんか。無料トライアルにサインアップしてUXPinの機能を試し、顧客のためにより良いUXを作っていきましょう！

 デザインリーダー の仕事とは

 デザインリーダー は、組織内のデザインチームのビジョンと戦略を指導します。組織のデザインにおいての原則と基準を確立しそれらを守りながら、デザインチームが質の高い作品を提供できるよう導きます。

 デザインリーダー は、組織、製品、デザインチームのニーズによって異なる責務を担いますが、通常は企業のリーダーシップチームや役員とも密接に関わることから有力なデザインの提唱者でもあります。

以下は、 デザインリーダー の業務例です：

• 組織のデザインビジョンと UX 戦略の設定
• ユーザーニーズの解決に焦点を当てた人間中心的な思考をデザイナーに徹底させる
• デザイン思考、問題解決、キャリア開発に関するデザインチームメンバーの指導とコーチングを行う
• ポジティブなUXを維持し、それが CX（カスタマーエクスペリエンス）全体にどのような影響を与えるかを理解する
• 製品開発プロセス全体にUXを統合するための部門横断的な連携
• 上の人達と協力して、デザインのゴールとビジネスのゴールを一致させる
• デザインの原則と基準を設定し、デザインチームが確実にそれを正しく適用して最高の作品を提供するようにする
• 部門の予算とリソースの管理
• デザイン人材の募集・採用・確保の監督
• デザインプロジェクトやイニシアチブを、コンセプトから立ち上げまでリードする
• 効果的で効率的なワークフローを構築し、高品質なプロジェクトを成功させる

 デザインリーダー になるための道のり

デザインリーダーになるには、通常、数年のデザイン経験と、デザインプロジェクトの成功やイニシアチブを発揮させた実績が必要です。

ここでは、企業がデザインリーダーを採用するときに求められる重要なステップをいくつかご紹介します：

• しっかりとしたデザインの基礎がある： グラフィックデザイン、インダストリアルデザイン、UX デザインなどのデザイン関連分野での学士号を取得している。
• デザイン担当の経験：様々なデザイン役割に携わることで、部門をリードするのに必要な知識、視点、専門性が身につく。
• スキルアップ：デザインリーダーには常に学ぶ姿勢があり、特に、デザイン、技術、管理、ビジネス、リーダーシップのスキルアップを目指している。
• リーダーとしての可能性の発揮：デザインリーダーになるには、チームやプロジェクトを率いる意欲と実績が必要。自ら積極的に行動して、実力を発揮したりスキルアップにつなげられる機会を得られるように、デザインリーダーを目指すことをリーダーシップやマネジメントに伝えなければならない。
• 出世コース：デザインの基礎を固め、チームを率いることに成功したら、デザインマネージャーやディレクターを経て、最終的にデザインリーダーへの昇進を目指せるようになり、さらにその先には、副社長や経営陣のポジションがある。

有能な デザインリーダー が持つ資質とは？

２０１７年、UXPinの創設者であるマーシン・トレダー氏（現 GoogleのシニアUX デザインマネージャー）は、優れたデザインリーダーとは何かについて考えを綴りました。

彼は２０１７年に次のように書いています…

アフリカのことわざで “If you want to go fast, go alone. If you want to go far, go together” 訳：「速く行きたいなら一人で行き、遠くを目指すなら共に行け」というのがあります。効率性を損なわずに一体感を保つことは、デザインリーダーにとって最高峰の仕事です。

優秀なリーダーが持つ最終目標は、チームの成功であり、有意義なUXを常に市場に提供することです。

デザインリーダーシップの素晴らしさは様々ですが、その根底には共通の経験やスキルがあります。

みんなそれぞれまったく異なる組織で、全然違う製品を扱っているかもしれませんが、デザインリーダーとしての以下のような側面は変わりません：

成功に導くデザインリーダーは熟練の経験があり、過去の成功にとらわれず常に進化し続けることを目指している

優秀なデザインリーダーとは、「デザイナー」としてだけではなく、「デザインとチームに対して愛情をもって指導できる人」です。デザインプロセスを明確に理解し、ユーザーを助けるためのビジョンを創り出す決意を持った人です。

未経験・経験の少ないデザイナーを指導することは、信頼と尊敬を築く上でも大きな課題になり、それによって、戦術的なフィードバックやデザイナーのスキルアップのサポートなどで業務が一部大変になります。

とは言っても、このようなデザインリーダーがいないことも確かです（筆者はまだお会いしたことはないのですが、、、）。偉大なデザインリーダーは、大体チームを通してスケールアップすることで、より良い仕事ができることを見出す経験豊富な実務家です。

 デザインリーダー は、UXを直接デザインするのではなく、素晴らしいチームを形付けていくことで、間接的にUXをデザインします。自身のスキルアップよりもチームのサポートを優先して、組織のデザイン効率を作り上げるのに、次第に デザインの技術 に重点を置かなくなります。

デザインリーダーは、チームの仕事を通じて、間接的にデザインするのです。

２．成功に導く デザインリーダー は、寄り添う時間を惜しまない。

 デザインリーダーの主な役割は、自分自身をデザインの仕事から解放し、他の人が素晴らしい仕事ができるように、邪魔にならないようにする必要があるというところです。最高の デザインリーダー は、チーム内で最悪のデザイナーにならないといけないですね。

チームの能力育成は、組織におけるデザインのスケールアップへの最短距離ですが、それは簡単なことではなく「時間」と「聖人君子のような共感力」が必要です。チームに寄り添い、彼らが自分よりもずっとすごい存在になるよう手助けしないといけないのです。

３．成功に導く デザインリーダー は、伝達上手であり聞き上手でもある

経験上、デザイナーは大体「聞く担当」というよりは「伝達担当」であり、話を聞くにしても、コメントをする順番が来るのを待ちます。そして、コメントする際は、自分が正しい側でありたいものです。

ただ、 デザインリーダー として成功するには、それ以上のものが必要です。

ある意味、問題を本当の意味で理解できるように、ユーザーリサーチの実践をチームに適用しないといけません。耳を傾けないといけないのです。すると、伝えるのがまったく違うものになってきます。

組織の中でデザインの声をはっきりと聞かせるには、声を大にして言わないといけませんが、組織が聞くべきは、個人の声ではなく、チームの声です。

成功に導く デザインリーダー は、伝えるために聴き、聴くために伝えるのです。

デザインリーダーは、チームのメッセージを増幅させるための拡声器としての役割を果たすべきと同時に、他人の話に耳を傾け、共感できるようにチームを指導すべきです。

４．成功に導く デザインリーダー 達 は、目標に向かって闘志を燃やす

偉大なデザインリーダー は、チームとユーザーのためにたゆまぬ努力を続けて戦います。チームもユーザーも、組織の中で強力な提唱者を必要としており、最高の体験を望んでいます。なので障害をすべて取り除くのが、 デザインリーダー の仕事です。

 デザインリーダー の人物像

デザインリーダーには共通点がたくさんあると気づいたとき、とても身近な概念を使って人物像を表現してみようと思い、 デザインリーダー の人物像を作ってみました。

デザイン・リーダーシップ・プログラムの策定やデザイン・リーダーの昇進・採用、あるいはデザイン・リーダーシップに関する会話のきっかけとして、こちらの図をご自由にご利用ください。

デザインチームのリーダーシップにおけるベストプラクティス

デザインリーダーシップの専門家であるシンディ・アルバレズ氏は、Yammer、GitHub、Microsoft、O’Reilly Media でリーダーシップを発揮した経験から、ベストプラクティスを６つ紹介してくれました。

ここでは、そのアドバイスを彼女自身の言葉で紹介します：

１．一緒に働く仲間に目標を求める

デザイナーの仕事は問題を解決することであり、見た目をただ美しくすることではありません。「誰が」「なぜ」「いつ」「何を」「どこで」「どのように」するかの理解が必要なのです。

仕様書や要求事項のリストを渡して、”とりあえずデザインしてくれ “と言ってきてもそれを受け入れてはいけません。丁寧に、でもしっかりと、このプロジェクトの主な目標を教えてほしいと主張しましょう。

「ライトボックスを使えばいい」、「◯◯機能で使ったのと同じスタイリングにすればいい」「◯◯社がやっていることを真似すればいい」などと言われるかもしれません。それがベストな解決策かもしれませんが、定められた目標に立ち返ってみないとわかりません。

２．デザインプロセスに光を当てる

私はこれを 「don’t be magic（魔法にかからないで）」とも呼んでいます。

もしあなたがベテランデザイナーで、直感的な聞き手であれば、みんなが言っていることとそうでないことを組み合わせ、彼らが最終的に何を望んでいるかを推測し、それを魔法のようにスクリーンに出現させることができます。初期段階のスタートアップや 急を要するデザインには欠かせないスキルです。

また、恐ろしく非スケーラブルでもあります。みんなはそうでないときでも、自分が明確にコミュニケーションをとっていると信じることができるのです。デザインとは「ただ描くこと」であり、視覚的な優先順位、色、スケール、順序についてあなたが行う何千もの暗黙の決定は任意であると考えることができるようになります。

デザインの決定事項の説明が必要： 「このスタイルを採用しているのは、ユーザーが取るべき最も重要な行動である要素 Aを強調するためです。ターゲットとするユーザーが全く違うので、Bの機能についてはあえて真似していません 。」

３．自分が現実的に信じるもののために戦う

過去の仕事では、以下のような極端なデザイナーと仕事をしたことがあります：

「デザインを教えてくれればどんどん作ります」↔「１ピクセルでも変えれば私の傑作は台無しです」

どちらも生産的ではありませんし、そのスペクトルの中で、自分や自分の性格、組織にとって最も効果的なのはどこなのかを学ぶのは、信じられないほど難しいことなのです。でもやってみないといけません。

もし、4つ目のリンクを追加することが UI を乱すと考えるのであれば、声を上げてその理由を説明しましょう。疑問やリスクを自由に表現してください。そして、もしステークホルダーが反対したら、受けて立ちましょう。時には死闘を繰り広げるべきこともあります。通常はそうなりませんけどね。

４．納品するものと時期を明確にする

以下は、思っていても通常誰も口に出さない質問です：

• このデザインはどの程度変更される可能性があるのか
• フォント、アイコン、画像などの細部はどの程度最終的なものなのか
• インタラクションを説明するのか、それとも静的なものなのか
• コアなユースケース、複数のエッジケース、使用シナリオを説明しているか
• すべてが完成しているのか、それとも「始めるには十分」なのか

上記の質問に答え、日付を記入した上で、書面で「納品するもの」をリストにした方がよいでしょう。やりすぎと感じるでしょうが、多くの誤解を防ぐことができます。チェックリストとして使ってください。

５．回復と補償

もし、何かが起きて（”もし”と言うか起こります）、約束したことが実現できなくなったら、すぐに連絡を取り、軌道修正のための計画を提示しましょう。

それがあなたのプロジェクトの人々にとって確実に一番便利又は効果的なプランであることを確認しましょう。

何のことわりもなく締切を逃してはいけません。何も言わずにいなくなってはいけません。黙って仕事をして３日後にすべての仕事を終えて再び現れるとかダメですよ。誰も迷ったり、探したりする必要がないように、すぐに声を上げましょう。

６．どうすればもっとうまくいくのかを常に考える

プロセスというのは、あなたを束縛するためにあるのではなく、チームがより効果的に動けるためにあります。プロセスがうまくいってないとき、それを恨んで惨めな気持ちなったところで何の解決にもなりません。また、ルールを回避しようとするのも何の役にも立ちません。問題解決のために、建設的な苦情を言いましょう。

同じ作業を繰り返していると感じたら、立ち止まって、それを自動化または単純化する方法はないかと聞いてみてください。自分の仕事が無駄になっていると感じたら、立ち止まってその理由を聞いてみましょう。

あるいは、何か特別なことをしたのなら、立ち止まって、あなたがしたことを仲間に教えてあげましょう。成功体験は共有しましょう。悪いものだけでなく、良い会議やプロジェクトも蒸し返し、なぜうまくいったのかを分析して再現してみましょう。

シンディのプロフェッショナルなキャリアからのヒントの共有に御礼申し上げます。彼女の詳細については、彼女のウェブサイトをご覧いただくか、LinkedInでつながってください。

UXPinで「いいデザイン」から「素晴らしいデザイン」へ

UXPin は世界最先端のエンドツーエンドデザインツールで、それによってデザインチームは最終製品のように見えるプロトタイプを作成できるようになります。

ここでは、UXPin が従来の画像ベースのデザインツールとは異なる主要な機能を４つご紹介します：

1. ステート：任意の要素に複数のステートを作成し、それぞれに個別のプロパティとインタラクションを持たせる。
2. 変数：ユーザーの入力をキャプチャし、データに基づいてアクションを起こすことで、テスト中にダイナミックで個別化された UX を実現する。
3. 条件付きインタラクション：「if-then」や「if-else」ルールを作成し、ユーザーのアクションや入力に対して異なる反応を実行する。
4. エクスプレッション：フォームの検証、計算コンポーネント、パスワード認証のシミュレーションなど、従来はコードでしか利用できなかった複雑な操作を実行する関数をデザインする。

最終製品のような外観と機能を持つ高度でインタラクティブなプロトタイプで、デザインチームを次のレベルへ引き上げましょう。無料トライアルにサインアップして、UXPin の機能をぜひお試しください。

The post チームを成功に導く デザインリーダー の人物像 appeared first on Studio by UXPin.

UXデザインは、その主観的な性質から、数値化して測定するのは簡単ではありません。また、UXはビジネスの他の領域、つまり営業、マーケティング、サポート、エンジニアリングにも間接的に影響を及ぼしますが、UXデザインが組織内で成功するには、デザインリーダーシップがデザイン投資の 価値 を実証しないといけません。

Forrester の２０１６年のレポートである「The Six Steps For Justifying Better UX（より良いUXを正当化するための6つのステップ）」では、”…平均して、UXに費やす１ドルに対して、１００倍のリターンがあります！”と発表しています。なのでデザインリーダーには、そのROI （投資収益率）を特定・測定する方法が必要なのです。

また、Forrester のレポートでは、企業が優れたデザインシステムに基づくUXを使用した場合、そのウェブサイトが以下のように優れていることがわかりました：

• 消費者のコンバージョンが４００％アップ
• 顧客の商品推奨意欲が１６.６％アップ
• 顧客の金銭消費意欲が１４.４4％アップ

「コンバージョン４００％アップ」が気になりますか？

そのはずです！そして、実際に筋が通っているのです。UXデザインとは、ユーザーを理解し、そのニーズを満たすことですからね。UX 部門がユーザーにとっての 価値 を最大化すれば、それがコンバージョンや利益の向上につながるのはわかりますよね。

今お使いのデザインツールは、顧客の 価値 を最大化するための包括的なエンドツーエンドのソリューションを提供できていますか？UXPinは、世界最先端のコードベースの UXデザインツールです。UXPin の強化された忠実度と機能性で、プロトタイプとテストを次のレベルへ引き上げましょう。ぜひ今すぐ無料トライアルにご登録ください！

デザインの ROI とは

ビジネスにおいて ROI とは、通常「％」で表示される業績評価です。投資に対する直接的なリターンを計算することから、ROI（Return On Investment：投資におけるリターン）の頭文字をとっています。

ROIは次のように算出します：

ROI＝（［投資による利益］-［投資コスト］）÷　投資コスト

デザインの ROI も同様に測定しますが、標準的な測定よりも少し複雑です。

以下のように財務的に分離する必要があります：

• UXから得られるもの
• 新機能の開発など、その他すべての労力から得られる利益

こういった利益を算出する際の課題の１つは、ステークホルダーがこの計算を「偏ったもの」や「最も有利な結果を選んでいる」と受け取ったりする可能性があるということです。そこで本記事の後半で、それを克服すべくデザイン ROI の適切な計算法をご紹介します。

デザインの ROI の例

以下は、デザインの ROI の例です：

• 売上/コンバージョンの増加
• テクニカルサポートコールの減少
• 顧客ロイヤルティ
• 顧客満足度
• 顧客囲維持
• 市場投入への時間の短縮（デザイン・開発への影響について）
• 手直しやミスの低減
• 社員の定着率
• 人件費削減

KPI の選択

ROI について語るとき、KPI（key performance indicators：重要業績評価指標）という文字もよく目にします。KPI もパフォーマンス測定ですが、望ましいゴールへの進捗を追跡するベンチマークやマイルストーンにも関連しています。

KPIの例としては、以下のようなものがあります：

• 利益
• コスト
• 時間
• CLU（Customer Lifetime Value：顧客生涯価値）
• ETR（Employee-Turnover Rate：従業員離職率）
• 従業員の生産性

デザインプロジェクトの ROI の算出法

デザインの ROI の算出は、測ろうとしているものによって違ってきますが、Athena Health のプリンシパル・デザイン・リサーチャーであるアーロン・パワーズ氏が、情報満載のウェビナーで、財務モデルによるUX ROI の算出方法を実演しています。

また、彼は、デザイン算出 の ROI が、以下のようなさまざまな分野からどのように引き出されるかを示しています：

• ファイナンス： 複雑な数式を含む教科書的な金融モデリング
• 意思決定モデル： 意思決定のシミュレーションとガイダンスのための教科書的モデル
• マーケティング分析： ユーザーの行動をビジネスの成果につなげるという点で、多くの類似した目標がある
• 機械学習（ML）：回帰モデリングは、余計なものを取り除いてユーザー行動とビジネス成果の間のモデルを効果的に構築することができる。

これらは単純な計算ではないので、財務モデリングについては、以下の目的でオンライン UX ROI 計算機を提供するウェブサイトであるHuman Factorを利用するといいでしょう：

• 生産性の向上
• ヘルプデスクへの依存度を低減
• コンバージョン率の向上
• 正規のトレーニングにかかるコストの削減
• 脱落率の低下
• 学習曲線の短縮

また、ランドルフ・バイアス氏とデボラ・メイヒュー氏による「Cost-Justifying Usability（コストに見合ったユーザビリティ）」という本も非常にお勧めです。この本では、どれくらいの投資額を出資すべきかの計算やユーザビリティを他者に売り込む方法に注目しています。

デザインのビジネス 価値 を高める3つの方法

デザインの ROI を特定および測定するためのアイデアを得たところで、組織全体で UX の 価値 を上げる方法を３つご紹介します。

１．デザインシステムの導入

デザインのビジネス価値を高める方法の一つとして、顧客や組織に貢献するデザインシステムの構築が挙げられます。

デザインシステムの構築には時間がかかり、かなりのリソースの投入が必要です。なのでその 価値 を証明しないといけないのですが、その算出には、潜在的な ROI の提示や、デザインシステムの成功を追跡するためのステークホルダーのための KPI の提示などが含まれます（全部上に概要があります）。

ここでは、組織にとってのデザインシステムの利点を提示する方法をご紹介します。

包括的なデザインシステムというのは、デザインチームがプロジェクトをいちいちゼロから始めなくていいということです。デザインシステムから必要なものを取り出し、以下にある承認されたものを使ってプロトタイプを作り始めることができますからね：

• カラースキーム
• アイコン
• UIパターンおよびコンポーネント
• デザインシステムのドキュメント
• 画像、映像、ロゴなどのアセット
• インタラクション

デザインシステムを導入することで、ビジネスは以下のメリットが得られます：

• 新製品や新機能の市場投入までの時間短縮
• デザイナーが同じビルディングブロックを使用することによる、ミスの減少
• より簡単なオンボーディング
• チームや部門間での連携強化
• 一貫性の向上による、より良いCX（カスタマーエクスペリエンス）の実現

デザインシステムの 価値 を測るKPI

デザインシステムの 価値 の測定は、デザイナーやステークホルダーからの賛同を得るために非常に重要です。そこで、デザインシステムのパフォーマンスを長期的に追跡するために、測定したい重要な KPI が３つあります：

• チーム効率 – 組織のデザインシステムを使用して、チームが新製品を作るのにかかる時間
• 市場投入までのスピード– チームがプロトタイプを作り、テストするのにかかる時間
• コードへの影響 – リリースごとにデベロッパーがどの程度コードを変更したか

まず、デザインシステムなしでこのようなメトリクスを測ってベースラインを取得し、次にデザインシステムありでその影響を計算する必要があります。

２．DesignOpsでビジネス 価値 を作る

DesignOps は、デザインワークフローの最適化や、非効率な作業を減らす方法の検索を主な目的としています。つまり、デザイン部門のビジネス 価値 を高めるためのもう一つの方法ということです。

DesignOps のもう一つの機能は、他部門と連携してパートナーシップを構築し、ビジネス全体におけるデザインの影響力を最大化することであり、他部門から定量的なデータを見つけ出し、DesignOps の効率化にまで遡及することを目標としています。

つまり、DesignOps は効率や 価値 を生み出すだけでなく、デザインの内外での事例を積極的に探しているのです。

ちなみに、UXPin が主催する有益なウェビナーでは、Babylon社 のアソシエイト・デザイン・オペレーション・ディレクターであるパトリツィア・ベルティーニ氏が、デザイン、ビジネス 価値 、組織に対する DesignOps の影響を測るフレームワークを提供してます。

３．適切なプロトタイピングツールを使う

デザインの効率化を図るのは、コストの削減や、より高い ROI 獲得のための最良の方法であり、正しい UX ツールを使うことで実現されます。例えば PayPal は、UXPin Merge に切り替えることで、デザインおよび開発プロセスに革命を起こし、プロセスにおける大幅な効率化と 価値 を作り出しました。

PayPal の課題は、デザイン部門の規模の拡大や、新しいデザイナーの雇用なしでの UXの拡張でしたが、PayPal のUX – デベロッパーツールやプラットフォームのエクスペリエンス担当のシニアマネージャーであるエリカ・ライダー氏は、「デザインの効果的な拡張には、デザインプロセスにデベロッパーやプロダクトマネージャーを含める必要がありました」と述べています。

UXPin Merge に切り替えることで、PayPalは、従来のベクターベースのデザインツールを使う経験豊富なUXデザイナーよりも８倍速く新製品や新機能を構築できるよう、製品チームを強化しました。

Merge はPayPal が以下に取り組むお手伝いをしました：

• デザインと開発の間の「信頼できる唯一の情報源（Singel source of truth）」の作成。
• 市場投入までの時間の大幅な短縮
• エラーの削減
• 製品の品質向上
• 一貫性と全体的なUX（ユーザーエクスペリエンス）の向上
• 非デザイナーが新製品のデザイン、プロトタイプ、テストに参加できるようにする。
• UX、プロダクトチーム、開発間の連携の向上
• UXデザイナーが、グローバルに影響を与える大規模なUXイニシアチブを通じて、価値の創造に集中できるようにする。

この 価値 を生み出すための UXPin Merge の仕組み

Merge によって、組織のデザインシステムをホストするレポジトリに UXPin のデザインエディタを同期させることができます。UXPin はコードベースのデザインツールであるため、これらのデザインシステムのコンポーネントには、レポジトリ内のものと同じ機能と忠実度が備わっています。

デザイナーは、このようなコードコンポーネントを使って、ユーザビリティテスト参加者やステークホルダーが最終製品同様に操作できる、完全に機能する高忠実度のプロトタイプを構築できます。

デザイナー、製品チーム、デベロッパーはみんなレポジトリ（Git または Storybook との統合による）にホストされた単一のデザインシステムを使い、レポジトリに変更があると、自動的に UXPin のエディタにシンクバックされてチームメンバーに更新が通知されるため、「信頼できる唯一の情報源（Single source of truth）」ができます。

• 単一のコードベースのデザインシステムを使うことで、デザイナーはコンポーネントをドラッグ＆ドロップして、完全に機能するプロトタイプをテスト用にサッと構築することができます。
  
• ユーザビリティの参加者は、最終製品と同じようにプロトタイプを操作することができ、それによってより質の高いテストと有意義なフィードバックが得られます。
  
• デザインハンドオフでは、エンジニアがレポジトリからコンポーネントをコピー＆ペーストし、JSX/CSSをわずかに変更することで、新しい製品や機能を構築することができます。
  
• QA（品質保証）では、プロトタイプと最終製品が同じ忠実度と機能であるため、エラーが少なくなり、つまり手直しや人件費、ユーザビリティの問題やサポートチケットが少なくなるということになります。

組織全体に大きな価値をもたらすツールで、デザインを最適化しませんか？UXPin Merge の詳細と、この画期的なテクノロジーへのアクセスをリクエストする方法は、コチラをぜひ覧ください。

The post デザインROI – デザイン投資の 価値 を算出する方法 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.

UXPinによって顧客のデザイン体験がどのように改善されたかについてフィードバックを受けると、私たちはいつもワクワクします。その顧客が世界最大のデジタル決済プラットフォームの１つであれば、特別感はなおさらです。

今回、PayPal のデベロッパーツールおよびプラットフォームエクスペリエンス担当のシニアマネージャーであるエリカ・ライダー氏と、彼女のチームのシニアUX デザイナーであるアンソニー・ハンド氏にお話を伺うことができたのでご紹介します。

エリカは、PayPal で解決しなければならなかったデザイン上の課題、すなわちデザイン、製品、開発の間のギャップを埋めることについて、彼女自身の言葉で説明しています。

多くの企業では、デザイナーとデベロッパーの比率は、「デベロッパー１０人」に対して「デザイナー１人」ですが、PayPal では、「１０００人以上のデベロッパー」に対して「デザイナー５人」です。

PayPal はこの課題を克服するためのツールや戦略を必要としていました。そこで、彼らは UXPin Merge に注目し、DesignOps のプロセスを改善しました。

彼女とPayPal のデザインチームが、UXPin Mergeを使ってどのようにデザインと開発のプロセスに革命を起こしたかを、これからご紹介します。

体験談を動画で見る 

PayPalの主な２つの課題

 デザイン拡張 の課題：

私を含め、５人のデザイナーからなる小さなデザインチームがあり、６０〜１００の製品と、１０００人を超えるデベロッパーを担当しています。

このような大きな組織を支える小さなデザインチームとして、私たちは革新的な問題解決のアプローチを開発しなければいけませんでした。デザイナー増員の予算は確保できないので、デザインそのものをスケールアップする方法を考えなければならなかったのです

一貫性の課題：

PayPal の製品チームには、経験豊富な UX 担当者やUIデベロッパーはおらず、その結果、さまざまなユーザビリティとデザインの一貫性に問題が生じ、製品がどれ１つとして同じにならなくなってしまいました。

そこで私は、まとまりのある一貫したユーザー体験を生み出すという、難しい仕事を任されましたが、３人のデザイナーと無限の製品チームからなる私たちは、従来のようなモデルで規模を拡大するのは無理だと思いました。加えて、デザイナーの増員が問題解決になるとも思えませんでした。

製品チームを成功に導くには、私たちにはデザインの拡張が必要だったのです。

今までは…

PayPalが使ってみたツール

まず、製品チームは自分たちで製品をデザインしないといけないことが分かっていたので、私たちはさまざまなツールを検討し、まずはデザインシステムや規格がある従来型のモデルから始めました。

最初の考えは、デザインについて製品チームを教育しながら、従来のデザインアプローチを適応させることでしたが、ドキュメント作成、サポートの提供、デザインツールの学習曲線をたった３人のデザイナーで行うとなると、従来のモデルではうまくいかないことにすぐに気づきました。

製品チームが製品をうまくデザインするには、彼らが学ぶべきツールやスキルを最小限に抑える必要があったのです。

従来のやり方

従来の UX プロセスでは、デザイナーがベクターベースのモックアップを作成し、それをデベロッパーに渡していましたが、残念ながらこのプロセスでは、コンポーネントがどのように機能することになっているかと、そこにあるべきコンポーネントの間にギャップが生じてしまいます。

その結果、デザイナーとエンジニアの間で「デザインはどうあるべきか」、「プロトタイプはどうあるべきか」を明確にするために、何度もやり取りをすることになり、デベロッパーは、製品の見た目や機能だけを考えていたため、デザイナーに思いもよらない質問を重ねることになってしまいます。

UXPin Mergeの導入

製品チームが製品をデザインするには、このデザイナーとデベロッパーのギャップを最小限に抑え、連携を改善する必要がありました。

PayPal に入社する数年前、私には「デザインの効果的な拡張には、デベロッパーやプロダクトマネージャーを  デザインプロセス に関わらせないといけない」という持論がありましたが、それを行う方法は知りませんでした。何をするかは分かっていたのに、どのようにするかは分かっていなかったのです。

ですがMergeとUXPinに出会ったことで、デザインと開発のギャップを埋める方法を理解する道が開かれ、PayPal の デザインプロセス 改善のきっかけとなりました。

従来の DesignOps のプロセスは、スケーリングに関するものであり、通常はデベロッパー１０人に対してデザイナー１人という割合が一般的です。まずデザイナーを追加し、次に大規模なデザインチームを収容するためのサポートインフラを構築します。

社内組織として、従来のデザイナーとデベロッパーの比率である１対１０にスケールアップするためのリソースが得られないことは分かっていたので、デザイナーを増やすことなく、デザインの課題を解決するための革新的なソリューションを見つけなければいけませんでした。

UXPin Mergeの仕組み

PayPalの消費者向けアプリ、サービス、Venmo、その他の外部サービスは、すべて異なる技術が使われています。社内ツールの開発には、より企業向けに特化し、社内のユーザーインターフェースに適していることから、『Microsoft のフルーエントデザインシステム』と 『UIコントロール』を採用しました。

UXPin Mergeがあれば、Microsoft の フルーエントデザインシステムを Githubレポに入れ、コンポーネントを UXPinのデザインエディタにインポートすることができるようになります。そしてこのUXPin Merge のセットアップを使って、製品チームは、エンジニアが DevOps ツールの開発に使っているコンポーネントとUIコントロールを正確に活用したプロトタイプをデザインすることができます。

たとえば、UXPinのエディタでキャンバス上のボタンをレンダリングすると、ホバー/クリック効果、フォント スタイル、その他のメトリクスを含め、デベロッパーツールでレンダリングしたものとまったく同じになります。UXPin Mergeでデザインすると、PayPal のときよりもはるかに忠実なプロトタイプを作成できるのです。

Mergeを使った感想

最初の展開で、UXPin Mergeを使うことでデザインにかかる時間を大幅に短縮できることが分かっていました。

すると PayPalの上級管理職から、「UXPin Mergeを使った場合」と「従来のデザインモデルを使った場合」の時間短縮の比較をしてほしいという依頼がありました。

そこで、あるデザイナーに単一ページの比較テストを選んでもらいました。PayPal で使っている別のデザインツールで、ベクターベースのデザインを１ページ行い、UXPinで当社のMergeコンポーネントライブラリを使って、まったく同じプロトタイプを作成しました。この２つのツールは、時間面でどのように比較されるでしょうか？

結果：Mergeを使った場合、デザイナーは約８分かかりましたが、他のデザインツールを使用した場合は、同じプロトタイプに 1 時間以上かかったのです! これは、私たちが比較対象として選んだツールを使い慣れている、能力を持った経験豊富なデザイナーによるものであることに留意してください。

ベクターベースのデザインツールを製品チームに提供するのは気が進みませんでした。彼らはデザインを始める前に、ドキュメントを整備し、ツールの使い方を学ばないといけませんでしたから。たとえトレーニングに時間がかかったとしても、経験豊富なデザイナーの能力に達することはできなかったでしょうし、同じプロトタイプを１時間でデザインすることもできなかったでしょう。

UXPin Mergeを使えば、プロダクトマネージャーの一部は、同じようなプロトタイプ１ページを８～１０分で作れます – UXPinの経験豊富なデザイナーにかかる時間と同じです！

以前は、限られたリソースとデザイナーで、１ページの製品を作るのに、モックアップのデザインだけで２〜３カ月かかっていましたが、今は、プロダクトチームが同じ時間内に製品をデザインし、提供することができます。

UXPin Mergeが与える大きな影響

UXPin Merge の大きな影響の１つは、より忠実度の高いプロトタイプを作成できるようになった点です。デザイナー、経営陣、ディレクター、デベロッパーなど、すべての人が最終製品の外観、UX、インタラクティブ性についてより確信が持てるようになり、それによってステークホルダーからより質の高いフィードバックを得ることができるようになりました。

経営幹部やディレクターは、こういったプロトタイプの機能と目標を実際に体験することから、最終的な方向性について、たとえば「このようなボックスがどのようにテキストフィールドのように見えないか」について単にコメントするのではなく、より強力なフィードバックをしてくれるようになりました。

Merge で UXPin を使うようになってから、私のデザイン哲学と生産性は格段に上がりました。３０分以内にプロトタイプを実装できる自信があります。ちなみに、以前使っていたツールでは半日かかっていましたからね。

フィードバック：UXPinを使うことで、ステークホルダーはかなり迅速なフィードバックの提供ができます。彼らにプロトタイプのリンクを送ると、好きな時間にプロトタイプで遊んでもらい、UXPinでプロトタイプに直接コメントを記入してもらうことができます。UXPinのコメント機能は、私たちの対応後に、コメントを【解決済み】としてマークする点が素晴らしいですね。

製品の質：この新しい UXPinのアプローチでは、より協力的で統合的なデザインプロセスが実現されます。デザイン、プロトタイプ、開発を別々にするのではなく、UXPinによって、プロセス全体を通してエンジニアリングと製品チームが関与する統合的なフローを作り出すことができ、その結果、製品の最終的な品質が劇的に上がりました。

ユーザーテスト：UXPinで作成した忠実度の高いプロトタイプは、私たちにはとても便利です。忠実度の高いプロトタイプをより早く作成でき、セッション後にすぐにフィードバックが得られます。そしてすぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。

UXPinは、コンセプトから忠実度の高いプロトタイピングまで、即座に対応できるツールを提供します。UXPin Merge を使って、高度なプロトタイピングとテストがデザイン プロセスをどのように変えるかをぜひご覧ください。

 PayPalが再定義したデザインプロセス

 PayPalのDesignOpsは、エンド・ツー・エンドのプロセスです。

1. 製品チームはユーザーを十分に理解するのが必須である
2. ユーザーのニーズに基づいた製品をデザインする
3. ドメインエキスパートが、彼らの知識とテストに基づいてデザインを完成できるようにする
4. デザインの成功を検証する

社内の共通の課題として、製品チームが UX デザインをボトルネックとして捉えていることがよくあります。そこで私たちの戦略は、まずそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにすることから始めました。

そこで私たちは、このような「スナップ・トゥギャザー」型のデザインを実現できるUXPin Mergeを使うことでそれを実現しました。ドラッグ＆ドロップでユーザーインターフェイスを構築できるコンポーネントが製品チームに提供されます。

製品チームは、余白や構成要素を固定したレイアウトを作成することができ、すべてが想定通りに表示され、機能するようになりました。デザイナーは、何も取り締まる必要も、製品デザインのために介入する必要もありませんでした。

製品チームが標準的なデザイン原則に従っていないときや、大変な問題で行き詰まったときは、デザイナーは今でも製品チームを手伝っていますが、製品チームは作業の９０％を自分たちで行うことができるため、デザイナーはより大局的なデザインの問題に集中することができます。

成果

顧客中心

私自身、顧客中心やデザイン主導というのは、デザイナーが常にリードしているという風には考えていませんし、組織の誰もが、デザイン主導とはどういう意味なのかを理解しています。

私達は PayPal でデザインをするとき、あっちこっちの小さな問題に焦点を当てるのではなく、グローバルレベル、組織全体、製品ライン全体で問題を解決することに重点を置いています。

小さなコーナーケースだけでなく、PayPal の製品すべてで一貫性のある体験がユーザーに提供されないといけないのです。

PayPal のプロダクトチームとドメインの専門家がデザインをしている間、我が UX チームはメンターやコーチとして動きます。以前は UX デザイナーが１製品、あるいは１ドメインを担当していましたが、Design Ops 2.0では、製品デザイナーが一度に１０～１５種類の製品を担当するようになりました。

企業における教育 

UX デザイナーがプロダクトチームを指導する場合、より良いレイアウトやプロダクトをデザインするためのガイダンスを配るだけでなく、デザイン思考を教えることもあります。

デザイン思考は UIデザインだけでなく、完全な UX を考えることです。API のレスポンスタイムは UX にどのような影響を与えるでしょうか？レイテンシーは UX にどのような影響を与えるのでしょうかか？

私たちは、UIのトップレベルからのデザイン思考を求めており、製品チームがエンドユーザーのために適切な判断を下せるように、全員に UX の影響を理解してほしいと思っています。

重要なことに集中する

我がデザインチームは、さまざまな製品チームのサポートに５０％の時間を費やし、残りの５０％は、グローバルな組織に影響を与える大きなUXイニシアチブに費やしています。

こうした UXの取り組みには、以下のようなものがあります：

• 「プラットフォーム上でのユーザー間の信頼関係の構築法」といったことに重点を置くか。
• プラットフォーム上でいかにしてユーザー間の本質的な繋がりを築くか。
• どのようにすれば、すべての製品にユーザー調査を組み込むことができるか。- 調査ではなく、ユーザーがどのように製品を使い、どこにギャップがあり、それをどのように修正し、そのデータを製品チームに提供するにはどうすればいいかのの理解である。

将来への投資

デザインプロセスの拡張は、長い目で見れば投資となります。デザインと開発のライフサイクル全体を俯瞰し、それが現在どのような状態になっているかを把握し、「このステップは長すぎる」ではなく、「どうすれば短縮できるか」を考えるには、経験豊かなチームが必要です。

すべての技術を構築する最初のプロセスは長い時間のように思えますが、実は長い目で見れば、開発、デザイン、開発プロセスの全てにおいて、かなりの時間を節約することができるのです。

UXPin Mergeとデザインプロセス 

もし UXPin Mergeが世界最大のデジタル金融プラットフォームの複雑なデザイン問題を解決できたとしたら、これがあなたのビジネスだとどうなるかを想像してみてください。

PayPal はMergeを使って Git レポジトリから UXPinとReactコンポーネントを同期しましたが、MergeはStorybookとの統合も可能であり、Vue や Angular など、さらに多くのフレームワークにアクセスすることができます。

  デザインプロセスの速度を上げる準備はいいですか？

The post PayPalがUXPin Mergeで デザインプロセス を拡張した方法 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.

ゼロからデザインシステムを作成する場合でも、フロントエンド開発のまとまりと一貫性を高めたい場合でも、コンポーネントライブラリの作成は、製品のUX（ユーザーエクスペリエンス）を上げるにはいい方法です。

コンポーネントライブラリは、長い目で見れば大幅な時間短縮になりますが、ゼロから作成するには多くのリソースと細部への配慮が必要です。なのでエンジニアは、コンポーネントライブラリの拡張性を確保するのに、製品の現在の優先順位と将来の可能性を考慮しなければいけません。

UXPin Merge があれば、コンポーネント ライブラリから作成した UI 要素を使って、デザイン エディタにインポートしてもその機能を維持したまま、完全に機能するプロトタイプを作成することができ、デザインおよび開発全体で『信頼できる唯一の情報源（Single source of truth）』を共有できます。詳細およびアクセス権のリクエストについては、Mergeの ページをぜひご覧ください。

コンポーネントライブラリで、フロントエンドのまとまりと一貫性を上げるためにコードを統一でき、また、新製品や新機能をリリースするためにデベロッパーが書かないといけないコードの量を最小限に抑えることができます。

多くのエンジニアは、以下のようなよくある問題いくつかのうち１つを認識して、コンポーネントライブラリの構築を決定します：

• UI の不整合：同じコンポーネントに複数のバリエーションが存在する
• プログラミング構文とマークアップの不整合：コードの書き方や構造が違う
• 増え続けるフロントエンドの負債：プログラミングのバグと修正によるバックログ
• 冗長なプログラミングやワークフローによる納期遅れ

  コンポーネントライブラリは、このような問題を解決または軽減し、エンジニアリングチームにスケーラブルなフロントエンドのフレームワークを提供することを目的としています。

ステップ１：インターフェースのインベントリの作成

  インターフェースのインベントリまたは UI 監査は、重要な最初のステップです。監査によって、エンジニアがコンポーネントライブラリの作成前に対処しなければならない多くの UI とプログラミングの不整合が発見されることがよくあります。そのような不整合は、わずかに異なる2つのHEXコードのような微妙な場合もあれば、さまざまなサイズ、形状、色、CTA（Call To Action）など、複数のボタンのバリエーションのような明白な場合もあります。

デザインシステムの専門家であるブラッド・フロスト氏は、ユーザーインターフェースのスクリーンショットをすべて撮り、各コンポーネントを切り出すことを推奨しています。面倒で時間のかかる作業ですが、棚卸しには欠かせない作業です。顧客が見ているものを正確に伝え、エラーや矛盾を明らかにすることができるので、プロジェクトファイルに頼るのではなく、実際の製品の中で行うことが重要です。

コンポーネントをカテゴリに分類して、何を扱っているのかを確認します。そしてそのカテゴリは、コンポーネントライブラリの基礎となります。

コンポーネントの種類の分類にお困りの場合は、GoogleのマテリアルデザインやAppleのヒューマンインターフェースのガイドラインのようにやってみることを検討してみましょう。あるいは、アトミックデザインを使ってUI要素を整理するのもいいでしょう。

また、インターフェース・インベントリは、コンポーネントライブラリをステークホルダーにアピールするためのいい材料にもなります。このような不整合を示すのは、問題の規模やコンポーネントライブラリのリソースを割り当てる必要性を示すのに最適な方法になることがよくあります。

ステップ２．ツールとフレームワークの選択

  何を作るかが決まったら、その作り方を決めないといけません。React、Angular、Vueなど、Javascriptのフレームワークを使っている場合は、Storybookを使って個々のコンポーネントを開発・管理することをお勧めします。

Storybookでは、エンジニアがコンポーネントを分離して作成し、テストすることができます。また、ドキュメントの作成、開発ワークフローの設定、エンジニアやステークホルダーとの連携も可能です。

デザインと開発の同期

Storybookのさらなる利点は、コンポーネント駆動型プロトタイプのためのテクノロジーであるUXPin Mergeと同期することです。なので、コンポーネントライブラリが完成したら、デザインチームが完全に機能するプロトタイプを作成できるように、それをUXPinに接続することができるのです。

Merge は UX デザイナーのためだけのものではありません。例えばTeamPassword にはデザイン チームがないため、ユーザー インターフェースのプロトタイプ作成とテストは、２名からなるエンジニアリング チームが行う必要があります。TeamPassword は以前はコードを書くことでこの作業を行っていましたが、プロトタイプとテストをもっと速くできる方法を求めていました。

そしてTeamPasswordは、Merge技術を使ってカスタムMUIコンポーネントライブラリをUXPinに同期させ、そこでプロトタイプの作成とテストを行うようになりました。

「完成したデザインを製品化するまでのプロセスも、とても速くなりました。すべての仕様と製品化可能なコードを含むプロトタイプをとても速くエクスポートでき、それによって、チームが通常フロントエンドのコードを書くのに費やさなければならない時間が節約されます。」

ステップ３． コンポーネントの入手

  インターフェース監査で作成したコンポーネントと対応するカテゴリのリストで、いよいよコンポーネントライブラリの作成に取り掛かります。ー でも、どこから手を付けましょう？ ここでは、ゼロからコンポーネントライブラリを作成するためのテクニックをご紹介します。また、Storybookでライブラリを開発するための技術的なリソースもご紹介します。

ブラッド・フロスト氏の『アトミックデザイン』の方法論に従って、コンポーネントを一から開発することをお勧めします。この方法は、新しいパターンを作成し、コンポーネントライブラリを拡張するためのモジュラーシステムを作ります。  

原子

  原子（Atom）は、これ以上分解することができないコンポーネントであり、コンポーネントライブラリの残りの部分のためのビルディングブロックや依存関係でもあります。原子には以下のようなものがあります：  

• ラベル
• 入力欄
• ボタン
• カラーパレット
• フォント
• アイコン
• アニメーション
• デザイントークン

分子

  複数の原子が組み合わさって分子を構成し、フォーム、タブ、アコーディオンなど、ユーザーが操作する個々の UI コンポーネントができあがります。例えば、検索のコンポーネントは、【ラベル】＋【テキストフィールド】＋【ボタン】になります。

生体

  生体は、２つ以上の分子を組み合わせた UI パターンであり、一般的な例として、以下のようなナビゲーションバーが挙げられます：

• ロゴマーク （分子）
• ナビゲーションのリンク（分子）
• 検索バー（分子）

テンプレート

  テンプレートには、複数の生物と分子が搭載され、完全なユーザーインターフェースが構成されています。このようなテンプレートで、冗長なワークフローが排除され、製品をより速やかに提供できるようになります。以下に例をいくつか挙げてみましょう：

• 管理者用のUI
• 企業のダッシュボード
• 製品のニュースフィード
• Eコマースのショッピングカート

デザイントークン

  デザイントークンは、スケーラブルなクロスプラットフォームのコンポーネント ライブラリの作成に重要であり、そのようなトークンには、UI コンポーネントをスタイリングするための、色、間隔、タイポグラフィー、アセット、アニメーションなどの UI データが含まれています。

１つのトークンには、各プラットフォーム用にフォーマットされたプロパティが含まれており、例えば、Android、iOS、ウェブブラウザには、以下のようにそれぞれ違った測定単位が使われています：

• ウェブサイト、ウェブアプリケーション（pixels/em/rem）：１ピクセル
• Android（密度非依存ピクセル(dp) /dip）：１ピクセル＝１dp
• iOS（ポイント(pt)）：１ピクセル＝０.７５pt

  エンジニアは、各測定単位に対応したトークンをプログラムすることで、あらゆるOSで一貫性を確保することができます。

また、デザイントークンによって、アップデートもより簡単になり、複数のファイルを修正する代わりに、エンジニアはトークンを更新してクロスプラットフォームの変更を行えます。

最初からデザイントークンを作成することで、コンポーネントライブラリを作成する際の冗長な作業が削減され、コードの将来性が確保されるのです。

ドキュメンテーションを忘れずに！

  コンポーネントライブラリをゼロから作成した人たちから最もよく勧められるのがドキュメントです。コンポーネントライブラリのドキュメントで、他のエンジニアにコンポーネントの開発・保守の方法が伝えられ、連携がしやすくなります。

各コンポーネントが完成したら、その記憶が新しいうちに文書化すべきです。さらに、変更もすべて文書化が必要です。

Vaadinのミカエル・スコーイネン氏は、各コンポーネントを以下のように文書化することを推奨しています：

• 概要：コンポーネントの名前と説明
• 説明：コンポーネントのインストール方法と使用方法
• 視覚的な例：コンポーネントの使用例を示す
• コードサンプル: コンポーネントのAPIの使用方法

また、ドキュメントには、以下も含まれなければいけません：  

• HTML、CSS、Javascriptのガイドライン
• コンポーネントのテスト
• Reactコンポーネントのprops（StorybookではArgs）の説明
• バージョン管理
• 共同作業の方法と共有方法（Jira、Trello、Notionなどのプロジェクト管理ツール）

Storybookでのコンポーネント ライブラリ の作成

  ここでは、コンポーネントライブラリを作成するためのテクニカルガイドをご紹介します：  

• How To Build JS Components with Storybook
• Build a React Native component library with Storybook
• How to Build a Component Library with Angular and Storybook
• Building a Component Library with React and Storybook
• Build a Component Library with Storybook（ステップ・バイ・ステップガイド）
• Atomic Design Systems: A Checklist for Each Individual Design Component
• 商品開発プロセスを改善する Storybook の ベストプラクティス
• コンポーネントライブラリを作成するためのStorybookフレームワーク

オープンソースの コンポーネントライブラリ の活用による作成の高速化

  オープンソースのコンポーネントライブラリには、コンポーネントライブラリを高速に作成するための基盤があります。また、デベロッパー間の摩擦や議論に何時間も必要とされるプロセスである、拡張性のあるシンタックスで、エンジニアにもメリットがあります。

カスタマイズは、オープンソースの コンポーネントライブラリを選択する際に考慮すべき最も重要な点です。ライブラリは、できればデザイントークンを通じて確実にテーマ性を持っているようにしましょう。また、全体的なドキュメントで定期的にメンテナンスされているものがいいでしょう。

オープンソースの コンポーネントライブラリ はテーマ化が可能ですが、独自の美観を得るためのカスタマイズには限界があります。また、ライブラリの構文や設計言語にも制約されるので、最終決定する前によく調べましょう。

UXPinにおけるMergeを使ったプロトタイプとテスト

  Storybookはコンポーネントの単独での作成や、内的なテストにはいいツールですが、ユーザーテストについてはどうでしょう？残念ながら、Storybookはブラウザやモバイルデバイスでのユーザビリティテストに関して制限があります。

確かに、コードでプロトタイプを作ることはできますが、変更やイテレーションを行うには時間がかかります。

Merge を使うと、新しいコンポーネント ライブラリをテストするためのプロトタイプを作成することができるように、コンポーネントライブラリをレポジトリからUXPinのデザインエディタにインポートすることができます。さらに、Mergeはドラッグ＆ドロップでプロトタイプ作成環境を作成するため、従来のデザインツールに必要な急な学習曲線が不要になります。

このプロトタイプのワークフローは、テック業界大手の PayPal と、従業員５人のスタートアップである TeamPassword でうまくいきました。おもしろいことに、両社とも UX のスケーラビリティの問題から Merge に切り替えており、両社では、デザイン経験のほとんどないチームが Merge を使ってプロトタイプやテストなどの UX タスクを完了させているのです。

PayPalでは、６０以上の製品を５人のUXデザイナーと１,０００人以上のエンジニアで対応していましたが、UXPin Mergeに切り替えた後、（デザインツールの経験がない）PayPalの製品チームは、経験豊富なUXデザイナーが画像ベースのツールを使うよりも８倍速く、デザインプロジェクトの９０％を完了させました。

資金に余裕がないスタートアップ企業である TeamPasswordには、UX チームのリソースがありませんが、競争力を高めるには UX が重要であるのはわかっていました。そこでMerge は TeamPassword の ２人構成のエンジニアリング チームに、エンドユーザーと共にユーザー インターフェースのプロトタイプ作成とテストを行うプラットフォームを提供し、UX デザイナーの穴を埋めました。PayPal のように、TeamPassword は Merge を使って製品と機能をより速く提供しています。

 コンポーネントライブラリ の作成には、かなりのリソースが必要ですが、多くの場合、エンジニアはUXチームにアクセスできず、デザインツールを使ってコンポーネントを作成およびテストする知識もありません。そこでUXPin Mergeが、デザインと開発の間のギャップを埋めることで、デザイナーとエンジニアが同じ言語で会話できるようにします。

UXPin Mergeは、デザイナーがデザインプロジェクトにおいて優れたプロトタイプを作成し、より多くの問題を解決するお手伝いをしますが、エンジニアがUXのリソースを持たない状況でもプロトタイプやテストを行えるようにすることもできます。

StorybookとUXPin Mergeを使って コンポーネントライブラリ を作成しませんか。Mergのページで詳細とアクセスリクエストの方法をぜひご覧ください。

The post コンポーネントライブラリ初心者向けの作成ガイド appeared first on Studio by UXPin.

これまで、デザイナーとデベロッパーの連携をしやすくする方法について見てきました。では、その連携をダメにする障壁やワークフローは何でしょうか？  

筆者たちは、デザインチームやプロダクトマネージャーがソフトウェアエンジニアと仕事をする際に陥りがちな間違いや、どうすればもっといい連携ができるかを調べ、摩擦や障害を減らすことで、よりスムーズな製品開発プロセスが実現し、デザインの価値も上がることがわかりました。  

UXPin Mergeで連携を強化し、デザインと開発の間のギャップを埋めませんか。この技術によって、コンポーネントライブラリの要素のUXPinへの取込や、機能的なプロトタイプの作成、デザイン通りの開発が実現します。詳しくは Mergeのページをぜひご覧ください。  

間違い１： 画像ベースのプロトタイプの使用

  初期段階のスタートアップ企業であれ、企業のソフトウェア開発チームであれ、デザインハンドオフはデザイナーとエンジニアの間でよく摩擦が起こりますが、この緊張の最大の原因の1つは、「プロトタイプの忠実度」にあります。  

画像ベースのデザインツールだと、忠実度や機能性に欠けたお粗末なプロトタイプができ、それによってエンジニアやステークホルダー、ユーザビリティ担当者は解釈や理解がし辛くなります。  

そこでデザインチームには2つの解決策があります：  

1. フロントエンドデザイナーやUXエンジニアと連携し、もっといいプロトタイプを構築する。
2. コードベースのデザインツールに変更する

  ​​後者は、よりスムーズなデザインのハンドオフのためにエンジニアリングチームへの依存の解消やプロトタイプの能力の大幅な向上、テストの改善、デザイナーとデベロッパーの連携の促進を実現することから、こちらの方が解決策です。

コードベースのデザインツールを使うメリット

UXPinのコードベースのデザインツールで、デザイナーは最終的な製品体験を正確に再現するプロトタイプを作成することができます。

UXPinの完全にインタラクティブなプロトタイプは、コードに匹敵する体験を提供するため、エンジニアやステークホルダーは、何かをすることを「想像」する必要がありません。

以下に、プロトタイプを強化するUXPinの機能を４つご紹介します：

• ステート：1つの要素やコンポーネントに複数のステートを適用し、それぞれに異なるプロパティ、インタラクション、アニメーションを設定できる。
• インタラクション：高度なアニメーションと条件付きフォーマットを使って複雑なインタラクションを作成し、ダイナミックなユーザー体験を実現。
• 変数：ユーザーの入力を取得・保存し、その情報を使ってアクションを起こしたり、製品フローを個別化する。
• エクスプレッション：Javascriptのような機能で、フォームの作成、パスワードの検証、ショッピングカートの更新などを行うことができる。

無料トライアルにサインアップして、このような機能やその他のUXPinの高度な機能をぜひご確認ください。

間違い２：デザイン上の意思決定が明確でない

デザイナーがやりがちな最大の間違いのひとつは、デザイン決定の背景にある「なぜ」を明確にしないことです。あなたが解決しようとしているユーザーの問題を知らずに、エンジニアはどうやって理解や共感ができるのでしょうか？

デザイン上の決定を明確にする鍵は、積極的な行動です。デザインプロセスを通じてデベロッパーを呼び込み関わらせて、不意なデザインハンドオフを防ぐのです。

デザイナーでありビジネスリーダーでもあるアントニア・ホルヴァス氏は、連携の改善や、エンジニアをデザインの決定に参加させるための素晴らしいアドバイスを以下のようにしています：  

• デザインと開発の組合せ：デザイナーは、デザインハンドオフ後に、プロセスを理解してエンジニアリングの課題を観察すべく、エンジニアが機能を構築するのを見ます。理想としては、このプロセスは、両方のチームメンバーが同じ画面の前でライブで質問したり回答したりしながら、直接行うのが最も効果的です。
• 一緒にアイデアを出す：アイデア出しのセッションにエンジニアを参加させることで、デザイン決定の裏にある思考プロセスを理解し、技術的なノウハウを活かしてアイデアを改善することができます。
• デザイン評論：従来はデザインチームの”儀式”でしたが、この一風変わった評論にエンジニアを参加させることで、新鮮な視点からの新しいアイデアを得ることができ、また、意思決定の背景にあるデザイン思考のプロセスを理解することで、エンジニアにもメリットがあります。
• デザイナー／エンジニアの振返り：アジャイルソフトウェア開発のプラクティスで、各イテレーションの成果を振り返り、改善点を議論するものです。デザイナーとエンジニアは、毎回のリリース終了時に振り返りを実施し、デザインハンドオフのペインポイントと解決策を特定するといいでしょう。

間違い３：UXについてエンジニアを教育していない

  一般に信じられていることとは異なり、UXチームは製品のUX（ユーザーエクスペリエンス）に単独で責任を負うのではなく、組織全体で責任を負うのですが、UXデザイナーによる効果的なデザイン提唱がなければ、誰もUXについて進んで学ぼうとはしないでしょう。   PayPalのUX Lead EPXであるエリカ・ライダー氏は２０２２年のデザインバリュー会議で、「企業には以下のような多大な”コントロールと管理責任の不均衡”がある 。」と指摘しました。  

• UXデザイナーは、ユーザーに提供するUXに関するコントロールは皆無なのに、管理責任を１００％負う。
• エンジニアは、ユーザーに提供するUXに対する管理責任は皆無なのに、１００％のコントロールを担う。

  UXチームの役割は、エンジニアにUXを教育し、両部門で責任を分担することです。  

そこでエリカは、「UXチームはエンジニアと協力してPayPalの優れたユーザー体験を提供するが、最終的な製品についてはエンジニアが責任を負う」ことを保証するためのシステムを開発しました。  

最大のハードルのひとつは、意識改革です。UX以外の誰もが、デザイナーの役割は見た目とUIのデザインだと考えていますからね。  

エリカの教育方法は、エンジニアのUXに対する考え方を、「美的感覚に優れたUI（ユーザーインターフェース）」から、「エンジニアが絶対的にコントロールできるボトルネックやロードブロックを引き起こす問題」へとシフトさせることでした。その例として、以下のようなものがあります：  

• レイテンシー：ボタンをクリックしても読み込みに時間がかかるようでは、お粗末なUXである。
• 可用性：URLが読み込まれないのは、お粗末なUXである。
• セキュリティ：もし誰かが自分のアカウントをハッキングしたら、それは最悪なUXである！
• 「人間が読める」ものではない、あるいはユーザーが解決する術のないエラーメッセージ：【エラーコード1578-B1273 – 失敗！】のように、その意味も解決方法も告げずにメッセージをユーザーに見せるのもまた、お粗末UXである。

  組織全体で、まずはエンジニアからUXの考え方を身につけていくことで、ユーザーへの共感を高めつつ、責任を分担することができます。

間違い４：ユーザー調査の結果を共有しない

UXツールの記事で、テイラー・パーマー氏がエンジニアへのインタビューから得た 「ユーザー調査でより良いエクスペリエンスを生み出す方法 」についてのインサイトが紹介されています。

エンジニアがユーザー調査を重視するのは、デザイン上の意思決定を理解し、あるデベロッパーが言うように「正しいものを確実に作っているようにするため」です。

デベロッパーは、デザインチームのユーザー調査のアーカイブにアクセスする必要はありませんし、ユーザーインタビューに同席する時間もありません。彼らにとっては、要約やメモ、録音されたインタビューなどの方がいいです。

ユーザー調査をエンジニアリングチームと共有する方法

テイラー・パーマー氏は、UXリサーチをエンジニアと共有するためのアイデアを以下のようにまとめました：

• 研究プロジェクトやインサイトを共有するためのミーティング
• エンジニアが “なぜ “を理解できるように、デザインファイルと研究概要をリンクさせる
• インタビューやユーザビリティスタディのためのオープンなポリシー作成
• ワイヤーフレーム、モックアップ、プロトタイプ（低再現性と高再現性）を含むどのUXアーティファクトにも対するフィードバックの取得
• 社内調査のレポジトリの作成と共有 – 必要に応じてエンジニアがリサーチを深く掘り下げられるよう、サマリー以上の情報を提供
• デザインミーティングやアイデア出しのメモの共有
• 定期的なユーザー体験のニュースレターの作成

間違い５：信頼できる唯一の情報源（Single source of truth）がない

製品開発チームにとって最も大きな課題の1つは、デザイナーとエンジニアの間のバラバラな”連携”を解決することです。

デザイナーとエンジニアは、完全に統合されたデザインシステムからの「信頼できる唯一の情報源（Single source of truth）」なしで、異なる言語を話します。するとどうなるでしょう？

弱い連携、デザインドリフト、摩擦などが起きUXや製品品質に悪影響を及ぼしてしまいます。

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

デザインシステムを構築しても、信頼できる唯一の情報源（Single source of truth）が1つになるとは限りません。従来のデザインシステム構築の方法では、以下のようにデザイナーとエンジニアがそれぞれ別の【真実】を使うことになります。

• デザイナーはUIキットや画像ベースのデザインシステムを使用
• エンジニアはコードのコンポーネントライブラリを使用

デザインシステムの成熟度を示す4つのステージのうち、このステージは3番目であり、4番目に行くには、デザイナーとエンジニアが同じコンポーネントライブラリを使うような、デザインと開発のギャップを埋めるツールが必要です。

Iress社のデザインシステムプロダクトオーナー兼プロダクトデザイン地域責任者のニック・エリオット氏は、以下のような第4段階を「完全統合」と呼んでいます：

• コード（又はノーコード）でデザイン: デザイナーはレポジトリにあるコードコンポーネントを使って、ドラッグ＆ドロップでUIを構築。– ゼロからのデザインは不要
• デザインドリフトがない：UXチーム、プロダクトデザイナー、エンジニアが全く同じコンポーネントを使うため、デザインドリフトがなくなり、UX/フロントエンドの負債は少なくなる。
• 一貫したデザイン：コンポーネントにはデザインシステムで確定されたプロパティとインタラクティビティが含まれているので、デザイナーは色、タイポグラフィー、ステートなどをの検討は不要。
• シームレスな引き継ぎ（又は引き継ぎなし）：エンジニアはすでにプロトタイプに使うすべてのコンポーネントの正確なコピーを持っており、フロントエンドの開発では、リポジトリからコピー＆ペーストするだけでよく、それによってコードを書く必要性が軽減される。

そこでIressは、UXPin Mergeを使ってデザインと開発を同期させました。MergeはIressのコンポーネントライブラリをレポジトリからUXPinに取り込み、デザイナーはコードを見ることも書くこともなく、最終製品のような外観と感触のコードベースのプロトタイプを作成できるのです！

この共有された「信頼できる唯一の情報源（Single source of truth）」は、デザイナーとエンジニアが同じ言語を話し、同じ技術的制約の中で作業するということであり、その結果、摩擦の減少やワークフローの効率化が実現するのです。詳細とアクセスのリクエスト方法については、Mergeのページをぜひご覧ください。

UXPin Mergeがデザインと開発を同期させてより良い連携を実現する方法

結論を聞いたことはあると思いますが、UXPin Mergeはどのように機能するのでしょうか？Mergeを使うと、組織はレポジトリからUXPinのデザインエディタにデザインシステムを同期させることができます。

組織は、React、Angular、Vue、Ember、HTMLなど、他のフロントエンド技術用のGit 統合またはStorybookを使って、ReactデザインシステムをUXPinに直接接続することができます。

コンポーネントライブラリはUXPinの左サイドバーに表示され、デザイナーがキャンバス上に要素をドラッグしてプロトタイプを始められるようになっており、各UIコンポーネントには、色、サイズ、タイポグラフィ、ステートなど、デザインシステムで確定されたプロパティが含まれています。

デザイナーは、プロパティパネルでドロップダウンとセレクタを使って、これを切り替えることができ、変更はJSXとしてレンダリングされるので、エンジニアはコピー＆ペーストで簡単に開発プロセスを始められます。

製品開発チーム全体が同じ言語で会話できるように、UXPin Merge のコードベースのデザイン ソリューションを使いませんか。詳細およびこの革新的なテクノロジーへのアクセス要求方法については、Mergeのページをぜひご覧ください。

The post デザイナーとデベロッパーの連携をダメにする5つの間違い appeared first on Studio by UXPin.

多くの企業が、レガシーシステム（旧式システム）とそれに伴う頭痛の種からの解放に四苦八苦しています。時代遅れのエコシステムには、UX（ユーザーエクスペリエンス）やデジタルイノベーションなど、多くの課題があるのです。  

チャレンジャーバンク（銀行免許をとって銀行サービスをはじめる事業者）が従来の銀行と競争し、洗練されたテクノロジーを採用し、顧客により速く商品を提供できる理由は、レガシーテクノロジーの負担にあります。  

本記事では、レガシーシステムが抱える課題と、それがビジネスやCX（顧客体験）に及ぼす悪影響について探ります。また、こうしたレガシーの負担がないFinTech企業が従来の金融サービス事業者をどのように凌いでいるか、そして従来の金融サービス事業者が現代化のために何ができるかを見ていきます。  

UXPin Merge で UXのワークフローを現代化してデザインと開発の間に「信頼できる唯一の情報源（Single souce of truth）」を作成することにより、製品がより速やかに提供され、市場投入までの時間が短縮されます。詳細およびアクセス権のリクエスト方法については、Merge ページをぜひご覧ください。  

レガシーシステムとは

  レガシーシステムとは、組織がまだ使っているハードウェアやソフトウェア、その他の時代遅れのテクノロジーのことであり、レガシーシステムを構築した企業は、大抵もはやビジネスを行っていないか、製品のアップデートやサポートの提供を停止しています。  

アップデートやサポートがない場合、組織はレガシーシステムの維持と運用のためにIT専門家を雇わなければなりません。そのようなシステムのための人材プールは小さいので、労働力は高価であり、さらに部品は手に入りにくいので、大抵は高いコストでハードウェアの代替品を製造しなければいけません。

レガシーシステムは、かなりのスペースも必要です。多くの組織では、30～50年前のシステムで運用されており、そのようなレガシーシステムのハードウェアはかさばるため、効率的な運用と維持には大きなスペースが必要となります。またデータの整合性や、システムクラッシュ時にすべてを失わないようにすることにも気を配らなければなりません。なんせレガシーシステムはクラッシュしますからね！  

銀行部門や政府機関では、いまだにレガシーシステムが広く使われています。レガシーシステムは維持費が高いだけでなく、セキュリティ上のリスクもすごいです。

Forbesの記事によると、米国連邦政府のシステムのほとんどが時代遅れになっており、例えば米国財務省のシステムは「５１年もの」と最も古いシステムの一つで、次いで保健福祉省の「５０年もの」となっています。  

レガシーシステムとUX

  このような技術的な問題は、粘着テープとガムで固定されたバックエンドのために優れたUX（ユーザーエクスペリエンス）をデザインしようとするUXデザイナーの課題となっており、そしてレガシーシステムには、製品チームにとって以下のような重要な課題がいくつかあります：  

• 劣悪なパフォーマンス：フロントエンドのアプリケーションは、レガシーシステムへのAPI（アプリケーション・プログラミング・インターフェース）の呼び出しを待たなければいけない。
• スケーラビリティの限界：レガシーシステムがイノベーションを阻害している。
• お粗末なクロスプラットフォーム体験：モバイルバンキングアプリとデスクトップアプリケーションでできることが制限されている。
• 予算の制約：レガシーバンキングシステムは高価である、つまり、UXやデジタル製品のイノベーションに回すことができる貴重なリソースを消費していることになる。
• サイロと官僚主義：動きの速いFinTechスタートアップやテクノロジーを取り入れた金融機関との競争が難しくなる。
• セキュリティ上の制約：レガシーシステムは攻撃に対して脆弱であり、それでさらに複雑さと制約が増す。

FinTechを成功に導く要因

  FinTech製品は、レガシーシステムを運用する組織と同じ問題を解決しますが、制約が少ないため、競争することができます。   ここでは、FinTechが数十年の経験と専門知識を持つ多国籍金融機関を凌ぐ方法をいくつかご紹介します。  

1. FinTechの動きは速い

  市場投入までのスピードは、FinTechの最大の強みの1つです。最新のテクノロジーや効率的なワークフローがあり、サイロや官僚主義がないため、FinTech製品チームはイノベーションを起こし、プロジェクトを速やかに提供することができるのです。  

また、FinTech企業はML（機械学習）、ブロックチェーン、AI（人工知能）などの新しい技術を自由に試して採用することができ、商品の品質と顧客満足度を大幅に上げることができます。

この効率性により、Robinhoodのようなアプリ優先の投資商品や、Monzo、Chime、Nubankなどのデジタルバンキング提供会社が成功を収めています。彼らは、絶えず革新を続ける洗練されたアプリケーションを通じて、顧客に同等の金融商品を提供しているのです。  

従来の金融機関は、市場投入が遅く、迅速で機敏なFinTech組織から常に２歩は遅れているため、競争に勝てないのです。  

2. ユーザー中心

  FinTech企業は、意思決定とイノベーションにおいて、ユーザー中心の考え方を採用しています。彼らは、最新のデジタルソフトウェア開発、特にUXとデザイン思考に通じているため、従来の金融機関よりもユーザーのニーズがよくわかっています。

このユーザー中心のアプローチにより、FinTech企業は顧客のニーズを優先し、期待に応えるコアとなるバンキング製品に集中することができ、より良い信頼、採択、定着を生み出すことができるのです。  

3. より良いデータ分析

  レガシーシステムの金融機関にとって、データの完全性と品質は重要な問題です。レガシーシステムは、全体的なリアルタイム分析を妨げ、それによって意思決定とイノベーションに遅れが出ます。  

一方、最新のFinTech企業では、高品質のリアルタイムでのエンドツーエンド分析により、問題や機会を特定することができます。

このような貴重なインサイトにより、ステークホルダーは、企業のビジョン、ロードマップ、顧客の期待に沿った賢明な意思決定を行えるのです。  

4. UXリサーチとユーザーテスト

  UXリサーチとユーザーテストは、FinTech企業で採用されているユーザー中心のデザインの一面です。このような貴重なUXインサイトと質の高い分析を組み合わせることで、FinTech企業はより詳細で全体的な顧客のペルソナを手に入れることができます。  

このように顧客の行動を深く理解することで、FinTechのデザイナーは、独自のビジネスチャンスを特定しながら、ユーザーのニーズを満たす製品やサービスの優先順位を決めることができるのです。  

5. 機能横断的な製品開発

  うまくいっているFinTech企業の多くは、アジャイル環境と機能横断的な製品開発チームを利用しています。このような現代のワークフローで、サイロの最小化やチームの調整、さらにエラー（UX負債／技術的負債）の削減や、より速くて正確なプロジェクトデリバリの促進が実現されます。

また、FinTech企業はリモートワーク環境に精通しており、グローバルな人材プールを活用し、より迅速に人材を確保することができます。  

従来の金融機関では、サイロ化が進み、規制要件や会社の方針により、人材の採用やチーム作りに時間がかかっていました。

レガシーシステムの現代化にデザイナーができること

1. 測定とレポート

  以下のような測定とレポートは、レガシーシステムの現代化には欠かせない要素です：

• UX監査：レガシーシステムに関連するユーザビリティの問題を特定し、無策の年間コストを測定する。
• カスタマージャーニーマッピング：FinTech Magazineは、高速カスタマージャーニーの最適化を中心としたレガシーシステムの近代化に対する3つのステッからなるアプローチを推奨している。
• ユーザーテストとUXリサーチ：テスト、インタビュー、リサーチを通じてユーザーを理解するために、より多くの時間をかける。
• UX競合分析：競合他社について調べ、顧客がなぜその製品を選んだのかを学ぶ
• サービスサファリ：チームメンバーに自社製品や競合他社製品を使用してもらい、ユーザー視点でのインサイトを得る。

  こういった方法論の使用は、最初のステップに過ぎません。デザインチームは、このようなインサイトを用いて、ステークホルダーに定量的なデータを提示する必要があります。以下に例を挙げましょう。

 レガシーシステムによるUXの低下がもたらすコストは、そして現代化によって期待できるリターンとは？  

Talabatの製品チームは、デザインシステムへの投資獲得ために戦ったとき、フロントエンドの負債にかかるコストを中心にビジネスケースを構築しました。チームは、デザインシステムを使う場合と使わない場合のUI開発にかかる時間を測定しました。その結果、Talabatのフロントエンドの負債が大幅に削減され、それによってステークホルダーを説得し、製品のデザインシステムへの投資を得ることができたのです。  

問題と解決策には、ビジネスケースをサポートするための数字が含まれていなければなりません。ステークホルダーは、以下のような評価するためのメトリクスやKPI（重要業績評価指標）を見たいのです。  

• 問題の状態と規模
• ソリューションが数値を改善する方法

2. デザイン思考を用いた効率的な優先順位付け

  デザイナーは、デザイン思考を使って、プロジェクトの優先順位決めやビジネス価値を最大化する機会の特定を行うことができます。望ましさ、実行可能性、実現可能性のバランスを見つけることは、長期的な成長と成功を持続させる革新的な製品のための効果的な研究手法です。  

• 望ましさ：顧客にとって「要る」ものか「欲しい」ものか。人は「要る」がないと生きていけないから、そこにより価値がある
• 実行可能性：会社にその余裕があるか、ビジネスとして成立しているか。
• 実現可能性：構築のためのリソースがあるか？ビジネスに適しているか？そして、実現までにどれくらいの時間がかかるか？

  この三位一体の芯の部分を見つけることで、顧客ニーズを解決しながらビジネス価値を最大化することができます。成功には、組織全体がデザイン思考とUXの原則を受け入れなければならないのです。  

デザイン提唱やデザイン思考のワークショップは、チームメンバーやステークホルダーの賛同を得、現代のユーザー中心的な考え方に舵を切るために非常に重要です。  

レガシーに制約のある機関がこうしたデザイン思考の原則を採用すれば、ユーザーやビジネスを犠牲にしてまで「古いやり方」を正当化するのは難しくなります。

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

  レガシーシステムを含め、多くの組織がいまだにデザインシステムなしで運営されています。「現代的」なデジタル決済の大手であるPayPalでさえ、社内製品にデザインシステムを採用したのは2019年になってからだそうです！

デザインシステムは、組織全体で「信頼できる唯一の情報源（Single source of truth）」を確保することができます。製品開発ワークフローを効率化し、結束力と一貫性を最大限に高めることで、ユーザビリティの問題が軽減され、デザイナーはプロジェクトごとにコンポーネントを構築するのではなく、ユーザーの問題解決に集中することができます。  

信頼できる唯一の情報源（Single source of truth）では、企業の従来の課題を解決できませんが、動きの遅い金融機関にとって重大な問題である、ワークフローの最新化や、市場投入までの時間短縮のための一歩となります。  

UXPin MergeによるDX（デジタルトランスフォーメーション）

UXPin Mergeは、レガシーシステムを現代化して市場投入までの時間を短縮するための優れたツールです。2019年にUXPin Mergeを採用した後、PayPalのプロダクトデザイナーは、以前より8倍速くUIを構築できるようになりました。  

また、Merge は PayPal の開発プロセスに革命をもたらし、UX チームのメンバーを新たに雇うことなくデザイン出力を拡張しました。これは、予算の制約に苦しんでいる組織にとって重要な要素です!  

デザイン・開発の同期化

  PayPalのUXリードEPXであるエリカ・ライダー氏は、MicrosoftのFluent UIデザインシステムを選択しました。DSチームはカスタムコンポーネントとテンプレートを作成し、デザイナーは要素をドラッグ＆ドロップするだけでUI（ユーザーインターフェース）を構築できるようにしました。彼女が言うように、”パチパチ留める “タイプのデザインです。

PayPalはMergeを使ってFluent UI ReactライブラリをUXPinと同期させたので、デザイナーはすべて同じコンポーネントを使えるようにしました。また、React のプロップを使って、デザイナーがUXPinのプロパティパネルで調整するスタイルとインタラクティビティの制約を設定しました。  

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

  Mergeのデザインハンドオフはシームレスで、ほとんど存在しません。多くの組織が新製品や新機能をリリースする際に対処する混乱した状況とは大違いです。

デザイナーとプログラマーが同じコンポーネントライブラリを使うため、ほとんどのフロントエンド開発はコピー＆ペーストとデザインに合わせたプロップの調整です。UXPinにはJSXのコードがあるので、デザイナーもそれをコピーできるのです！  

最小限のデザインとゼロからのコーディングにより、エラーや技術的負債、市場投入までの時間が削減され、連携とUXがよくなります。  

時代遅れのビジネスプロセスやレガシーシステムが、UXチームの競争力や顧客の期待に応える能力に影響を及ぼしていませんか？UXPin Merge を使って、製品開発ワークフローを強化し、より優れたUXを顧客に提供するための信頼できる唯一の情報源（Single source of truth）を作りましょう。詳細およびアクセス権のリクエスト方法については、Merge ページをぜひご覧ください。  

The post FinTech（フィンテック）のレガシーシステムの対処方法とは？ appeared first on Studio by UXPin.

デザインシステムは、デザイン作業を最初から最後まで強化および管理するための完全な標準セットを提供しますが、機能的なデザインシステムを構築して維持するには、まずはきちんと時間と労力をかけないと、効果的に行きません。  

本記事では、デザインシステムの文書化について紐解いていき、デザインシステムにおける文書化の必要性を探り、効果的なデザインシステムの文書化基盤を構築するためのステップについて見ていきます。  

デザインシステムの文書化とは

  デザインシステムの文書化は、デザインチームが使用ガイドラインを組み合わせて提示するのをサポートするのに使える貴重なリソースであり、このようなルールを共有、利用、実行することもできます。これにより、デザイナーとデベロッパーは、より予測可能なUIを提供するための作業をモデル化することができるのです。  

本題に入る前に、デザインシステムの文書化とはどのようなものかを簡単にご説明します。  

一般的なデザインシステムは、UIデザイン要素やその他のコンポーネント、ワークフローを含むコンポーネントライブラリで構成されています。このように、デザインシステムは、パターンライブラリやスタイルガイドを統一し、一つのまとまったエクスペリエンスを提供するものです。  

Blink UX社のプリンシパルUXデザイナー兼パートナーであるハイディ・アドキソン氏によると、デザイン文書のバリエーションはさまざまですが、よりタスクに特化したタイプとしては、以下のようなものがあります：  

• ユーザーストーリー：デザイナーのユーザーニーズの視点に基づいたアプローチを可能にする
• 画面遷移図：ユーザーが画面間をどのように移動するかを示すのに最適
• ユースケース：より長く、より客観的な物語を提供し、将来的に大きな利益をもたらす
• ページレベルの文書：ページの機能、目的、およびデモの手順の概要についての説明
• シナリオナレーション：具体的な作業の進め方を中心とした、説明的なナレーションの概要

  他にも、構造的な観点からの文書に関連するデザイン文書の種類で、以下のようなものがよくあります：

• オブジェクトモデル：システムの構造的なビューの提供
• アーキテクチャマップ： アプリやサイトが一般的にどのような構造になっているかを伝える
• 標準化されたコンポーネント：システム全体で共有される標準化された要素についての説明
• システム用語集：特定の単語、フレーズ、およびその他の関連するシステム固有の言語がリストアップされている
• ナビゲーションフレームワーク ：メニュー項目、ナビゲーション要素、および制御機構についての説明

デザインの文書化が必要な理由

  デザインの文書化は、今日、あらゆるデザインシステムにおいて不可欠な要素であり、コンテキストの提供からチームの調整作業の説明、システムのコンポーネント ライブラリの明確な記録の維持まで、コンポーネントの文書化はデザインを成功させるための基本になっています。  

デザインシステムの文書化は、かつて「重要でない」とされ、見過ごされがちでした。ステークホルダーは、デザインシステムの文書化の可能性に触れることもなく、文書がもたらす価値についてはさっぱりわかりませんでした。

  Googleのマテリアルデザインの登場後、デザイン文書が重要であることがすぐに明らかになりました。大体のデザイン文書は、無秩序なメモや箇条書きで構成されており、重要な情報のほとんどが抜け落ちていました。そこでマテリアルデザインはその状況を一変させ、必要な構造を追加し、文書化の必要性を保証してくれたのです。  

デザインシステムの文書化には、以下のように多くの利点があります：  

• チームが同意するビジョンの提供：書面での技術的な指示ではなく、人に焦点を当てたデザイン文書を作成することで、チームが集中力を欠いたときに参照することができる明確なビジョンを設定できる。
•  デザインシステムに明確で重要な構造を与える：プロセスの把握によって、デザイナーとデベロッパーは、アイデアや一般的な目的として存在するのではなく、目の前に提示された計画に頼ることができる。
•  リソースの節約： 優れた高品質の文書のデザインインフラストラクチャは、コストのかかる試行錯誤のミスの削減や、チームの時間と労力の最適化、再利用可能なデザインパターン記録の後々の再現を可能にする。
•  エンゲージメントと満足度の向上：大きなプロジェクトは、チームにとって大きな負担となることがあるが、効果的なデザイン文書を作成することで、困難な状況下でも信頼できる、現実的な目標が与えられる。
•  効率と生産性の向上：チームが必要とするすべてのものが文書化され、利用可能になることで、全員が同じ見解を持ちながら、物事をより迅速に進めることができる。

  効果的なデザイン文書がなければ、製品のデザインと市場投入の成功はほぼ不可能です。デザインシステムの文書化は、特定デザイン決定の根拠を提供し、ユーザーがモデルを理解し、操作できるようにすることで、必要不可欠なものとなりました。  

デザインシステムの文書作成の9ステップ

1. エンドユーザーを理解する

  デザインシステムの文書化の第一歩は、このような作業を行う市場、つまりユーザーを見ることから始まります。ユーザーが何を求めているかがわからなければ、デザインの目標や結果を大きく誤る可能性があります。  

文書は「製品」であり、チームはその製品の「消費者」である、と分類して考えてください。誰がこのドキュメントを使うのか、彼らが求めているコンテキストを提供するには何が含まれる必要があるのか、どのように構成すれば消費しやすいのかに焦点を当てましょう。  

2. 各コンポーネントの文書化の必要性を概説する

  次に、各コンポーネントのニーズを網羅するアウトラインの確立が必要であり、以下のようなデザインのガイドラインを含める必要があります。  

• パターン
• コード・スニペット
• 色
• 画像
• フォント 
• ADAコンプライアンスガイドラインなど

  コンポーネントの文書化は、他のデザイン要素との関連性を考慮した上で概要を検討する前に、何よりもまず組織のニーズを考慮する必要があります。

3. スタイルガイドを作る

スタイルガイドで、文書の視覚的プレゼンテーションの基礎を確立でき、デザインシステムのビジュアルとコンテンツ要素のガイドラインがもたらされます。スタイルガイドは、まず他のデザイン文書の要素を見て、色やロゴの目立ち方、全体の語調などを記述し、最終的には、他の人が使うためのテンプレートとしての役割を果たします。 

4. チームで共有できる再利用可能なテンプレートを作る

そして、チームで共有しながら何度も再利用できるような文書のテンプレートの作成が必要です。再利用可能な文書のテンプレートがあれば、チームの時間が節約され、一貫性を保ち、誰もが自分の見ているものを理解できるようになります。

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

信頼できる唯一の情報源（Single source of truth）の確立、明確化および文書化は、おそらく製品デザインの最も重要な要素の1つであり、この普遍的に承認された合意は、デザインチームが作業するすべてのものの中心になります。アイコンや配色、文字の大きさやボタンなど、すべての人が「こうあるべき」と理解していれば、物事はよりスムーズに運びます。

UXPinなどのツールで作成したコンポーネントライブラリにある基本的なデザインコンポーネントから始めるか、Reactコンポーネントで起源を確定して開発段階から始めるか、どちらかです。例えば、UXPinでは、UXPin Mergeのデザインシステムのバージョン管理により、会社全体の一貫性を確保することができます。

プロジェクトに取り組む際に、チームがデザインするための信頼できる唯一の情報源（Single source of truth）を作り続けましょう。UXPin Mergeはデザインシステムのバージョン管理を提供し、それによって信頼できる唯一の情報源（Single source of truth）のデザインアプローチが最適化され、コード駆動型プロトタイプの管理ができます。UXPinのようなツールでは、作り込まれたオープンソースライブラリの利用や、Git、Storybook、NPMの統合による独自のデザインシステムのインポートができます。

6. スターターキットを同梱する

デザインキットは、見落とされがちな「優れたデザインシステムの文書化を構成する要素」ですが、こういった必要なリソースは、優れたUX（ユーザーエクスペリエンス）に不可欠な「出発点」の要素を表しています。スターターキットは、オンボーディングツールとして最適で、ステップバイステップのガイドラインから高度なユーザーマニュアルまで柔軟に対応します。 

7. フィードバックを集める

フィードバックで、デザインシステムがうまく機能している時と、そうでないときを知ることができます。例えば、フィードバックを集める仕組みをGitHubの課題に限定している組織がありますが、これは、デザイナーや技術的な専門性の低いロールプレイヤーが意見を述べにくくなってしまいます。

文書化サイトのフィードバックボックスのようなフィードバックの代替収集手段だと、ユーザーが問題を記述して送信することができます。GitHub の問題を開く必要がない効率的なフィードバックチャネルにより、フィードバックが必要な場合は、文書化プラットフォームを通じて、速やかにに行うことができます。

8. 責任を分散させる

文書化は、ボランティアでやってくれる人がいつでもいるとは限らない、手間のかかる作業ですが、その重要性をチームに伝えることで、文書を作成することの価値を理解してもらうことができます。一人に負担をかけるのではなく、チーム内で分担することを検討しましょう。そうすれば、さまざまな気づきが得られるだけでなく、タスクも達成しやすくなります。

9. 定期的に更新する

デザインシステムは、メンテナンスされ、清潔に保たれ、適切である必要があります。潜在的な問題領域の特定や矛盾の削減、有効なシステムの数の効率化に継続的に注意しましょう。

いい例として、文書化サイトやデザインシステムのコンポーネントに対して、Reactストーリーのコード例を「信頼できる唯一の情報源（Single source of truth）」として確立し、定期的に更新して、互いの整合性を確保するというのがあります。

また、UXPinには定期的なアップデート機能備わっており、デザインシステムからマスターコンポーネントを変更した場合、システム内ですぐに更新することができ、すべてが完全に整合された状態を維持することができます。  

デザインシステムでプロトタイプを作ろう

  健全なデザインシステムは、コンポーネントライブラリを充実させ、信頼できる唯一の情報源（Single source of truth）を中心に展開する、明確で曖昧さのないコンポーネント文書によるサポートが必要です。  

一般的ないいプラクティスのルールとして、文書が全てです。文書によって進捗状況、マイルストーン、勝ち負けの追跡、過去に遡っての見直し及び学習ができ、そして何より、人はデザインシステムそのものを理解し、それに従うことができるようになります。  

デザイン システムの実装の確認が必要ですか？Mergeテクノロジーを搭載したUXPinでは、デザインシステムのUIコンポーネントをプロトタイプで使えます。UXPinにインポートし、デザインエディターでドラッグ＆ドロップして、完成品のような一貫性のあるプロトタイプを作成しましょう。 UXPin Mergeについてもっと読む。  

The post デザインシステムを文書化する簡単な９ステップ appeared first on Studio by UXPin.

誰もが知っている従来の「労働」は、ここ2、3年で劇的に変化しました。世界中のオフィスがバーチャルワークスペースやハイブリッドワークスペースを取り入れた働き方にシフトしていき、そのような変化は新しい考え方や働き方をもたらし、従業員と企業の成功に有益であることが証明されました。  

多くの人にとって、オフィスを離れることでより自律的になり、ワークライフバランスも良くなります。直接的にせよ間接的にせよ、従業員の幸せは企業の成功につながる傾向があります。良い姿勢と前向きなリーダーシップは、そのための直接的な橋渡しとなるのです。では、このような考え方は、デザインリーダーシップにどのように反映されるのでしょうか。  

主なポイント

• いい雰囲気で統合されたチームは、より多くのイノベーションを生み出し、個人は自らのデザイン能力に自信を持ち、参加者は増えていく。
• いちいち細かい管理や、何をすべきかを全員に指示することなくチームが機能するところまで到達できれば完璧。
• 権限を与えられたリーダーは、最終的にデザインの世界にポジティブな革新と変化をもたらす。もし、次のステップに進むべきか迷っていたら、人は本来励まされ、従事していると感じたときに最高の仕事を完成させるということを思い出すといい。
• まずは自ら切り込み、自身の決断を振り返る：その決断はチームの助けになったか、それとも進行を妨げたか？
• 行動計画を作成する：目標達成のために何を変えるべきか、どのようなリソースが必要かを決定する。
• 変更を加えつつ、それが思うようにいくかどうかを観察する。必要なら反復する。

もしあなたが現在デザインリーダーで、チームを効果的に管理し、ビジネスを成功させる方法をお探しでしたら、良いデザインチーム構造を作るためにできる重要なステップをいくつか見ていきましょう。本記事では、デザインリーダーシップとは何か、そしてそれをどのようにあなたの デザインチーム やビジネスに適切に適用できるかを探ります。

チームのワークフローを最適化し、より良いコミュニケーションを実現するプロトタイピングツールをお探しでしたら、UXPin Mergeがピッタリです。UXPin Mergeは、チームがより高いレベルのデザイン成熟度をすぐに達成できる強力なテクノロジーです。インタラクティブなUI要素を含む高忠実度のプロトタイプをデザインし、デザインプロセスの連携がどれだけ上がるかをぜひご確認ください。UXPin Mergeについてもっとみる

 デザインチーム の管理 – 正しく行うために重要なステップ 

デザインリーダーシップとは、すべてのステップをいちいち細かく管理することではなく、優れたデザインリーダーは、むしろチームに対してインパクトのある指示を出すことができます。では、具体的にどのようにすれば、有意義なプロダクトデザインの職場環境が実現されるのでしょうか。

まずは、 デザインチーム をうまく管理するための重要なステップと、結束力のあるチームを作るために避けるべきことを見ていきましょう。  

ステップ１：デザイン部門の監査から始める

  UXデザインの監査から始めるように、目標を振り返ってみましょう。ロードマップの作成によって、組織におけるデザイン目標における達成すべきことがより明確に見えてきます。このロードマップで、道のりの凸凹が少なくなり目標に到達しやすくなります。  

次のステップでは、 デザインチーム の構造を全体的に監査します。チーム内にどのような人材がいるのかを把握し、その強みと弱みを確認するのです。こういったことの把握により、会社の目標達成のために必要な、適切なスキルを持ったメンバーが十分にいるかどうかがわかります。  

チーム全体をより深く理解するには、チームミーティングがいい方法です。さらに、デザインチームの監査は、日々の業務全体がどの程度うまくいくかを判断する上で非常に有効です。

監査によってチーム構造が明確になり、すべてのチームメンバーの役割と、彼らが役割を果たすために期待される能力を特定できます。明確化することで、全員に高い目的意識を持たせることができ、混乱や滞りなく一貫したタスクが設定されます。  

ステップ2：自分の間違いを確認し、認める。

  デザインチームのリーダーとしてチームを管理する際には、誠実な考え方を取り入れる必要があります。リーダーシップを発揮する上で、先天的な思い込みや古い思い込みはつきものですが、緊密なチームの雰囲気の中で働く場合、外部からのアウトプットは非常に貴重なものとなるのです。  

チームメンバーからのフィードバックという形で、外部からの意見をどんどん求めましょう。その際、匿名のアンケートや、毎日一緒に働いている人たちから情報を集めるための全員参加の電話でもかまいません。

厳しい意見を聞くのは大変ですが、そのような意見を直接メモすることは、チーム全体の強化につながります。リーダーシップの不足部分はさまざまな形で表れ、例えば、チームの明確な目標設定の度重なる失敗や、従業員に対して細かく管理しがちであるといった指摘がチームから来るかもしれません。  

どんな欠点があるにせよ、デザインリードとして少し工夫が必要なところは積極的に確認し、認めるようにしましょう。あなたやチームのメンバーも含めて、完璧な人間なんていないですからね。

ステップ３：やるべきことの計画を書く

  チームを成功に導くために、リーダーシップスタイルの改善や計画の立案と同様に重要なのが、プロジェクト管理に関わる要素であり、これはデザイン監査と密接に関係しています。把握したい質問としては、「増員は必要ですか？だとしたら、現在のチーム構成の中で、どのスキルのギャップを埋める必要があるか分かりますか？」などがあります。  

関連する項目として、スキルギャップ評価の実施が挙げられます。チームメンバーに得意なスキルを聞いてみましょう。直接聞いてみることで、これまであまり意識されていなかったスキルや、今後のデザインプロジェクトに役立つスキルが見つかるかもしれません。

チームメンバーとの1対1のミーティングやグループミーティングでは、これから伸ばしたいスキルについて質問するのもいいでしょう。そうすることで、彼らが望むキャリアパスとデザインチーム全体のコンピテンシーをどのように統合するかを計画することができます。スキルのギャップを埋めるために、チームメンバーがスキルを磨き、開発する方法を提案しましょう。

企画段階では、募集・採用の段階で、デザインチームづくりがうまくいっているかどうかの確認が重要です。遅れをとっている分野があればメモをしておき、以下を考えてみましょう：

• 候補生の離職率が高くなっているか
• オンボーディングプロセスで、新入社員が繰り返し質問をし続けることがあるか

  このような質問と、タスクの配分、仕事量の管理、一貫したパフォーマンスなど、その他の潜在的な改善点を検討しましょう。  

ステップ４：成果の測定法を決める

  このような項目を把握し、具体的な変更が実施されたら、その変更をどのように評価するのか、しっかりとした計画がいると考えるでしょう。実施した変革が成功したかどうかを測るのに必要なのです。  

成果の全体的な成功を評価するとき、以下を自分自身に問いかけてみてください：

• 問題を解決できたか？：デザインとは、単なるグラフィックやカラーパレットではなく、その核心は、クリエイティブなチャンネルを通じて、相互作用と問題解決を促すことなのです。もしあなたが、例えば従業員の定着率の低さなどの現実の問題を特定し、よりオープンなコミュニケーションとフィードバックなどのより良い解決策を提供したのなら、それは成功と言えるでしょう。　
• プロセスを改善したか：デザインは、必ずしも補足に関するものである必要はなく、むしろ、調査中に冗長で役に立たなかったステップが特定されるかもしれません。優れたデザイン・リーダーシップとは、うまくいっていないものを切り捨てたり、取り除いたりすることもあるかもしれません。様々な開発ルートを通じてプロセスをより効率的にしたのなら、よかったですね、またひとつうまくいきましたよ！
• フィードバックに対してオープンだったか： デザインの成功は、まさに従業員と経営陣の個人的な成長であり、効果的なコミュニケーションを通じて示すことができます。フィードバックを受け入れてオープンなコミュニケーションをとることは、なかなか習得しにくいスキルですが、優秀なリーダーなら誰にでもあるはずです。プライドを捨て、率直なフィードバックを受けましょう。あなたもチームも、もっと良くなるはずです。

オススメの測定方法は、改善しようと計画している特定の領域によって異なります。例えば、自身のデザインリーダーとしての資質を測りたいのであれば、職場について従業員がどう感じているかを測るメトリクスである「従業員NPS（ネットプロモータースコア）」などの定量調査を実施するといいでしょう。

このようなアンケートを実施することで、例えば3ヶ月や6ヶ月間でスコアがどのように変化したかを確認することができます。これは単なる一つの手段ですが、従業員の満足度を見るのによく行われる方法です。  

例えば、チームメンバーの定着率を上げて離職を防ぎたいと考えていたら、従業員の適切な定着のために必要な措置を講じた後、特定の行動項目を実施した後に平均在職期間がどのように変化したかを測るといいでしょう。  

あるいは、2週間という時間枠の中で、チームがどのくらいのタスクをきちんと完了したか測定したい場合は、このようなメトリクスを隔月で比較するといいでしょう。測定は、さまざまな影響要因にアプローチする現実的な方法がある「フィボナッチ数列のポイント」を通してアプローチできます。  

ステップ５：トランスフォーメーションプロセスの開始  

これで、デザインチームの働き方の効率化ができるようになりました。上記のステップを要約して実行すると、次のようになります：  

• １対１のミーティング：チームリーダーとチームメンバーの報告者が緊急の問題について個別に連絡を取り合い、強い関係を構築するには、１対１でのミーティングがいい方法です。また、このミーティングによって、従業員は自分が製品チームの重要な貢献者であると感じ、目標に向かってきちんと仕事をこなし、スキルも上がっていることを確認することもできます。1対1は、現状報告としてではなく、定期的にフィードバックを行い、キャリアアップや新しいスキルの習得を促すプラットフォームとして活用すべきです。
• 毎日のスタンダップ：デイリースタンドアップでもハドル会議と呼ばれるものでも、その考え方は同じです。スタンダップでチーム全体が情報を共有し、つながっていることを実感できるようにすることで、進捗状況の把握、必要な改善点や未解決の問題の明確化、仕事の完了状況についてのチームの状況の把握ができます。
• チームビルディング活動：士気を高め、チームワークを活発にするためのさまざまな活動があり、コミュニケーションを前面に押し出し、製品チームの連携を自由な流れにし、最高の職場の雰囲気を作り出すのに使えます。チームビルディングで、プロダクトマネージャーと従業員が、従来の職場環境以外で互いのことをより深く知ることができるかもしれません。脱出ゲームやゴルフコースでの1日など、楽しくて魅力的なアクティビティになるといいですね。

チームの成功には、成長と連携が欠かせません。当社のDesignOps eBookの最初の柱で説明したように、デザインチームの幸福度は、経営計画の最重要事項であるべきです。上記のステップは、チームが成長し、大切にされていると感じる事ができるようになるための、提案の一つに過ぎません。

ステップ6：反復の力を見逃さない. 

  成長は一筋縄ではいきません。なので定期的にチームメンバーとのコミュニケーションを取るようにしましょう。そうすることで、何がうまくいっているのか、どんなやり方がうまくいっていないのかが見えてきます。そうなると、そこからが巻き返しのチャンスです。

ここでもまた、チームメンバーに率直なフィードバックを求めましょう。それは、対面式の会議でもアンケートでも構いません。オープンなコミュニケーションは、デザインプロセスや製品開発のワークフローを円滑に進める上で理想的な環境であり、気づきを得た従業員は、最終的に評価されていると感じるのです。一般論ではなく、明確なアクションに焦点を当てることを忘れないでください。具体的に掘り下げることで、誰もがより良い結果を得ることができます。  

アンケートを実施する場合は、頻度を上げ過ぎないように注意しましょう。データを収集した期間が短すぎて適切な結論を導き出せない可能性や、チームメンバーにあなたの決断を頻繁に評価してもらうことは、あなたがデザインリーダーとしての能力に自信がないと思われる可能性があります。デザインリーダーとして進むべき方向性を明確にすることで、チームはそれを評価してくれるはずです。

チームの連携とデザインチームの管理方法を改善するために、繰り返し実験しましょう。適切なデザインチームの管理は長距離走であり、短距離走ではないことを忘れないで下さい。良いチームを育てるには、試行錯誤が必要なのです。  

チームを成功に導こう

DesignOpsの第一の柱は、優れたビジネスの核となる「人」を扱うことです。  

従業員をサポートしたいのであれば、その仕事に適した技術スタックが必要です。UXPin Mergeはそのような技術であり、これを使えば、デベロッパーのインタラクティブなコンポーネントをデザインエディターに持ってきて、ステークホルダー、プロダクトマネージャー、そして何よりもデベロッパーが理解しやすいプロトタイプを構築することがでます。コミュニケーションのギャップを埋め、組織内のワークフローを強化しましょう。UXPin Mergeについてもっと読む

The post デザインチーム を効果的に管理する方法とは appeared first on Studio by UXPin.

デザインコンサルタントは以前から存在しており、企業が外部のサービス会社や代理店にデザインコンサルティングを依頼することは昔からありました。  

しかし、デザイン変更管理が進化し、現代のデザイン思考がデザインチームと他部門との統合方法を変えるにつれ、このようなデザイン業界の役割は、さまざまな刺激的な可能性と利益をもたらしてくれるようになりました。  

本記事では、社内デザインコンサルタントが業界で果たす役割が大きくなっていることにスポットを当て、デザイン品質やデザインチームのパフォーマンスにどのようなプラスの影響を与えているのかお話します。  

ここでは、社内デザインコンサルタントがこれらのチームとどのように融合し、デザイン品質にどのようなメリットをもたらしているかを探るとともに、効果的な社内デザインコンサルティングを立ち上げるためのステップについてみていきましょう。  

デザインコンサルティングの立ち上げと運営に必要な時間を獲得する方法は、現在のワークフローの改善であり、そのうちひとつが、プロトタイピングとデザインのハンドオフプロセスをスピードアップする技術を試してみることです。それにはまさにUXPin Mergeがピッタリです。企業がフロントエンドの負債と戦い、自身のデザインシステムに基づいた製品を開発するのをUXPinがどのようにサポートするか、詳しくはこちらをご覧ください。

社内デザインコンサルタントとは

  まずは、デザインコンサルタントのコンセプトと、コンサルタントがどのように組織内の問題解決者として機能し、実行可能なデジタルデザインソリューションを特定・実行するのかについてみていきましょう。  

社内デザインコンサルタントとは、デザイン会社の中で、アイデアの提案、推奨や監査の実行、既存のデザインシステムへの助言を行う機能であると言えます。  

デジタル製品のデザインの形状や機能性から、美観や市場性まで、社内デザインコンサルタントは、これらの特徴や要素が互いにどのように融合しているかを把握しています。

このようなコンサルタントは、デザインチームの中での重要な役割をいくつか担い、以下を行うことによってその専門知識を提供し、付加価値を高めています：  

• デザインチームのメンバーが検討し、最善の決断ができるようサポート
• 潜在的な解決策や代替案について、常にチームに情報を提供し、最新情報を入手
• デザインフレームワークを使って業務プロセスやタスクの効率化をサポート

  効果的なデザイン戦略の策定により、チーム全体のパフォーマンスとアウトプットをモニタリングし、改善します。   さらにデザインコンサルタントは以下を日常業務としています：  

• デザインワークショップの企画・運営
• 組織的なデザインシステム構築の監修
• デザインのアイデア出しや実行に必要な経験や意見の追加

社内デザインコンサルタントと社外デザインコンサルタント

  社内デザインコンサルタントは社外デザインコンサルタントとほぼ同じですが、デザイン会社の業務やチームダイナミクスにおいて遥かにいい見解があります。そして社内デザインコンサルタントと社外デザインコンサルタントの違いは、クライアント企業との関係にあります。  

• 社内デザインコンサルタント：クライアント企業にフルタイムまたは契約ベースで雇用され、クライアント企業に直接報告する。雇用主のために継続的に働き、組織内の製品デザインに特化し、企業の経営陣やデザインチームと長期的な関係を築く。
• 社外デザインコンサルタント ：デザインコンサルティング会社から来て、指定されたデザイン関連のプロジェクトやタスクの完了のために短期間雇われる。大抵は社外のコンサルティングやデザインサービスに雇われ、複数の組織のプロジェクトに同時に取り組み、自身の経験やより広いビジネス視点に基づいたアイデアをもたらす。ちなみに、Ideoがイノベーションのコンサルティング会社として有名なのは聞いたことがあるかもしれないが、この会社はパロアルトに拠点を置き、多くのスタートアップ企業のデザインへの取り組みをサポートした。

つまり、社内デザインコンサルタントは自社専属で、通常、長期的なプロジェクトに参加します。一方、社外デザインコンサルタントは、代理店から派遣され、短期間の仕事でサポートします。  

社内デザインコンサルタントの利点

1. 一貫性と明瞭性の確保

  外部のコンサルタントを入れるたびに製品デザインチームのワークフローが混乱するのではなく、製品デザイン活動の中で社内デザインコンサルタントが機能するように投資することは、誰にでも一貫性と明瞭性があるということです。

これには、共感、定義、アイデア出し、プロトタイピング、テストを柱とするデザイン思考プロセスをチームに導入することが含まれ、また、社内デザインコンサルタントは、デザインにおける変更管理を効果的に行うことができます。  

社内デザインコンサルタントは、この非常に重要だけど時間のかかるプロセスを監督・管理するのに適任です。チーム全体の一貫性と明瞭性を確保するために取り組みを整理・効率化することで、デザインにおける変更管理を組織全体に浸透させることができるのです。  

2. 知的資本と問題解決能力の向上

デザイン会社は、製品デザインチーム内に社内コンサルティンググループを設けることで、コスト削減、より良いデザインサービスの人材獲得、製品開発の加速、戦略的デザインソリューションやブランド戦略などを進めることができます。それにより社内コンサルティングを通じてのみ得られる知的資本の成長と維持が促され、社員が会社そのものをよりよく理解できるようになります。

社内デザインコンサルタントは、第一線で活躍する社員として、社内のデザインアーキテクチャに関する豊富な経験と知識を積み重ねており、このような深いインサイトで、他の社員が社内デザインコンサルタントと交流する際や、ライン管理のポジションに移行する際に、問題解決能力が上がります。

3. 組織全体でのデザイン推進

  大抵のデザインチームにとって、デザイン思考の組織全体への普及は難点です。社内にデザインコンサルタントを置くということは、チーム内にデザイン支持者を置くということでもあるのです。

社内デザインコンサルタントは、デザイン思考を実践し、 戦略的なデザインに必要な視認性と注目度を常に保証します。また、デザイン大使として、他のビジネスステークホルダーが製品デザインやデジタル製品のユーザビリティの重要性を理解できるようサポートします。  

4. デザイン部門と他部門のコミュニケーションの橋渡し

多くのデザイン関係者は、組織内のサイロ解消がいかに難しいかを指摘しており、デザイン変更管理には、デザインチームメンバー間だけでなく、他部門との間でも明確で曖昧さのないコミュニケーションが必要になります。  

デザイン変更管理とデザイン思考を常に提唱している社内デザインコンサルタントは、そのシステムでいかに仕事が楽になるかを、他の部署や担当者が理解するのに長けています。彼らは、システムの複雑性を説明することに長けており、例えば、ソフトウェアデベロッパーにシステムの機能やブランディング戦略における役割を伝えることで、デベロッパーとデザインチームとの連携をより円滑にすることができるのです。

ただ、このような最新のプロセスには、円滑なコミュニケーションだけでなく、適切なツールも必要です。UXPin Mergeのような技術スタックは、デザインチームがUI、UXデザイナーとデベロッパー間の穴埋めをするのに、彼らを信頼できる唯一の情報源（Single source of truth）に合わせることで、より密接した作業環境や、孤立した邪魔なサイロの軽減に繋がるのです。

このようなツールがどのように役立つかを示す素晴らしい例として、影響力のあるデザイン運営の第一人者、デイブ・マルーフ氏によるものがあります。彼はウェビナーで、社内コンサルタントはこのようなソフトウェアで、信頼できる唯一の情報源（Single source of truth）を活かし、デザインチームと部門間の溝を埋めることによって、組織におけるサイロを解消できると述べています。

社内デザインコンサルタントを配置するには

では、デザイン運営に社内デザインコンサルタントを加えることを検討されているのですね。いいですね！ただし、始める前に計画が必要であり、社内デザインコンサルタントを始める前に、デザイン思考の哲学を採用し、伝えることから始まるのです。

ステップ1：コミュニケーション

デザイン業界では、社内デザインコンサルタントがまだ普及しておらず、外部デザインコンサルタントへのデザインシステムのレビューやアップデートの依頼に慣れているか、コンサルタント業務を自ら行うことをすでに習得している場合が多いようです。

社内デザインコンサルタントを置く目的は、チームのパフォーマンス向上であることを覚えておきましょう。なので事前に必ずコミュニケーションをとり、チームと連携しましょう。なぜ社内コンサルタントを配置するのか、専任のコンサルタントを配置することでどのようにデザインの負担が軽減され、問題解決に役立ち、デザイン思考の一貫性を確保できるのかを確実に理解してもらいましょう。

ステップ2: 目的の明確化

目標がなければ、コンサルタントもチームも、自分たちが目指す成果物がわからず、闇雲に作業することになります。よって次のステップでは、早い段階から社内デザインコンサルタントの目標を明確に定めます。 

そのようなコンサルタントの目的には、以下のようなものがあります：

• マーケティングチームが新規ビジネスを呼び込むためのメールフローを見直し、CX（カスタマーエクスペリエンス）を上げるのをサポート
• カスタマーサクセスチームによるアカウント解約プロセスのUX（ユーザーエクスペリエンス）向上へのアシスト
• デザインチームとデベロッパーの連携と連絡を促し、信頼できる唯一の情報源（Single source of truth）を中心としたデザインの仕組みの導入
• 見込み客のコンバージョンプロセスをより効率的にデザインするための営業部門との連携
• 企業のブランディングチームと連携し、企業の最新情報についてのより魅力的なメディアリリースの予定や、製品の優れたデザインを紹介するためのSNS戦略の見直しをサポート

ステップ3: コンサルティングを始める

次に、作業を始めましょう。デザインチームと連携し、社内デザインコンサルタントの目的を明確に定めて伝え、コンサルタントを見つけたら、その任務の遂行を開始します。

他部門と関わりを持ちましょう。協議、観察、テストを実行し、チームとのブレインストーミング、プロセスの監査と更新、フィードバックの獲得、目標に到達したかどうかの報告をしましょう。  

ステップ4：測定と学習

作業を実行に移す時間ができたら、結果を測定して分析し、作業の微調整が必要になります。チームからフィードバックを求め、データを分析し、改善すべき点があればそこを指摘します。間違いが見つかったら、それを教訓にして、デザイン戦略を修正しましょう。

完成したら、測定した結果と最初に設定した目標との比較が必要です。目標に到達していれば、引き続きコンサルティングを行い、改良を加えましょう。そうでない場合は、もう一度最初からやり直しましょう。

このヒントで最高のデザインコンサルタントを輩出しよう

デザインチームのニーズが進化し、より複雑になるにつれ、デザイン会社や組織は、社内デザインコンサルタントの雇用、トレーニング及び育成の利点と可能性が、外部コンサルタントの導入の必要性を上回っていることに気づきました。

社内デザインコンサルタントは、スポーツチームのキャプテンとして新しいシーズンに向けてチームを安定させ、新たな高みへと導いてくれる存在だと考えてください。彼らの仕事は、パフォーマンスを上げ、「プレーヤー」の能力を最大限に引き出すことなのです。  

社内デザインコンサルタントは、すでにデザインサービスにおける重要性を示しており、近い将来、あらゆる職場でデザイン思考の重要な推進力となることでしょう。彼らは、製品デザインプロセスにおける一貫性を確保し、デザイナーが目指すものと、デベロッパーがデザインシステムの必要性をどのように理解しているかとの間のギャップを埋めるサポートをします。  

生産性を上げよう

社内デザインコンサルタントはデザイン思考の完璧な支持者であり、UXPinのようなデザインツールで武装することで、デザインチームを最大限に活かし、生産性を上げることができるようになったのです。

UXPinには「Merge」という技術があり、デジタル製品の構成要素である機能的なUIコンポーネントを正確に使ってプロトタイプを構築することができ、事実上、デザインのハンドオフがよりスムーズになります。デベロッパーは、構築する必要があるものを正確に把握することができ、デザイン要素の背後にあるコードをコピーして、そのプロセスで使うことができます。その結果、デザインと開発間の透明性が高まり、会社全体がより明確になるのです。

The post デザインとコンサルティング – 社内コンサルティングのメリットとは appeared first on Studio by UXPin.

限られたリソースと他部門との競争において、UI/UXデザインの取り組みに説得力のあるビジネスケースを作成することは、賛同者確保のために非常に重要です。その際、自身に最高のソリューションがあり、その取り組みを成功させることができることを証明しなければいけません。

本記事では、UXデザインの専門家が説得力のあるUXビジネスケースを作成する方法について、UAEの宅配サービス「Delivery Hero」の事例を交えてお話します。

UXPinを使用して、ビジネスケースをサポートする完全な機能を持つプロトタイプを作成しましょう。それでステークホルダーやユーザビリティ担当者は、最終的なデジタル製品と同じようにプロトタイプに関わることができます。無料トライアルにサインアップして、コードベースデザインによってUXワークフローとユーザビリティ・テストにどのような変革がもたらされ、製品開発が向上するか、ぜひご覧ください。

ビジネスケースとは

ビジネスケースは、プロジェクト、イニシアチブ、または戦略の利点と、会社または部門がそれを必要とする理由を概説しますが、UXのビジネスケースは、例えばデザインシステムの構築、デザインツールの購入、大規模なUXリサーチプロジェクトへの投資など、特にデザイン関連のプロジェクトに関連します。

UXチームは、ビジネスケースを通じて以下をする必要があります：

• 費用の必要性（問題）の実証
• デザイン上の解決策の提示

解決策は、価値提案と組み合わせることで、より効果的になることが多いのです。このプロジェクトは、デザインと組織にどのようにROI（投資対効果）をもたらすでしょうか？

UXのビジネスケースが必要な理由

特にUXプロジェクトでは、ステークホルダーからの賛同は得難いです。非デザイナーの多くは、ユーザー中心デザインの原則やデザイン思考を理解しておらず、デザイン投資に対して消極的なのです。

UXビジネスケースは、製品のCX（カスタマーエクスペリエンス）を上げることがいかに利益につながるかをステークホルダーに示す必要があります。たとえば、デザインシステムは大きな投資ですが、ステークホルダーは、再利用可能なコンポーネントのライブラリがどのようにビジネス価値をもたらすのか理解できないことが多いため、デザイナーはビジネスケースを通じてこの価値を示さないといけません。

Delivery Heroのビジネスケースの価値提案

Delivery Heroは、デザインシステムのビジネスケースに価値提案を使用した良い例です。Delivery Heroのデザインチームは、自社のデザインシステムをステークホルダーに売り込もうと何度か試みた後、実際のケーススタディや価値提案など、より説得力のあるケースの作成が必要であることに気づきました。

そこでDelivery Heroの製品デザインチームは、デザインシステムを【使用した場合】と【使用しない場合】のユーザーインターフェースの構築を1つの画面で比較しましたが、その結果は、驚くべきものでした：　

• デザインシステムなしでの構築 – 総時間: 7.5時間
• 再利用可能なコンポーネントとして構築 – 総時間：3.25時間

この実験では、再利用可能なコンポーネントを使用することで、フロントエンドの工数の57%削減と、フロントエンドの負債を0%にすることが実証されました。

フロントエンドの負債はDelivery Heroにとって複合的な問題となっていたので、この問題を解消し、納期を60%近く短縮することで、ステークホルダーに大きなROIを示したのです。

Delivery Hero のステークホルダーはその結果に感銘を受け、会社のデザイン システムである「Marshmallow」にゴーサインを出しました。（Delivery Hero のストーリーの詳細については、こちらをご覧ください。）

UXビジネスケースに含めるべきこと

ビジネスケースの目的と重要性がわかったところで、盛り込むべきポイントを探ってみましょう。

• エグゼクティブサマリー
• ミッションステートメント
• 市場
• 問題提起
• 解決策と価値の提案
• リスク
• ロードマップ
• 必要なリソース
• チーム

ここで重要なのは、必ずしもこのポイントすべてを使うわけではなく、ビジネスケースとプロジェクトに関連するものだけを使うということです。ビジネスケースを徹底的に、しかし簡潔にすることが目標であり、もしステークホルダーが調査結果を見たい場合は、別途提示することができます。

エグゼクティブサマリー

エグゼクティブサマリーは、ビジネスケースとそのセクションを要約したものであり、ビジネスケースのエグゼクティブサマリーに含めるべき必須要素は以下の通りです：

• 問題点
• 自身の解決策

ミッションステートメント

ミッションステートメントは、プロジェクトの目的とゴールを要約したものです。通常は数文で構成され、エグゼクティブサマリーと同じスライドに表示することができます。これは、チームメンバーやステークホルダーを共通のアイデアと目的で結びつけながら、デザイン・プロセスの指針となります。

Project Managerの記事であるHow to Write a Mission Statementをチェックしてみてください。

市場（またはユーザー）

UXビジネスケースが社内の取り組みである場合、このセクションを「ユーザー」に置き換え、プロジェクトが誰を対象としているかの特定ができます。たとえば、デザインシステムは、製品、UX、およびエンジニアリングの各チームにのサポートをしますが、エンドユーザーにもプラスの影響を与えます。ステークホルダーが実在の人物に共感できるように、エンドユーザーをペルソナで表現するといいでしょう。

問題提起

問題提起は、【重要な問題】、【人への影響】、そして【ビジネスへの影響】の概説であり、Atlassianのデザインマネージャーである ローラ・ヴァン・ドール氏は、「良い問題提起を行うには 2 つの要素があります」と言います。

問題の選択：

「聴衆にアピールできる問題を選び、強調しましょう」 

ステークホルダーに売り込む際には、デザインチームだけに焦点を当てるのではなく、問題がビジネスにどのような影響を与えるかを示しましょう。

Delivery Heroの場合、製品チームは、現在のプロジェクトワークフローで「フロントエンドの負債、不整合、市場投入までの時間の遅れが蓄積され、最終的にビジネスの時間とリソースを犠牲にしていること」を示しました。

ユーザーに直接影響を与える問題を提示する場合、ステークホルダーに問題を明確に理解してもらうために、カスタマージャーニー、ユーザーリサーチ、その他のUXアーティファクトを含めるとよいでしょう。

問題の枠組み：

ローラの次のステップは、ターゲットとなるユーザーに対する問題の枠組みです：

• 核となる問題の特定
• その問題が誰にどのように影響するかの概説
• オーディエンスとビジネスへの悪影響の説明

解決策と価値提案

自身のソリューションがどのように企業の問題を解決するのか、その価値提案を記述しましょう。価値提案は、その価値とROI（投資対効果）を説明するので、ビジネスケースにとって非常に重要です。

ステークホルダーは、ビジネス関連の影響に比べたら、ワークフローの問題解決には関心がありません。自身のソリューションはどのようにROIを実現するのでしょうか？

Delivery Heroのデザインシステムチームのアンバー・ジャビーン氏は、解決策にはビジネスメトリクスとKPIを使用して、組織にとってプラスになることの説明が必要だと言います。コスト削減、収益上昇、市場投入までの時間の改善、製品の競争力の向上をどのように行おうとしていますか？

リスク

徹底したビジネスケースは、リスクとその対処法についても検討します。ステークホルダーは、あなたが解決策を多角的に検討し、潜在的な問題に備えていることを知りたがりますからね。

Atlassianのローラ・ヴァン・ドール氏は記事の中で、「夢見る夢太郎ではなく、現実を見ましょう…夢を売りすぎて、成功しかありえないようなシナリオを提示すると、ケースが偏りすぎているように見え、どん底に突き落とされるかもしれないですよ」と述べています。

ロードマップ

ビジネスケースのもう一つの重要な要素は、タイムラインまたはロードマップです。プロジェクトの実現にはどれくらいの時間がかかるのでしょうか、そして、企業は提案された解決策の価値をいつから享受できるのでしょうか？また、ステークホルダーが進捗を確認できるよう、KPI（重要業績評価指標）はどのように設定しますか？

ここでも、関連するビジネスメトリクスの使用が重要です。例えば、人材について議論する場合、デザイン、プロダクト、エンジニアリングなど、部門ごとの総時間を見積もりましょう。このような内訳により、ステークホルダーは、プロジェクトが会社の人的資源や他のプロジェクトにどのような影響を与えるかを見ることができます。

必要なリソース

人材、資金、技術、デザインなど、プロジェクトに必要なリソースは何でしょう。可能であれば、複数のシナリオを用意し、利用可能なリソースに基づいた選択肢をステークホルダーに提供しましょう。

プロジェクトの実施前、実施中、実施後にどのようなリソースが必要になるかを考えましょう。たとえば、デザインシステムには、開始前のデザイン監査、デザインシステムの構築と提供のための人材、デザインシステムの管理と拡張のためのチームなどが必要です。デザインシステムが成熟するにつれて、より多くのリソースが必要になります。

チーム

ビジネスケースの背後にあるコアチームと、プロジェクトを実現し、拡大するために必要な人材について、特に詳しく説明しましょう：

• UXデザイナー
• エンジニア
• プロダクトマネージャー
• アナリスト
• ステークホルダー

強力なUXビジネスケースのためのベストプラクティス

2022年5月に開催されたDelivery Hero MENA（talabat）のDesignOps Director、アンバー・ジャビーン氏によるウェビナー「Enterprise Design System – How to Build and Scale」から、ベストプラクティスをいくつか拝借しました。

1. 本当のペインポイントから始める

ビジネスケースには、製品、ユーザー、そしてビジネスに悪影響を与えるペインポイントが含まれてないといけません。問題の影響を受けるのがチームメンバーだけだと示されていたら、ステークホルダーが行動を起こす可能性は低くなります。

例えば、その問題が【手直し（余分なコスト）】、【ユーザビリティの問題（ユーザーを失い、費用のかかるサポートチケットを生み出す）】、【技術的負債（余分なコスト）】、【市場投入までの時間の遅れ（競争力の低下と収益の損失）】を生み出していると証明できたとします。そうすると、あなたにはステークホルダーの注目が集まる真のペインポイントがあるということになります。

2. 価値提案の構築

ペインポイントを中心に価値提案を構築しましょう。あなたの解決策は、問題を解決し、ROIをもたらさないといけません。現実的であること、そしてリスクを考慮したことをステークホルダーに示すことを忘れないようにしましょう。

3. 最大の支援者とスポンサーを特定する

UX以外のリーダーやステークホルダーを見つけ、ビジネスケースをサポートすることで、より重みのあるビジネスケースにすることができ、以下のような提唱を彼らから得られるでしょう：

1. 特定された問題は、現実のものである
2. 提案されている解決策と価値提案は最良の選択肢である

ビジネスケースには、このような支持者を含め、場合によっては最も影響力のあるステークホルダーの言葉を引用することもできます

4. 語る前に見せる

UX以外の人は、UXとデザイン思考の原則を理解するのが難しいことから、問題を説明するだけでは不十分です。なので、何が問題で、それがビジネスにどう影響するかを見せる必要があります。

Delivery Heroで見たように、アンバーのチームは、会社の時間とお金を浪費している非効率性と問題を示す実験を提示しました。そして、自分たちの解決策がその問題を解決し、組織に価値を提供できることを証明したのです。

ステークホルダーに理論を提示すれば、彼らは証明しろと送り返すでしょう。時間をかけてテストや実験を行い、自分のソリューションを実行し、それがうまくいくことを証明しましょう。

5. ビジネスメトリクスを語る

あなたの問題と解決策には、あなたのビジネスケースをサポートするための数字が含まれていなければなりません。ステークホルダーは、査定のためのメトリクスやKPIを見たいのです：

• 問題の状態と規模
• あなたの解決策がどのようにその数値を改善するのか

6. 一人でしない：ネットワークの構築

ステークホルダーにビジネスケースを提示する前に、部門を超えたチームメンバー、リーダー、マネージャー、そして問題の影響を受けるすべての人に話を聞いて、解決策への支持と賛同を得るようにしましょう。プロジェクトの背後に組織があれば、意思決定者から承認を得られる可能性が高くなります。

UXPinプロトタイプでビジネスケースをサポートしよう

UXPinのコードベースのデザインツールにより、デザイナーはコードのような忠実性と機能性を備えた完全なプロトタイプを作成することができます。UXデザイナーは、ある機能がどのように機能するかを想像するのではなく、最終的な製品体験を正確に再現し、ステークホルダーに対してより説得力のあるビジネスケースを作成することができます。

ステークホルダーやユーザーテストのために、より質の高いプロトタイプを構築するための無料トライアルにぜひご登録ください。

The post UXのビジネスケース：デザイン投資のための強力なケースを構築する方法 appeared first on Studio by UXPin.

2022年5月、UXPinはDelivery Hero MENA（中東・北アフリカ地域（talabat））のDesignOpsディレクターであるアンバー・ジャビーン氏をお迎えし、「Enterprise Design System – How to Build and Scale.」と題したウェビナーを開催しました。

本記事では、彼女の講演の一部を要約し、デザインシステムの賛同を得る際にチームが直面した課題と、彼女ならどうするかということについてお話します。

アンバーは、UXPinの無料eBook「 DesignOps 101: Guide to Design Operations」の共同執筆者です。この本は6つの章からなり、DesignOpsの紹介とその実践法が説明されています。

UXPinでデザインシステムを構築、拡張、共有、成熟させましょう。

デザインシステムの賛同を勝ち取るために多くのチームが行っていること

2019年、Delivery Heroは、多くのスタートアップが経験する、あまりにも身近な困難に見舞われていました。UIライブラリやデザインシステムもないまま、9つのチームが製品に取り組んでいたことにより、Delivery Heroはサイロを生み出し、重複が多く、拡張しにくく、結果的に「非常に断片的なUX（ユーザーエクスペリエンス ）」になっていたのです。

アンバーとそのチームは、デザインシステムこそが、自分たちの問題を解決するイチバンの方法だと考え、ステークホルダーの賛同を得るためのケース作りに取りかかりました。

デザイン監査の実施

Delivery Heroの製品チームは、まずデザイン監査から始めました。そして監査報告書では、以下のような多くのユーザーインターフェースの不整合が明らかになったのです：

• 数種類のCTA（Call To Action）
• タイポグラフィ・スタイリング基準なし
• 複数のアイコン形式

アンバーは講演の中で、「…私たちのデザイン言語は、あちこちにあったのです。これは、大きな気づきの瞬間でした。」と言っています

チームは監査報告書をもとにビジネスケースを構築し、Delivery Heroの幹部に提示した結果、アプリ再デザインの賛同を得ることができました。

製品チームはまず、主要な画面とユーザーフローの再デザインを行いました。新しいデザインは、より一貫性があり、クリーンで、ブランドとの整合性が高く、UXを上げるものでした。

UIパターンでUIライブラリーを構築する

製品チームはこの再デザインをもとに、色、タイポグラフィー、立面図、UIパターン、コンポーネントなどのUIキットとスタイルガイドを作成しました。

Delivery Heroの製品部門は規模を拡大し、新しいデザイナーを採用しました。アンバーは、「このような規模の拡大にもかかわらず、Delivery Heroのデザインプロジェクト全体の一貫性が向上し、デザインを拡張することができた」と述べています。

コンポーネント・ライブラリ構築の初挑戦

デザイナー向けの信頼できる唯一の情報源（Single source of truth）のデザインに成功したDelivery Heroの製品チームは、エンジニアリング向けにも同じことをしたいと考えていました。そこでアンバーと彼女のチームは、コンポーネントライブラリのための別のビジネスケースをまとめました。

ビジネスケースのDelivery Heroデザインシステムの主要な利点を以下にまとめました：

• デザイン – 開発間の信頼できる唯一の情報源（SSOT）
• より良いUX（ユーザーエクスペリエンス）
• ブランドとの親和性強化
• 実験、プロトタイピング、テストの迅速化

Delivery Heroの幹部は、プレゼンテーションを気に入り、製品チームの提案に価値を見いだしました。 なのに、デザインシステムを作るお金もリソースもなかったことから、コード・コンポーネント・ライブラリの構築の答えは「ノー」だったのです！! 

アプローチの練り直し

アンバーのチームは、もう一度振り出しに戻って、スタイルガイドを使った新しいデザインをアプリ全体に展開することにしたのです。このプロジェクトには3ヶ月を要しましたが、製品開発チームにとっては大成功でした。

その後6ヶ月の間に、Delivery Heroはたくさんの新機能と実験結果を出しました。製品チームの新しいデザインは新鮮で一貫性がありましたが、エンジニアにとっての信頼できる情報源がないため、Delivery Heroの最終的なリリースに一貫性がないという問題がありました。

製品チームは、一連の監査を再度行うことにして、そこでデザインハンドオフとプロダクションのスクリーンショットを撮った結果、コンテンツやUI要素の欠落など、多くの矛盾が明らかになりました。この監査で、Delivery Heroがリリースごとに負債を積み重ねていることがわかったのです。

Delivery Heroのデザインシステムに対する説得力のある事例の構築

Delivery Heroのデザインシステムチームにはエンジニアがいなかったので、デベロッパーと組んで、幹部に新しい売り込みをするためのコンポーネントを作り、テストする必要がありました。

アンバーのチームは、Delivery Hero の【No results】画面用のコンポーネントを作成し、デザイン システムを「使用する場合」と「使用しない場合」とで比較して実験しました

• デザインシステムなしで構築 – 合計時間：7.5時間
• 再利用可能なコンポーネントとして構築 – 合計時間：3.25時間

製品チームは、フロントエンドの開発時間のみを記録しました。この実験では、再利用可能なコンポーネントによって、フロントエンドの労力が57%削減され、負債が0%になることが実証されました。

アンバーのチームが、この新しいデータを使って、コンポーネントライブラリ構築のための別の事例を提示すると、Delivery Heroの幹部はこの結果に感動し、デザインシステムの開発にゴーサインを出したのです。

そして現在、Delivery HeroのデザインシステムであるMarshmallowは、デザインシステム専門チームが管理するUIキットとコードUIライブラリの30以上のコンポーネントを持ち、デザインと開発を一元化しています。

Marshmallowには、以下のものがあります：

• デザインシステムのウェブサイト
• 専用Slackチャンネル
• ブランド、コード、デザイン、コピーなどのガイドライン 
• デザイン言語
• 作業やコミュニケーションのためのプロトコル
• コードコンポーネントライブラリ
• アイコンのテンプレート
• UIキット
• UIサンプル
• デザインシステムガバナンスの手順

ゼロからのデザインシステムの作り方はこちらでご覧になれます：Design Systems: Step-by-Step Guide to Creating Your Own.

企業向けデザインシステム構築のための賛同取得と拡張

アンバーは、学んだことを振り返りながら、企業向けデザインシステムへの賛同を得るための6つのアドバイスをしています。

本当のペインポイントから始める

製品、ユーザー、ビジネスに悪影響を及ぼしているペインポイントを特定することは、重要な第一歩です。アンバーとそのチームは、監査システムを使って、デザインと開発の間に大きなずれがあることを突き止めました。

価値提案の構築

ビジネスケースのための価値提案の構築に、ペインポイント（複数可）を使いましょう。そして解決策は、問題を解決し、ステークホルダーに投資対効果をもたらすものでなければなりません。

最大の支援者とスポンサーを特定する

アンバーは、デザインシステムの売り込みを裏付けるために、他部署からの支持者を探すことを勧めています。その支持者は、1, “これは会社にとって本当の問題である” 2, “これは最良の解決策である “というあなたの主張を支持してくれるでしょう。

語る前に見せる

アンバーは、最初のプレゼンテーションで犯したミスは、証拠なしにストーリーを語ったことだと言います。そこで、コンポーネントライブラリで何ができるかをステークホルダーに見せると、チームの話はより説得力を増し、ビジネスケースも納得のいくものになりました。

ビジネスメトリクスを語る

“シナリオのビジネスケースを、KPIやビジネスに影響を与えるメトリクスと関連付けなければ、ストーリーは完成しません。” アンバー・ジャビーン氏

さらに、ビジネスケースには、この問題がどのように会社のリソースに負担をかけているのか、そしてその解決策によって何ができるのかを示す、デザインシステムのメトリクスが含まれていなければいけないと言います。

一人でしない：ネットワークを築く

技術、デザイン、製品、マーケティング、顧客サービスなど、部門を超えたパートナーのネットワークとしてビジネスケースを売り込み、デザインシステムが、組織のための解決策であり、デザインチームの負担を軽くするためだけのものではないことを証明しましょう。

アンバーの1時間のウェビナー全体はYouTubeでご覧になれます。

UXPinによるコードベースのデザインシステム

UXPin独自のMergeの技術により、デザインシステムのコンポーネントライブラリとUXPinのエディタを同期させ、デザインと開発の間に信頼できる唯一の情報源（SSOT）を作成することができます。

The post 企業デザインシステムの構築と拡張に関する11の教訓 appeared first on Studio by UXPin.

DesignOpsを成熟させ、広めることは長期的な成功のために非常に重要です。しかし、どこから始め、何を追跡し、どのように正しいメトリクスを測るのでしょうか？ そこで筆者達は、NN GroupのDesignOpsフレームワークとUXPinコミュニティからの質問からヒントを得て、DesignOpsの実践者が成熟度の追跡と測定に使用できるチェックリストのテンプレートを作成しました。

UXPin MergeでコンポーネントライブラリをUXPinのエディタに同期させて、信頼できる唯一の情報源（Single source of truth）を作成し採用率を上げましょう。Reactライブラリ用のGitや、その他の一般的なフロントエンドフレームワーク用のStorybook統合をぜひご覧ください。

メトリクスの使用によるDesignOpsの追跡

DesignOpsの取り組みを追跡しなければ、変更が成功したかどうかや、組織の成熟度合いを知ることはできません。また、このようなメトリクスは、ステークホルダーへの成功の報告、賛同の獲得、およびOpsの拡張のために極めて重要です。

正しいメトリクスの選択

2021年12月に開催されたパトリツィア・ベルティーニ氏とのWebセミナーでは、DesignOpsのROIと正しい測定基準の選択について考察しましたが、そこでパトリツィアは、DesignOpsのメトリクスを、【有効性】と【効率性】の2つのカテゴリーに分類しました。

• 【有効性】とは、行動や正しいことを行うことであり、主観的で測定が困難な場合がある。
• 【効率性】とは、数字や割合、比率などを使って測定・定量化できるものである。

ステークホルダーは、原因と結果を明確に示すことができるため、効率性を見ることを好みますが、効率性も、行動や主観的な改善によって効率が上がり、DesignOpsの拡張と成熟に役立つため、同じくらい重要です。 パトリツィアが有効性と効率性にどのようにアプローチしているか、YouTubeチャンネルにあるウェビナーで再度ご確認ください。DesignOps、デザインリーダーシップ、デザインシステムに関する今後のウェビナーについてはぜひご購読ください。

DesignOpsのフレームワークを 「成熟度チェックリスト 」として使う

NN Group の DesignOpsのフレームワークは、「DesignOps の状況」 を理解するのに優れたテンプレートであり、DesignOpsリーダーは、このフレームワークを「成熟度の追跡」や、「改善すべき領域の特定」のためのチェックリストとして使うことができます。 NN Groupが557人のデザインとUXの実務者を対象に行った2020年の調査では、DesignOpsは 「ほとんどの組織で低水準 」という結果が出ました。 この調査では、「組織は推奨されるDesignOpsの取り組みの22%しか行っておらず、DesignOps専用の役割もなく、全体的にDesignOpsの成熟度が低かった」と報告されています。 このフレームワークをガイドとして、DesignOpsの実践者は【進捗】と【成熟度】を追跡するためのチェックリストを作成することができます。 フレームワークによると、DesignOpsには主に3つ領域があります：

• どのように協力し合うか
• どのように仕事を成し遂げるか
• どのようにインパクトを生み出すのか

どのように協力し合うか

【どのように協力し合うか】 は、NN Group の DesignOps 成熟度調査において、平均 18% で最も低いスコアとなり、「人間らしさ：開発と成長の実現」というカテゴリーが、この分野で最も低い成果となりました

この分野が連携や連絡、チームワーク、雇用、スキル開発など、UXのアウトプットに関連するメトリクスに相関していることから、経営陣やデザインリーダー又はDesignOpsのリーダーは、成果の低さに特に注意を払わなければいけません。 組織化：チーム体制 プロジェクトの成功には、「適切なチーム」の構築が欠かせません。NNグループの調査では、DesignOpsの成熟度を向上させるための3つの重要な領域が特定されました：

• 共有されたデザインチームの組織体制
• 役割とスキルを補完し合うバランスの取れたデザインチーム
• デザインリーダーは他部門のリーダーと同等である

連携：効果的なコミュニケーション

• デザインの役割がデザインチームメンバーやステークホルダーに理解され、合意されている
• デザイナーがUXの知識やインサイトを共有するためのコミュニケーションチャネル
• 社内および部門を超えた連携を促す職場環境
• チームメンバーが興味や情熱を共有するための正式なチャネル

人間味：発展・成長を可能にする

• 客観的な候補者評価を促す一貫した採用・面接の実施
• 新入社員のマイルストーンと目標の設定と、定期的なチェックの実施
• デザイナーのキャリア開発のための明確な道筋
• 成長の機会を特定するための定期的なスキル評価プロセスの確立

DesignOpsサービスの認知

もうひとつ、【どのように協力し合うか】を形付けるのは、組織全体の意識と積極性を高めるために仕事を社会化するという、認識です。

• スキルの認識：適切なチーム作りに不可欠
• スキルギャップの認識 ：長期的な成長とUXの拡張に不可欠
• キャリアの現状と機会の認識：才能の保持や、従業員のモチベーション維持のための、個人の開発と成長への刺激
• ブランドと文化の認識： UXを組織の幅広いビジョンと結びつける。

【どのように協力し合うか】の領域を改善したいと思いませんか？DesignOpsの最初の柱に関する無料のeBookをこちらで入手し、DesignOpsのこの重要な側面について学びましょう。

どのように仕事を成し遂げるか

私たちがどのように仕事を成し遂げるかは、プロジェクトのワークフロー、ツール、プロセス、およびプロトコルに関連しています。この分野は、生産性、プロジェクトの納期、および一貫性に影響を与えるため、通常、DesignOpsの主要な焦点となります。

NNグループのDesignOps成熟度調査では、すべてのメトリクスで平均20％という結果が出ています。

標準化：一貫したツールやプロセスを使う

• 標準化・文書化されたデザインプロセスをステークホルダーと共有し、社内のデザインチームが使用する
• デザインが開発プロセスに適切に組み込まれている
• デザイナーは、標準化されたUX原則に基づいて作業を行い、一貫したプロジェクトデリバリーを実現する
• デザイナーは、UXアーティファクトを作成するのに一貫したツールセットを使用する
• デザインツールは、プロダクトやエンジニアリングを中心とした外部パートナーと統合されている

調和：リソースやインサイトの共有

• 共有されたデザインシステムまたはスタイルガイド
• 一元化され、検索可能で、共有されたリサーチのアーティファクトとインサイト
• 共有され、アクセスしやすいデザインアーティファクト

優先順位：何をなぜ重視するかの決定

• デザインチームは現実的な能力で運営されており、すなわち、適切なリサーチ、デザイン、プロトタイプ、テスト、ドキュメンテーション、およびデリバリーのための十分な時間が確保されている。
• デザインプロジェクトにおける現実的な時間枠と予算

DesignOpsサービスの有用性

NNグループのフレームワークに、もう一つ、【DesignOpsサービスの有用性 】という要素を追加します。

• デザインリーダーシップとステークホルダーのデザインプロジェクトの状況に対する認識
• デザインチームの健全性
• うまくできあがったデザインプログラム
• 生産性、効率性、市場投入までの時間、一貫性など、デザインシステムへの影響

どのようにインパクトを生み出すのか

【インパクト】は、DesignOpsの最後の注目分野です。NNグループの調査では、インパクトは平均30%と最も高いスコアでしたが、多くのメトリクスは1桁以下かそれに近い数値でした。

  このDesignOpsの要素を拡張、成熟させるのに、デザインアドボカシーは重要な役割を果たします。

測定：デザイン品質の定義と追跡

• 説明責任を果たすための一貫したデザインメトリクスの追跡
• プロジェクトごとに、また、より広いビジョンとロードマップに向けて追跡されるUXのメトリクス
• デザイン品質の客観的で一貫した測定

社会化：デザインの役割と価値についての教育

• パートナーやステークホルダーと共有するデザインの成功例とケーススタディ
• パートナーやステークホルダーに対するデザインの役割と価値の統一的なメッセージと共有
• ユーザー中心のデザイン原則の適用における、非デザイナーの認識
• 組織のデザインの価値の理解

有効化：デザイン活動の組織的な活用の促進

• 外部パートナーも利用可能なデザイン活動や手法
• 問題解決のためのデザイン思考など、非デザイナー向けのデザインスキルトレーニング 
• アイデア出し、プロトタイプテスト、デザインスプリント、UXリサーチなどのデザインプロセスへのデザイン担当以外の社員の参加

DesignOpsサービスの導入

インパクトの要素に【導入】というもう1つのレイヤーを追加します。導入と完了は、DesignOpsのケーススタディと成功事例を組織やステークホルダーと共有することができるため、インパクトにとって非常に重要です。

• ツール、プロセス、システムの採用 – 変化の促進
• デザインイベント、デザインチームメンバー、外部パートナー、ステークホルダーへの参加
• 標準化されたデザインプロセスに従ったプロジェクト
• デザインレビュープロセスに従ったプロジェクト
• 管理されたデザインプログラムの数
• うまくできあがったプログラムの数

UXPin Mergeでデザインを拡張しよう

デザインアウトプットの拡大のために、デザイナーを増員する必要はありません。2019年にUXPin Mergeを導入したPayPalでは、プロジェクトの納品が8倍速くなり、デザイナーを増員する必要がなくなりました！

デザイン、製品、開発を同期する完全に統合されたデザインシステムがあれば、チームはゼロからのデザインやコーディングをほとんどすることなく、素晴らしい製品を作ることに集中できる時間を増やすことができます。それによりIressは、UXPin Mergeによって「完全に統合されたデザインシステム」を構築し、以下が実現されました：

• コードもしくはコードなしでのデザイン
• デザインドリフトなし
• 一貫したデザイン
• シームレスな（もしくはまったくない）ハンドオフ

UXPin Mergeの単一のコードベースのデザインソリューションで、DesignOpsの多くの課題を解決しましょう。この画期的なテクノロジーへのアクセス権をリクエストして、顧客にとってより良い製品体験の構築をぜひ始めてください。

The post DesignOpsの成熟度確認のためのチェックリスト appeared first on Studio by UXPin.

デイブ・マルーフ氏は、DesignOpsのエキスパートであり、業界のベテランです。彼は、ブログ記事、インタビュー、講演などを通じて知識を共有し、このプラクティスの発展に貢献しています。

UXPinが開催した無料ウェビナーに彼を招き、エンタープライズ・デザインに対する総合的なデザイン運営のアプローチに関する彼の見解をシェアして頂きました。

UXPin Mergeは究極のDesignOpsツールです。デザイナーとエンジニア間のギャップを埋めるコードベースのデザインツールで、DesignOpsの多くの課題を簡素化および自動化します。無料トライアルにサインアップして、MUI統合による強力なMergeテクノロジーなど、UXPinの高度な機能をぜひお試しください。

デイブ・マルーフ氏によるDesignOpsの5つのポイント

デイブの講演やブログ記事から、デザイン運営の改善のための5つのアイデアをまとめました。このリソースへのリンクは、本記事の最後にあります。

1：”意図的な空間 “を創る

彼はAmplify Designの中で「意図的なスペースとプロセ スがいかに思わぬ発見をする能力、創発、そして探求を促すか」 について話しています。彼は、チームが作業や連携、意見出しをする場であるスペースは、最も「デザイナーの仕事を増幅させる価値あるピース」の1つであると述べています。

彼のお気に入りのワークスペースは、ホワイトボードに囲まれたチームポッドの中央にハイトップデスクかポディウムが置かれたもので、このセットアップは、デザイナーと部門を超えたチームの両方に有効です。

チームメンバーはホワイトボードに向かって座るので、集中力が途切れることはなく、また、走り書きしたメモやアイデアをホワイトボードで確認することもできます。

中央にあるHightopは、連携を促すためのものです。チームメンバーは質問、アイデア、プレゼンなど、このハイトップを使って他のメンバーに向かって行います。この「意図的な空間」は、連絡と連携を促しながら仕事を進めることができるのです。

デイブの意図的な空間の手法は、同じくDesignOpsのエキスパートであるサロメ・モルタザヴィ氏の、プロセスよりもプラクティス（人々の仕事の仕方）を最適化するプラクティス主導型のアプローチと一致しています。

サロメは、3月にUXPinが主催したデザインバリュー会議で、デザイン業務へのアプローチについてのアイデアをいくつか発表しています。

2：デザイナーが増幅させるものを確定する

デイブはDesignX Communityの有名な講演「Amplifying Design Value」（彼のMediumアカウントでも公開）で、Opsが組織内でデザインの価値を高めるための方法を概説しています。

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

3：より良い未来のためのデザインマニフェストを書く

デイブは、形を与えること、明確にすること、行動に適合させること、そして探求することを褒め称えるデザインマニフェストを書きました。このマニフェストは、「いいデザインが出るのは、、、」という接頭辞から始まります。

いいデザインが出るのは、、、：

• さまざまな活動が最も適切なリズムで行われる時
• 意図的なスペースとプロセスが偶然素晴らしい発見をする能力、創発、探索を促す時
• 定量的なデータと定性的なデータをバランスよく統合し、実用的なインサイトを得ることができる時
• 連携とインクルージョンが、協調的かつ集中的な開発とバランスがとれている時
• 物語の多元性の探求で、人々が将来にわたって意味を見出している時
• デザイナーの魅力やモチベーションが、他の人とは違うことを自身で理解している時
• 質の高いデザインアウトプット、そして質の高いプラクティスとは何かを自身で相互に理解し、評価する時

4：デザインプログラム管理の4つの法則を発見する

デイブは、デザインプログラムマネージャーがデザインワークを管理する際に考慮しなければならない4つのベクトルや法則を挙げています：

1. 忠実度： エンド・ツー・エンドのデザインプロセスにおいて、さまざまな忠実度に対応する適切なサポートを提供する
2. 連携：連携が自然に起こるような環境を整え、デザインプロセスの重要な部分で連携を予定に入れる
3. 結束：チームとプロジェクトが「単一のビジョン」に向けて確実に結束して機能する
4. 振り返り：チームが仕事、思考、創造性を振り返り、評価するための時間と空間をつくる

5：DesignOpsによるデザインバリューの向上

デイブは「How does DesignOps increase your design value?」で、DesignOpsのリーダーがデザインの価値を広めることができる3つの領域を特定しています：

従業員

使えるリソースで最高の人材を採用、育成、定着させる。デイブの言う「採用」は、最も経験豊富で高価な「ロックスター」を引き寄せることだけを指しているわけではありません。

社員の育成への投資や、最も高い潜在能力があり強いリーダーシップを持った人材の発掘は、長い目で見ると良いことが多いのです。 彼は人事を4つの側面から見ています：

1. オンボーディング： 優秀な社員をいかに早く育てるか
2. 報酬と認識：組織では、良い仕事はどのように評価されるか、またその報酬は各個人に適切か
3. 人材育成：組織で、成長やリーダーシップのための道筋や機会が作り出されているか
4. 昇進：キャリアアップの基準を明確にすることで、期待値を管理し、適切なチームメンバーを採用するための基準を設定できる

インフラ・ツール

DesignOpsのリーダーには、ツールの賢い選択が必要です。「デジタルの世界では、デジタルとアナログのツールが積み重なっていて、クラフトの接点でそのツールの使用に影響を与えます。」とデイブは指摘しています。

UXPin Mergeにたどり着くまでに、PayPalのエリカ・ライダー氏がいかに多くのデザインツールをテストしたかが、その一例です。彼女は、非デザイナーであるPayPalの社内製品チームが、新製品をデザイン、プロトタイプ、テスト、ハンドオフできるようなデザインツールを必要としていました。

 UXPin Mergeを使用すれば、PayPalの製品チームはコンポーネントをドラッグ＆ドロップして完全に機能するプロトタイプを、従来の画像ベースのデザインツールを使用する経験豊富なUXチームよりも8倍速く構築することができます。

 チームメンバーが素晴らしい仕事をするには、技術に合った道具を見つけることが重要だということです。  

ガバナンスとワークフロー

  ガバナンス主義は、チームメンバーの作業や新しいツールやプロセスの採用を妨げたり、遅らせたりすることがよくあります。DesignOpsは、ガバナンスとワークフローを評価し、障害物を取り除いて、デリバリーの品質とペースを向上させなければいけません。  

デイブ・マルーフ氏からもっと学ぶ

デイブの知識と経験から、より多くを学ぶためのリソースをご紹介します：  

• A Guide to UX Leadership – UXPinが提供する無料のe-Book
• Holistic Design Operations – 2022年2月に開催されたUXPin主催の無料ウェビナー

UXPinでデザインの価値を上げる

UXPinのコードベースのデザインツールは、デザイナーとエンジニアが同じ言語で会話することで、より良い連携とスムーズなデザインのハンドオフを促します。 エンドツーエンドのデザインプロセスを強化し、より大きなデザインROI（投資収益率）を実現しましょう。無料トライアルにサインアップして、UXPinの高度な機能をぜひすべてお試しください。

The post デイブ・マルーフ氏が語る – デザインバリューに関する5つの力強い見解 – appeared first on Studio by UXPin.