人とチーム

製品Xの節約–デザイン思考のケーススタディ

デザイン思考とは何ですか？

あなたがアイデアを持っていると想像してみてください。あなたはあなたのビジネス上の問題を解決すると思う独創的なアプリケーションを思いつきます。現在、市場には同一のソリューションはなく、最も類似しているソリューションは、顧客が期待する方法で実際に機能していません。

あなたのビジョンはまだ新鮮ですが、頭に浮かぶ最初の基本的な質問について考え始めます。「それを成し遂げるのにどれくらいの時間がかかりますか？」

そして、無制限の予算と時間で自分自身を見つけることはめったにないので、2番目の結果として生じる質問はすぐに来ます：「それをするのにどれくらいの費用がかかりますか？」

これらは両方とも、製品を作る上での基本的かつ重要な質問ですが、多くの場合、最初から正確に間違った質問です。

代わりに、最初に尋ねる最も重要な質問は次のとおりです。 「ユーザーにどのような価値を生み出すことができますか？」

プロジェクトの範囲、要件、およびタイミングをよりよく理解するために、「デザイン思考、」は、製品の「発見段階」で役立ちます。これはまさに私たちが理解する必要がある時だけではありません何素晴らしい製品になるだけでなく、 どうやって そしてもし私たちはそれをすべきです。この創造的で実験的なアプローチは、使用できるだけでなく、何よりも有用なものを作成する方法をよりよく理解するのに役立ちます。

デザイン思考プロセスは、知識という独自の具体的な結果を生み出すため、特に役立ちます。

この方法論にはより広い使用範囲ただし、このデザイン思考のケーススタディでは、ソフトウェア製品開発という1つの特定の分野にのみ焦点を当てます。

デザイン思考の理論

デザインシンキングの実際のアプリケーションとそれを適用した私の経験を掘り下げる前に、デザインシンキングのプロセスを詳しく見ていきましょう。

デザイン思考は、問題を解決するためのソリューションベースのアプローチを提供する方法論です。人間中心の視点で、ユーザーの視点を理解することに焦点を当てています。この方法論の力は、アイデア、ソリューション、または拡張機能がお客様に実際の結果をもたらすことができるかどうかを迅速にテストできることです。デザイン思考の目的は、さまざまな分野（マーケティング、心理学、デザイン、ビジネス）からのさまざまな方法論、ツール、および技法を統合して、ユーザーを解決しなければならない問題の中心に置くことです。

この方法論の目標は、「ユーザー自身を見つけてそのニーズを定義する」ことであり、それらのニーズを見つけることによって、本当に役立つソリューションまたは製品を作成することです。この目標を達成するために、コンセプト全体が6つのデザイン思考フェーズに分割されます。

デザイン思考フェーズの図。

レガシーシステムからのデータ移行

共感する： このフェーズの目標は、顧客のビジネスに関する情報を検索および収集することにより、顧客を理解することです。このフェーズでは、インタビュー、フォーカスグループ、観察、調査など、いくつかの異なるツールを使用できます。
定義： このフェーズでは、共感フェーズから情報を収集して分類します。ここで、ユーザーペルソナとユーザージャーニーを定義します。
考案： 上記の情報を使用して、ここでチームは解決策を考えます。ばかげたアイデアや間違ったアイデアはありません！すべてを表現し、文書化する必要があります。
プロトタイプ： このフェーズでは、具体的なものが作成されます。これにより、実際の生活でアイデアを検証できます。このMVPを過度に複雑にして、できるだけ早く作成しないでください。
テスト： 実際のユーザーと実際にアイデアを検証します。反応を得ます。それを改善する方法について質問してください。
実装： これは、収集されたすべての知識が最終製品に変換されるフェーズです。

これを読んだ後、「これは素晴らしいことですが、これが私のアプリをすばやく実現するのにどのように役立つのか」と考えているかもしれません。これをより具体的にするために、私はデザイン思考プロセスから恩恵を受けた私の個人的な経験からのケーススタディを検討します。

デザイン思考の応用-実際のケーススタディ

イントロ：プロジェクトX

