UX向上につながる デザイン駆動型開発 とは？
UX（ユーザーエクスペリエンス）と機能を優先させることで、ソフトウェア作成へのアプローチ方法が変わり、それがデザイン駆動型開発（Design Driven Development）の台頭へとつながりました。このアプローチは美的感覚を追求するものではなく、エンドユーザーを理解、共感および共鳴するソリューションを提供するものです。
※ここでのブログではデザイン駆動型開発の頭文字をとって「DDD」と表現します。
主なポイント：
- デザイン駆動型開発（DDD）は UXを優先し、デザインを後付けから製品作りの方針に変える。
- DDDの手法で、製品がエンドユーザーと共鳴することが保証され、それによって手直しが減り、市場投入までの時間が短縮される。
- 製品のデザインと機能性は、想定された希望ではなく、現実のユーザーのニーズに対応する。
- DDD における課題は、美的感覚と実用性のバランス、デザイナーとデベロッパーのハンドオフの管理、組織のサイロのナビゲートなどから生じる。
UXPin Merge テクノロジーはデザインと開発のギャップを埋めることで連携が強化され、現実的でユーザー中心のプロトタイプが促進されます。
UXPin Merge のテクノロジーで、ユーザーの心に響くデザイン駆動の製品を実現しませんか。こちらから UXPin Merge をぜひご覧ください。
デザイン駆動型開発とは
デザイン駆動型開発（DDD）は、デザインを製品開発の最優先事項として考えます。デザインを単なる美しさの後付けとして扱うのではなく、ソフトウェアの方針であり機能性を左右する極めて重要な役割と考えます。
業界では厳格な「ウォーターフォールモデル」から適応的な「アジャイルプロジェクト管理フレームワーク」へのシフトで、迅速なイテレーション（反復）とユーザー中心のソリューションの必要性が浮き彫りになりました。
DDDは、迅速な反復のためにもデザインの力を活用することで、確実に製品が機能、エンドユーザーの共感を得ることにつながります。
DDDを理解するには、ソフトウェア開発のライフサイクルにおける影響を認識する必要があります。新機能、アーキテクチャ、コード自体にも影響することから、開発者は早期段階でデザインチームから明確なロードマップを受け取ります。
これによって、ターゲットのユーザーに愛される製品、修正回数の減少、市場投入までの時間の短縮、開発プロセスの効率化が実現します。
デザイン駆動型開発の例
例えば、ターゲットは都会でウォーキングをする人向けの運動追跡を目的とした「FitStride」というサービスを提供するスタートアップ企業があったとします。
従来の手法を用いると、開発者がステップを追跡するアルゴリズムを作成し、その周りに基本的なUI（ユーザーインターフェース）を構築することから始まるかもしれません。
しかしながら、この手法では最終製品とその機能性について多くの仮定が必要になることが問題になってしまいます。最終的に、元に戻したり、再デザインしたりすることになる可能性があるからです。そこで、ユーザーのニーズを理解し、適切なソリューションをデザインするために、”デザイン駆動型開発”アプローチを採用します。
まずはユーザーリサーチから始めましょう。都会のウォーキング愛好家は「のんびりとした散歩」と「長い通勤」を識別できないことに不満があることがわかったとします。
このインサイトに基づき、UXデザイナーはユーザーがウォーキングのタイプや気分をタグ付けできるインターフェースを作成し、歩くペース、「リラックス」または「急ぎ」といった気分・目的に応じて、最適なルートを提案する機能も組み込めることができます。
これで開発者にとって明確な設計図を受け取れたので、歩き方の区別、またはルートを提案するアルゴリズムを作成し、その機能をインターフェースにスムーズに統合します。
そして発売と同時に、FitStrideは直感的なデザインとユニークな機能で賞賛を集め、デザイン駆動型のアプローチの有効性を確信できるでしょう。
これは１つの例ですが、製品開発チームがUXリサーチとデザインのインサイトを活用して、実際にユーザーのニーズを満たしたことを示せるものです。
デザイン駆動型開発 の仕組み
デザイン駆動型開発を理解するには、その段階的な手順を詳しく理解する必要があり、各フェーズは、ユーザーが開発サイクルの中心にいることを確実にするために重要です。
以下でその展開を見てみましょう：
ステップ１：ユーザーリサーチ
DDD の基礎は、主に以下を通してユーザーを理解します：
- アンケートおよびインタビュー：ユーザーとの直接の会話（対面またはリモート）やアンケートによって、本質的なインサイトを集め、彼らが何を求めているかを聞くのではなく、彼らのペインポイント、ニーズ、願望を理解する。そして、この情報は意思決定のための生データとなる。
- ユーザーペルソナ：データを集めた後、代表的なユーザープロファイルに合成する。このペルソナは単なる架空のキャラクターではなく、実際のフィードバックに基づいており、ペルソナで、チームが誰のためにデザインしているかが視覚化され、ユーザーに焦点を当てた明確な方向性を確保することができる。
- ジャーニーマップ： デザイナーはペルソナを使ってユーザーのジャーニーをマッピングし、各ユーザーとのインタラクションをマッピングすることで、摩擦のある部分と喜びの瞬間をピンポイントで特定することができる。このエクササイズで、UX の全体的なビューを得られる。
ステップ２：要件の収集
明確さが非常に重要です。このフェーズでは、リサーチの段階で集めた幅広いインサイトを、絞り込み、並べ替え、優先順位付けをして、次のステップとデザイン決定の指針とします。
- ステークホルダー間の連携： 製品の成功は、全員のビジョンの一致にかかっており、デベロッパー、デザイナー、ビジネスにおけるステークホルダーと定期的に接点を持つことは、ユーザーニーズとビジネス目標について全員が確実に同じ方向を向いているようにするために不可欠である。
- 機能リストの作成： 常にユーザーニーズに根ざした潜在的な機能をリストアップする。できるだけ多くの機能を追加することではなく、純粋に UX を上げる機能を選択することが目的である。
ステップ３：デザインおよびアイデア出し
- スケッチおよびアイデア出し： 部門横断的なチームが協力してソリューションのアイデアを出す。多様なスキルセットと組織目標を持つチームメンバーからの意見により、デザイナーは確実にユーザーと会社のためになるデザインを開発する。
- デザインの作成：デザイナーはデザインツールに持ち替え、ワイヤーフレームとモックアップを作成する。ワイヤーフレームはナビゲーションやアーキテクチャを決定し、モックアップでボタンやメニュー、色やフォントなどの UI デザイン要素が洗練される。
ステップ４：プロトタイプおよびユーザーテストのデザイン
- プロトタイプのためのツールとプラットフォーム： 正確なユーザーフィードバックを得るには、適切なプロトタイピングツールの活用が不可欠である。UXPin Merge のテクノロジーだと、デザイナーは React コンポーネントをデザインエディタにインポートして、最終製品のように見えるインタラクティブなプロトタイプを作成できる。
- ユーザーのフィードバックを集める： インタラクティブなプロトタイプを使って、ユーザーとデザインを対話させる。それでユーザーからのフィードバックから、ユーザビリティの問題点やビジネスチャンス、改善点が明らかになる。
ステップ５：デザインハンドオフおよび開発
- デザイナーとデベロッパー間のハンドオフ： 最終製品がユーザーのニーズに適合するように、効果的なコミュニケーションによって、デベロッパーはデザインの意図を確実に理解する。
- デザインシステムとコンポーネントライブラリ： 共通のデザインシステムを確立することで、製品全体の統一性が確保され、ユーザビリティが上がる。
ステップ６：反復的フィードバックのループ
- UAT（ユーザー受け入れテスト）： 実際のユーザーが、開発した製品を実際の環境で操作する。彼らのフィードバックによって、先に決定されたデザインが実世界で共鳴するかどうかが検証される。
- A/Bテスト： デザインとは、多くの場合は「選択」であり、ユーザーにさまざまなバージョンを提示し、変更を加え、反復することで、どのデザイン要素が最もうまく機能するかを見極めることができる。
ステップ７：起動および反復
ジャーニーは発売で終わりではなく、製品チームは、最終製品や実世界の体験にデザインが与える影響を評価しないといけません。
- リリース戦略： 段階的なロールアウトを選ぶにせよ、完全なリリースを選ぶにせよ、その戦略はユーザーからのフィードバックとビジネス目標に依存する。
- 継続的フィードバックと反復的開発： 発売後、製品は進化する。フィードバックのループを維持することで、製品はユーザーのニーズや市場の需要に継続的に合致していき、反復するたびに洗練されて改善されていく。
デザイン駆動型開発の課題
DDD の開発を取り入れることで、ユーザー中心の製品が約束されますが、その道のりには課題がないというわけではありません。
形と機能のバランスを取る
- 課題：見た目の美しさは重要だが、あまりにも精巧なデザインだと機能性が薄まり、「ユーザーのニーズに効果的に応えられない美しい製品」をユーザーに提供してしまう可能性がある。
- 解決策：基盤となる機能を優先する。 機能的な基礎となるレイヤーを設定し、使いやすさを損なうことなくUX を向上させる要素をデザインする。 ユーザーと一緒にデザインを定期的にテストすることで、フォームが機能を妨げていることを明らかにすることもできる。
デザイナーとデベロッパーのシームレスなハンドオフの実現
- 課題：デザイナーとデベロッパー間のコミュニケーションの誤りにより、製品が意図されたデザインから逸れ、時間とリソースが無駄になる可能性がある。
- 解決策：開発サイクル全体を通じて、デザイナーとデベロッパーの間で定期的に接触してレビューを実施する。 UXPin Merge のテクノロジーは、デザインと開発の間のギャップを埋め、よりスムーズでシームレスなデザインハンドオフを実現する優れたツールである。
ユーザーニーズを満たしながら、スコープクリープ（時間と共にプロジェクトの要件が増加すること）を避ける
- 課題：プロジェクトが進むにつれて、当初想定していなかった機能の追加や、変更を加えたりしたくなり、プロジェクトのスケジュールや予算が危うくなる可能性がある。
- 解決策：確定されたユーザーペルソナとその中心的なニーズに焦点を合わせる。フィードバックは非常に貴重だが、提案されたそれぞれの変更を、主要なユーザーゴールへの影響と照らし合わせて判断する。提案された機能がその目標に合致しない場合は、将来の反復のために保留にするか、さらなる調査を行うことを検討する。
組織のサイロを克服する
- 課題：多くの組織では、各部門がバラバラに仕事をしており、それによって DDD の協調的な性質を阻害するようなバラバラのプロセスができてしまう。
- 解決策：部門を超えた連携の文化を育む。定期的なワークショップや合同セッションを実施することで、各部門が互いの役割を理解し、理解し合うことができる。また、目標と KPI の共有によって、全員が統一された目標に向かって取り組むことができる。
UXPin Merge でデザイン駆動型の開発プロセスを強化する方法
DDD の開発戦略を成功させるには、デザイナーとデベロッパーの強固な連携、そして部門を超えた連携が不可欠です。
従来の画像ベースのツールは、静的デザインとインタラクティブなコード製品の間の溝により、このギャップを埋めるどころかむしろ開げてしまいます。
デザインと開発の溝を埋める
従来の DDD ワークフローでは、デザイナーがモックアップを作成し、それをデベロッパーがコードに変換していました。
UXPin Merge テクノロジーだと、デザイナーはコードコンポーネントをデザインプロセスにインポートする「コードからデザインへ（Code-to-Design）」のワークフローを作成することで、このワークフローの切り替え、静的な画像ベースのツールの排除、デザインと開発のギャップを埋めることができます。
情報に基づいた迅速な反復の促進
Merge のコードコンポーネントを使うということは、デザイナーが最終製品に正確に類似したプロトタイプを作成できるということです。
この真正性により、従来のデザインツールではできなかった、リアルなインタラクションとダイナミックなユーザー体験に基づいた正確なユーザーテストと有意義なフィードバックが保証されます。
ステークホルダーの結束したコミュニケーションの確保
UXPin Merge はデザイナーとデベロッパー間のギャップを埋めるだけでなく、ステークホルダーがレビューやコメントをできる、統一されたプラットフォームを提供します。
そのため、製品チームはUXPinのコメント機能と Slack統合を使ってフィードバックを一元化することで、コミュニケーションの不具合や提案の見落としを減らすことができます。
UXPin Merge のテクノロジーで、現実に根ざしたデザイン駆動型の開発ワークフローを作りませんか。こちらから UXPin Merge をぜひご覧ください。