しばらく前、私は起業家とのミーティングで自分自身を見つけました。少数のマネージャー、そして部屋の周りを飛び回る多くのアイデア。彼らの直接の競争相手は最近新しいアプリケーションをリリースし、緊張は明白でした。同社は、競合他社に負けないように、市場に出回っている新しいものを売り出したいと考えていました。

彼らは、いくつかの要件、製品がどのように見えるべきか、そしてそれがいくらかかるべきかについての漠然とした考えを含む文書を作成しました。

「私たちは他の人がしたことをより低い価格で従わなければなりません」とマーケティングディレクターは言いました。「ユーザージャーニーを簡素化する、より使いやすいシステムを作成する必要があります」と別のマネージャーは付け加えました。「情報を収集する方法を変更し、情報を簡素化し、プロセスをサードパーティと統合する必要があります」と別の人は言いました。「それは私たちに数ヶ月かかるでしょう」とテクニカルマネージャーは首を横に振った。彼はそれらすべての要求を実装するために数百時間のコードに精神的に翻訳した。

プロジェクトの詳細をすべて開示することはできませんが、製品がハブ通信ソフトウェアであったことは開示できます。このソフトウェアは、さまざまなチャネル（EメールからSMS、FAXからVoIP）を管理し、Webおよびモバイルプラットフォーム用に作成されました。もともとは数年前に作られたものですが、使い勝手が悪かったです。発売当時、競合他社はユーザーエクスペリエンスの面ではるかに進んでいました。さらに、彼らは優れたモバイルアプリを持っていて、それはモバイルアプリストアで定着していました。

X社は、従来のプロジェクトに精通した、従来のプロセス主導型の企業でした。それはいくつか実行されましたアジャイルプロジェクト以前は、MVPを作成して市場でテストするというアイデアは初めてでした。さらに注目すべきことに、彼らは未知のものを恐れていました。新しいMVPが顧客のユーザーベースに望ましくない、または予測できない影響を与える場合はどうなりますか？このコントロールの欠如は自信を刺激しませんでした。

上記および以下の会議では、実際に達成すべき製品が何であるかを明確に定義することはできませんでした。私たちは、できるだけ早く目標を達成する必要があることを知っていました。

しかし、プロジェクトが進行し、競合他社が勢いを増し始めたため、会社からの同意が固まりました。「半製品を発売する余裕はありません。最初から機能する製品が必要です」という考えにほとんどの人が同意しました。

初期の困惑と恐れにもかかわらず、これは、合理化された軽量製品を作成することで、ユーザーベースに真の価値をもたらし、潜在的により多くのユーザーを引き付けるものを学ぶ機会でした。

これにより、会社は、発売時に重要な機能しか持たない場合でも、完全な製品を時間どおりに構築するために、これまで試したことのないアプローチを探すようになりました。デザイン思考プロセスを使用し、エンドユーザーに本当に価値をもたらすものに焦点を当て、顧客に必要なものだけを提供することで競合他社に打ち勝つことにしました。

ステージ1-共感する

共感フェーズ： このフェーズの目標は、顧客のビジネスに関する情報を検索および収集することにより、顧客を理解することです。このフェーズでは、インタビュー、フォーカスグループ、観察、調査など、いくつかの異なるツールを使用できます。

共感フェーズで使用されたサンプルグラフの画像。

最も文字通りの意味で、共感は他人の感情を理解し、共有する能力です。デザイン思考では、共感は「深い理解あなたが設計している人々の問題と現実について。」

私たちの最初のステップは、最高賃金の人の意見（別名HiPPO）が他の人の意見を支配していないことを確認することでした。そのため、経営者や創設者とともに、意思決定プロセスに関与する可能性のある利害関係者のリストをまとめました。

1日の会議で、直接連絡できる30人の名前（従業員、機能マネージャー、顧客の間）の最初のリストを作成し、4000人の顧客（定期的な顧客ユーザーの約10％）のターゲットオーディエンスも選択しました。ベース）。

性別の分布、業界、その他のデータポイントの多様性を含めることにより、ターゲット顧客ベースを可能な限り「正規化」しようとしました。さらに複雑さを増すために、インタビュー対象のサンプルの物理的な場所はすべて、さまざまな都市、場合によっては国に分けられました。これで、インタビューやアンケートを実施するための連絡先ができました。

このグループは、スクリプト化された一連の質問といくつかの基本的なルールに従って、リモートでインタビューを実行するように編成されました。

面接中は、「 5なぜ」テクニック。
すべての行動の背後にある主な「何を、どのように、なぜ」を理解するようにしてください。
インタビュイーがウェブカメラを使用していること、およびカメラから少なくとも部分的にボディランゲージを含めることができる十分な距離があることを確認してください。
将来見られる必要がある場合に備えて、すべてのインタビューを記録します。

ユーザーのニーズに対応する新しいバージョンをすばやく作成できるように、どの主な機能を強化または削除する必要があるかを理解することを目的として、インタビューの質問を準備しました。

2番目のユーザーグループのために、Googleフォームで一連の質問を用意しました。クローズドベータ版で利用可能な製品の新しいバージョンを試すようにユーザーに要求する質問など、ユーザーからのより多くの対話を容易にするために、いくつかの定式化された自由形式の質問とともに、多肢選択式の質問を選択しました。

情報収集プロセス全体を整理するために、Skype、Zoom、Googleフォーム、すべてのアクティビティを配置してステータスを追跡するデジタルかんばんボードなど、チームが情報をより簡単に収集できるリモートツールを使用しました。

情報収集のサンプル図。

面接対象者はシステムの弱点と長所についてフィードバックを提供することにオープンであったため、面接の最初の結果は心強いものでした。

ただし、アンケートの回答の最初のバッチはそれほど刺激的ではありませんでした。送信された300通の電子メールすべてのうち、5人だけがアンケートに回答しました。

この結果に失望した私たちは、営業マネージャーの1人が次のアイデアを思いついたときに、ユーザーベースを巻き込む新しい方法を試す準備ができていました。

「彼らがメールに返信することはないと思います。彼らは私たちとのやり取りに慣れていません。しかし、更新の期限が切れるすべての人と連絡を取り、小さなインセンティブを与えると、彼らは私たちに手を差し伸べると確信しています。」

アイデアはシンプルですが、並外れたものでした。数時間で、新しいユーザーリスト（3800）が作成され、主流と極端の間で同じ区分が維持されました。ただし、これらのユーザーは、更新が近いため、システムとの対話を「強制」されます。

今回は、一連の質問に答え、ベータ版に参加し、その見返りとして、更新の割引を受けるように求められました。接着は完了し、この新しいモデルの最初の納品時に、ユーザーの70％以上が回答し、アンケートに回答しました。

いくつかの質問を繰り返して変更した後、何度もインタビューすることをいとわない一部のユーザーのおかげで、ユーザーベースをより明確に定義する準備が整いました。

レスポンシブデザインのメディア画面サイズ

ステージ2-定義

ステージの定義： このフェーズでは、共感フェーズから情報を収集して分類します。ここで、ユーザーペルソナとユーザージャーニーを定義します。

サンプルユーザー。

定義の辞書の意味は 概念のアイデンティティと本質的な性質を決定する 。私たちの場合、以下を定義したいと思います。

私たちの理想的な顧客
彼らの問題
彼らの問題の解決策
私たちが対処しなければならなかったお客様のニーズと恐れ

デザイン思考の用語では、定義フェーズここで、観察結果を分析し、特定した主要な問題に統合します。

実際の問題が何であるかを理解するのに十分なデータベースがありました。共感フェーズで寄せられたフィードバックに加えて、X社の従業員が強調したが経営陣に指摘されたことのないポイントや、長所、短所、その他の考慮されていない問題が含まれていました。

次のアクションは、ユーザーペルソナを作成することでした。このブレーンストーミングフェーズでは、拡張チーム全体が関与しました。ブレーンストーミングフェーズは、ビデオ会議システムとツールを使用してペルソナとその作成をリアルタイムで追跡し、常にリモートで実行されました。

ペルソナごとに、彼らの経歴、テクノロジーへのアプローチ、ソーシャルメディアの使用、優先ブランド、ニーズ、アイデアを特定し、カスタマージャーニーがどうなるかを推測しました。

この後、一般的なクライアントのユーザーペルソナを選択し、インタビューと調査から得られた一連のデータを完成させました。これは私たちの手を汚すのに適切な時期でした。

定義フェーズでは、「売上を10％増加させる製品が必要」などの問題の一般的な定義を、「35〜45歳の男性と成人女性」のようなより具体的な解決策に変換しようとしました。オフィスで働いている人は、送信者が実際に彼らが言っている人であることを確認するために、法的有効性のある通信を受信する必要があります。」

プロジェクトプロセスのこの時点で、ユーザーを中心としたブレーンストーミングセッションを完了し、ソリューションを仮定し、考えられるすべてのイノベーションに対してオープンマインドを保ちました。「唯一の愚かな考えは決して表現されないものです」というマントラがありました。

短期間で、私たちの主題が誰であるかを念頭に置いて、私たちはユーザーにとって何が有用であるか、そしてカスタマージャーニーに沿ってどのようなニーズと恐れに対処すべきかを明確に把握しました。

次に、「ユーザーストーリーマップ」の作成に取り組みました。これにより、ユーザーのプロセスを分類し、テーマにマッピングすることができました。ペルソナごとに、旅行中に完了する必要があると想定した一連のアクティビティ、ストーリー、およびタスクを定義しました。そうすることで、アイデアをすばやくテストし、それがコアニーズを満たしているかどうかを理解することができました。もしそうなら、競合他社が日々成功を収めているため、他の誰よりも早く市場に投入することができました。

ステージ3-構想

アイデアフェーズ： 上記の情報を使用して、ここでチームは解決策を考えます。ばかげたアイデアや間違ったアイデアはありません！すべてを表現し、文書化する必要があります。

定義からさらに一歩進んだのがアイデアフェーズです。このフェーズでは、抽象的な定義だけでなく、実際の概念とソリューションを形成することが重要です。

デザイン思考の用語では、発想は、「スケッチ、プロトタイピング、ブレーンストーミング、ブレインストーミング、最悪のアイデア、その他の豊富なアイデア手法などのセッションを通じてアイデアとソリューションを生成するプロセスです。」

私たちのチームは完全に離れていたので、材料を作成してレビューするときに無駄のない方法で作業を進めることにしました。たとえば、デザイナーやチームの他のメンバーは、できるだけ速くするために、紙に描いた絵から始めて、グループ内でそれらの写真を共有することが最善の解決策であることに同意しています。そうして初めて、BalsamiqまたはAxureで最も興味深いデザインを作成できます。

サンプルワイヤーフレーム。

作成されたスケッチごとに、ユーザーから情報を収集し、一連のソリューションを定義し、それらのユーザーに戻って（可能な場合はいつでも、可能な限り頻繁に）プロセスと結果をテストしました。

ステージ4-プロトタイプ

プロトタイピングフェーズ： _このフェーズでは、具体的なものが作成されます。これにより、実際の生活でアイデアを検証できます。このMVPを過度に複雑にして、できるだけ早く作成しないでください。 _

サンプルワイヤーフレーム。

プロトタイプ段階で、ようやく私たちの定義とアイデアを実現する時が来ました。プロトタイプは提案された製品の最初のオリジナルモデルであり、これはまさに私たちが構築しようとしたものです。デザイン思考基準によると、プロトタイプ段階では、実際の製品の安価で縮小されたバージョンを作成して、前の段階のソリューションを調査します。

旅の始まりからほぼ10日後、私たちは決定的な瞬間に到達しました。開発者チームとのミーティングで、私たちの仮定と見積もりを確認する機会がありました。開発者チームとの協議と定義のセッションの後、私たちはストーリーを比較検討し、開発作業の主な取り組みはバックエンドシステムの開発と、現在使用されているレガシーシステムとのインターフェースにあることを理解しました。これに加えて、フロントエンドシステムの作成ははるかに短い演習になることもわかりました。そこで、時間を節約するために、システムにすでに存在するコンポーネントを使用してフロントエンドのプロトタイプを作成することにしました。

プロトタイプの最初のバージョンを準備するのに3日の時間制限がありました。このプロトタイプは、製品を可能な限り反映し、必要な機能を維持する必要がありました。

3日後、プロトタイプの最初のバージョンの準備が整いました。作成しようとしたソフトウェアの動作を反映した「偽の」データが含まれていました。一部のアクセサリ要素が欠落していましたが、その状態のソフトウェアは、計画されたコンテンツ全体のかなりの割合を視覚的に表しています。

2週間の作業の終わりに、実際のユーザーで試してテストできるソフトウェアができました。ユーザーエクスペリエンス監視ソフトウェアを使用して、プロトタイプをナビゲートしている間、ヒートマップとユーザーの注意を分析しました。

ステージ5-テスト

テストフェーズ - 実際のユーザーと実際にアイデアを検証します。反応を得ます。それを改善する方法について質問してください。

定義、構想、プロトタイプの段階を経て、ついに私たちの製品が実際に実際に機能するかどうかを確認する時が来ました。デザイン思考の用語では、テストとは、プロトタイピングフェーズで作成された最良のソリューションを使用して製品全体を試用することを意味します。

私たちの場合、テストフェーズは最後に行われただけでなく、可能な限りフィードバックと反復の一定のループでした。達成された各ステップの最後に、次のフェーズに進むように説得する前に、ユーザーまたは顧客からフィードバックを取得しようとしました。

ウェアラブル技術を表すオプションを選択します。

プロトタイプが完成したら、可能な限り幅広い対象者でテストし、ニーズをどの程度効果的に満たしているかを確認し、認識を理解し、目標を達成したかどうかを理解します。

テストフェーズには、ユーザーが新しいワークフローを確認してアクションを実行できるウォークスループロトタイプと、チームがユーザーの応答を追跡しながら直接ユーザーを観察するいくつかのセッションが含まれていました。簡単なアンケートを使用して、プラットフォームの特定の機能全体のコンバージョン率を収集し、ユーザーに1〜10のプロセスのスコアを付けるように求めました。

その後、テストフェーズはチーム全体に拡大され、以前のセッションでシステムの実装に関するフィードバックを提供することに喜んで同意した組織外の一部の個人（顧客とユーザー）にも拡大されました。

このテストの結果は心強いものでした。 X社の利害関係者は、モックアップを見るだけでなく、初めて製品を試して「触れる」ことができました。拡張されたチームは、2週間以内に、仮定をテストおよび検証し、時間をかけて修正する機会がありました。

今、最終テストが待っていました。それをユーザーに公開し、次に何が起こるかを理解することです。

ステージ6-実装

実装フェーズ： これは、収集されたすべての知識が最終製品に変換されるフェーズです。

gulp vs grunt vs webpack

データ、アイデア、ペルソナ、そして最初の具体的なプロトタイプがありました。袖をまくり上げて開発を始める時が来ました。新しいシステムを実装するのに1か月半かかりました。

MVPを短期間で実装するための一連のルールを定義しました。

新しい機能を追加せずに、定義したものだけを構築します。
私たちは、主要なビジネス目標に焦点を合わせ続けます。
チーム内でアジャイル手法を使用してワークロードを管理します。

プロジェクトを時間内に完了するために、発見段階のごく初期の段階からプロジェクトに関与していなかった数人の新しいチームメンバーを招きました。

フロントエンド開発者、バックエンド開発者、およびデザイナーを追加しました。チームの新しいメンバーはリモートで作業しており、プロジェクトの期間中、全員を同じ部屋に入れることはできなかったため、コミュニケーションを継続するための適切なツールがあることを確認しました。

作業を管理するために導入されたプロセスはアジャイルプロセスでした。残りの時間をいくつかの短いスプリントに分割し、毎日リモートミーティングを行い、日中はSlackを介して更新し、アイデアを交換し、互いに助け合って問題を解決しました。

完全なドキュメントをどこかに保存していませんでしたが、精神的には、チーム間で包括的な一連のアクション、共通の共有ビジョン、および目標がありました。私たちは皆、ユーザーペルソナを、彼自身のニーズと問題を抱えた実際のユーザーであると認識し始めました。私たちのチームが一致したビジョンを持ち始めたら、プロジェクトを時間どおりに完了するために何をいつ行う必要があるかを定義することに移りました。

ペルソナの元の証拠と製品に提供したいフローを維持するために、アクティビティはユーザーストーリーマップ内で概説されました。

ザ・ユーザーストーリーマップアクティビティの特定、アクティビティを完了するために必要なステップの特定、およびそれぞれに関連付けられたストーリー/タスクのリストという3つの明確なステップによって作成されました。ストーリーを優先度（Must、Should、Could）に従ってソートしました。これにより、どのコンポーネントが製品に組み込まれるかが決まりました。

チームは、チームが共有する明確なビジョンと、上記の管理者から直接操作することなくチームを軌道に乗せることができる方法のおかげで、実装の最初から速いペースで進むことができました。プロジェクトで働くすべての人は、デザイン思考の段階からの質問を念頭に置いていました。

プラットフォーム内の各ユーザーはどのようなアクションを実行する必要があり、何を達成しようとしていましたか？
これらのユーザーが最終目標を達成するために実行する必要がある手順はどれですか。
彼らが以前に持っていた問題点と、それらをどのように回避すべきか？

これにより、私たちのチームは独自の微妙な決定を下し、製品を最終目標に向けて導くことができました。

製品が最終的に生産される前に、各スプリントの最後に進行中の作業の2つのレビューを行い、パスの最後に1つの最終リリースのレビューを行いました。最後のスプリントを使用して、製品の実行と起動に必要なインフラストラクチャを準備しました。

最後に、私たちの古い製品を使用したユーザーは、新しいバージョンを試すために再び招待されました。私たちの製品は、それを作るというアイデアが表明された会議の2か月後に生産にリリースされました。製品は機能し、ユーザーはそれを使い始め、私たちは古いツールの代わりにこのツールに徐々に新しいユーザーを送りました。 A / Bテストの結果、彼らは新製品を好むことがわかり、プロジェクトは大成功として会社に受け入れられました。

さらに重要なことに、デザイン思考の方法論がついに受け入れられました。これは、長期にわたる優れた影響をもたらし、将来、より優れた製品を構築できるようになると確信しています。

結論

デザイン思考グラフ

このケーススタディを通じて、限られた時間と予算でデザイン思考の方法論を実際の問題に適用する方法を示しました。

従来のアプローチを使用して一連のステップで物を生産する代わりに、6つのデザイン思考段階を繰り返すことを選択しました。共感する。定義します。考えてください。プロトタイプ。テスト。実装します。これが私たちのモットーとなり、非常に好評の製品を生産することができました。

デザイン思考を使用することで、時間を節約し、プロジェクトに費やすコストを節約できます。私たちは何百万もの異なる機能に取り組んでいませんでしたが、チームの全員に明らかなアクションを通してよく考えられた少数の機能にのみ取り組んでいました。最も重要なことは、ユーザーが必要とする製品と価値を提供できたことです。

デザイン思考プロセスを使用することは、多くの異なる分野で私たちを助けました：

プロジェクト管理の観点から、プロジェクトのスコープを明確に定義し、スコープのクリープを防ぐことができました。
ビジネスの観点から、ビジネスに真の価値をもたらす機能を選択することができました。
開発の観点からは、構築を開始する前に構築する必要があるものの明確な目標を理解するのに役立ちました。
チームの観点からは、すべてのチームメンバーが関与し、効果的に協力して、プロセスのあらゆる部分で意見を聞くことができました。

私たちがデザイン思考のプロセスを開始したとき、クライアントは懐疑的でしたが、終了して顧客からのフィードバックを受け取ったとき、私たちがレイアウトした手順が、非常に困難なことを達成するのに役立ったこと、またはそうでなければ不可能です。これはクライアントによって評価され、将来の課題に対する社内のフラッグシッププロジェクトになりました。