Can’t make the #ChromeDevSummit this year? Catch all the content (and more!) on the livestream, or join your peers for a CDS Extended event at a hosted location nearby. To learn more, check out the Chrome Dev Summit 2019 website.

UX の基本

この記事で紹介するワークフローは、チーム、製品、新興企業、会社が顧客のユーザー エクスペリエンスを高めるための堅牢で重要なプロセスを作成するのに役立ちます。プロセスのさまざまな部分は個別に使用できますが、一連の手順として使用することをお勧めします。

このガイドは、Google の複数のチームが、セルフ ドライビングカーProject Loon などの問題をトラブルシューティングおよび解決するために使用するデザイン スプリント手法に基づいています。

ダブル ダイアモンド

この流れの仕事は、UXの世界では英国デザイン評議会によって知られているダブルダイアモンドと呼ぶものに基づいており、研究を通してアイデアを理解するためにチームを分岐し、次に課題を定義するために収束し、再びそれを分岐して個別にスケッチし、アイデアを共有し、今後の最善の方法を判断し、テストして検証します。

プロジェクトのフェーズには、理解、定義、発散、決定、プロトタイプ、検証が含まれます
英国デザイン カウンシルで最初に開発された「ダブル ダイアモンド」デザイン プロセスモデルの手順には、プロジェクトのフェーズである理解定義発散決定プロトタイプ検証が含まれます。

ステージの設定

最初に、現在根底にある課題から開始し、自分が実際に解決しようとしている課題は何かということを考え、提案などを書き出します。課題ステートメントは、目標を含む、プロジェクトに対して設定する概要文書です。

この課題は、改善が必要な既存の製品に関するものでも、まったく新しい製品に関するものであってもかまいません。 タスクがどのようなものであっても、達成しようとしている目標に合わせて言語を調整するだけです。 ステートメントは、チーム目標に関連付けられたものであり、対象読者に重点を置き、鼓舞するようなものであると同時に簡潔である必要があります。

これらは私が過去に取り組んできた製品の実生活の例です。

  • 内反足の患者の治療とフォローアップ治療を管理するシステムをデザインする。

  • 複雑な金融システムを簡素化するアプリを作成し、基本機能に絞り込む。

  • ブランドを犠牲にすることなく、異なるプラットフォーム間で一貫したモバイルアプリを設計する。

課題ステートメントの更新

目標のバリエーションをいくつか書いたら、それをチームに提示して合意を得ます。チームが問題に集中するのに役立つので、期限を含めることをお勧めします。調整を追加すると、上記のリストは次のようになります。

  • 内反足の 2 歳未満の子供の治療とフォローアップ治療を管理するシステムをデザインする。提供開始は今年の第 1 四半期。
  • 2017年7月の最初のローンチで、金融業界の知識がなくてもボタンを押すだけで株式を売買できるシンプルな金融アプリを作成します。
  • 複数のプラットフォームに柔軟に対応し、各プラットフォームに会社のブランドを効果的に配置するデザインガイドを作成する。期限は年内。

課題ステートメントを完成させたら、それを目立つ場所に掲示して、作業中に確認できるようにします。 絶えず読み返す必要があり、プロジェクトを通して更新または変更することもあります。

問題の検証

次のステップでは、問題を調査して把握します。確認する必要があるのは、チームが問題を正確に理解しているかどうかということです。多くの場合、問題を自分の視点でとらえていますが、これは危険です。私たち技術者は実際にはパワーユーザーであり、ユーザーの少数派にすぎないからです。私たちは積極的に意見を言う少数派であり、問題になっていない場合でも実際には問題であると思い違いをすることがあります。

データを収集して問題を検証する方法はさまざまです。方法はそれぞれ、チームや、ユーザーへのアクセス権があるかどうかによって異なります。 目的は、現在発生している問題をより的確に理解することです。

利害関係者との社内インタビュー

利害関係者とのインタビューは、会社またはチーム全体を分析するのに有益です。
利害関係者とのインタビューは、会社またはチーム全体を分析するのに有益です。

インタビュー プロセスでは、マーケティングから会計に至るまで、各チームメンバーや利害関係者にインタビューします。これにより、実際の課題に関する考えや可能な解決策に関する考えを把握できます。ここで言う解決策とは、技術的な解決策ではなく、会社や製品の最良のシナリオと最終目標のことです。たとえば、「年末までに 80% の医療施設に内反足ソフトウェアを配置する」という前述の問題は、目指すべき大きな目標です。

注意点が 1 つあります。この検証方法では、チームのディスカッションやコラボレーションが妨げられ、組織に閉鎖的な雰囲気が生まれるため、あまり好ましくありません。それでも、クライアントや、他の方法では見落とす可能性があるデザイン上の課題に関する有益な情報が得られる場合があります。

ライトニング トーク

ライトニング トークは、わずか数分間の短いプレゼンテーションです。
ライトニング トークは、わずか数分間の短いプレゼンテーションです。

これは社内インタビューに似ていますが、すべての利害関係者を 1 つの部屋に集めます。 次に、5、6 人の利害関係者(マーケティング、営業、デザイン、会計、研究など)を選び、最大 10 分間、自分の視点で課題を中心に話をしてもらいます。プレゼンテーションで話す必要があるトピックは、次のとおりです。

  • ビジネスの目標
  • 自分の視点でのプロジェクトの課題(技術的、調査収集、デザインの課題など)
  • 現在行っているユーザー調査

最後に、メモを取る人を選んで 5 分間の質問時間を設けます。 終わったら、問題を更新して新しく習得した知識を反映します。 目標は、製品目標の達成に役立つ機能またはフローを促す箇条書きのリストを収集することです。

ユーザー インタビュー

ユーザー インタビューは、特定のタスクにおけるユーザーの問題点を把握するのに適した方法です。
ユーザー インタビューは、特定のタスクにおけるユーザーの問題点を把握するのに適した方法です。

ユーザーのプロセス、問題点、フローについて把握する最適な方法です。 少なくとも 5 件のユーザー インタビュー、アクセス権がある場合はさらに多くのユーザー インタビューを手配してください。次のような質問をしてください。

  • 既存のタスクをどのように完了するか。たとえば、前述の金融アプリの課題を解決する場合は、「株式を瞬時に購入するにはどうしますか。」と質問します。
  • このフローについて好きな点は何ですか。
  • このフローについて嫌いな点は何ですか。
  • ユーザーが現在使用している類似製品は何ですか。
    • 好きな点は何ですか。
    • 嫌いな点は何ですか。
  • 魔法のつえを持っていて、このプロセスについて 1 つ変更できるとしたら、何を変更しますか。

インタビューの目的は、ユーザーに現在の課題を話してもらうことです。それは自分が議論することではないため、できるだけ静かにしている必要があります。これは、ユーザーが話すのをやめたときにさらに重要になります。必ずユーザーの考えがまとまるまで少し待ってください。話すのを数秒間やめた後、かなり話し続けることに驚くことでしょう。

その間メモを取り、可能な場合は会話を録音すると、聞き逃した可能性のある内容を聞きなおすことができます。目標は、課題を、自分で集めたユーザー分析と比較することです。これらは一致しているでしょうか。課題ステートメントの更新に役立つことを習得できたでしょうか。

民族学的実地調査

自然な環境にいるユーザーに会うことは、ユーザーが自分自身の課題をどのように解決するかを把握するのに最適な方法です。
自然な環境にいるユーザーに会うことは、ユーザーが自分自身の課題をどのように解決するかを把握するのに最適な方法です。

ここでは、買い物をする方法、仕事をする方法、SMSメッセージを送信する方法などを実行しながら、現場でユーザーを観察します。聞きたいしかし、ユーザーが自分でアクションやタスクを実行するのを見れば、それは洞察に満ちたものになる可能性があります。基本的にあなたは干渉することなく観察しています、彼らが容易であるか難しいと感じるものと彼らが逃したかもしれないものに注意してください。目標は、ユーザーの環境に没頭して、ユーザーの問題点をより的確に共感することです。

通常、この方法では、作業に長い時間がかかり、リサーチャーがプロジェクトのこの部分をリードする必要があります。ただし、自然な環境で調査対象のユーザーに会う機会が得られれば、最も分析に役立つでしょう。

まとめ

プロジェクトの習得段階が完了したら、最後にもう一度だけ課題を確認する必要があります。 正しい道にいますか。調整が必要なものはありませんか。 習得した知識をすべて書き留め、カテゴリに分類してください。 これらは、解決する問題に応じて、機能またはフローの基本となります。 課題の更新や修正に使用することもできます。

十分なフィードバックと分析が得られたら、次に、その知識をプロジェクト マップの作成に応用します。

プロジェクト マップ

解決しようとしている問題は、通常はプロジェクトのフローに関係のあるさまざまなタイプのユーザー(またはプレーヤー)で構成されています。習得した知識に基づいて、考えられるプレーヤーをリストします。 ユーザータイプまたは利害関係者、たとえば、「内反足を治療する医師」、「内反足の患者」、「患者の世話をする介護者」などがあげられます。各プレーヤーを用紙の左側に記入します。アクセス権がある場合は、ホワイトボードに記入します。右側には、各プレーヤーの目標を記入します。

最後に、プレーヤーごとに、目標の達成に必要なステップの数を記入します。たとえば、「内反足を治療する医師」の目標は「内反足の患者を治療すること」であるため、ステップは、「患者をシステムに登録する」、「まず医療計画を作成する」、「医療保険のレビューサイクルを作成する」、「医療処置を行う」です。

プロジェクト マップは、各ユーザーまたはプレーヤーの主なステップをフローに書き出したものです。
プロジェクト マップは、各ユーザーまたはプレーヤーの主なステップをフローに書き出したものです。

そのため、プロジェクト マップには、プロセスの主なステップが含まれます。詳細が多すぎないプロジェクトの概要と考えてください。 チームメンバーは、マップが課題ステートメントに一致しているかどうかを判断できます。 後で各ステップを分析するときに、詳細がわかります。 ただし、現時点では、プロジェクト マップは、ユーザーが最終目標を達成するために実施するステップの概要を示します。

ワイヤーフレームとストーリーボードの作成

Crazy 8s

これについては、8 つのパネルができるように紙を折る Crazy 8s と呼ばれる方法をお勧めします。次に、各パネルに、これまでに習得したすべての知識をもとにアイデアを描画します。10 分間でアイデアを出して 8 つのパネルすべてに描画します。20 分以上にすると、ぐずぐずしたり、コーヒーを入れに行ったり、メールを確認したり、チームと一般的な話をしたり、仕事を避けたりする可能性があります。迅速かつより効果的に仕事をせざるを得なくなるため、このステップで切迫感を生み出すことができます。

チームで作業している場合は、全員に自分の仕事をしてもらうよう促します。このプロセスにより、脳が始動し、問題について考えるようになります。通常、スケッチがインターフェース デザインのワイヤーフレームになります。

その後、自分とチームの他のメンバー全員がアイデアをグループに提示します。全員が 8 つの各アイデアの詳細と特定のパスをたどることを選択した理由を説明する必要があります。各チームメンバーに、習得した知識を利用して自分のアイデアを正当化するよう促します。全員がアイデアを提示したら、次はアイデアに投票します。各個人には 2 つのスティッキー ドットがあり、どのアイデアにも投票できます。本当に気に入っている場合は 1 つのアイデアに 2 回投票することもできます。

Crazy 8s は、すべてのアイデアをページに書き出す最適な方法です。
Crazy 8sはアイデアの全てを一つのページにまとめるのに素晴らしい方法です。
次に、習得した知識に基づいて、詳細なデザインを行う必要があります。
次に、習得した知識に基づいて、詳細なデザインを行う必要があります。

デザインの改良

投票後、最多得票のアイデアを採用し、最終的なアイデアを作成します。同僚から聞いた他のアイデアを借りることもできます。10 分間でこのタスクを完了します。完了したら、再びアイデアをチームに提示し、前回のように投票します。

アイデアのストーリーボードの作成

ストーリーボードは、スケッチとアイデアを 1 つのフローにまとめたものです。
ストーリーボードは、スケッチとアイデアを 1 つのフローにまとめたものです。

デザインを手元に置き、ユーザーのエンゲージメントのストーリーボードを作成します。このときまでに、ユーザーが実施する別のステップについて考えておく必要があります。同僚のデザインもフローに組み込むのはよくあることです。ユーザーが発散する可能性があるいくつかのポイントを明確な段階的プロセスに含める必要があります。プロジェクト マップに戻り、デザインを目標に照らして検証してください。

プロトタイプの作成

プロトタイプの作成は、完全なコードを作成することではなく、誰かが使用したときにリアリティのあるものを作成することです。プロトタイプの作成に使用されるツールは、人によって異なります。Keynote や PowerPoint では、デザインの詳細ではなくフローについて考える必要があります。Balsamiq、Marvel、Framer など、より動作を制御できるツールの習得に時間を費やすこともできます。使用するツールにかかわらず、フローに重点を置くことができ、本物のように見えるものにします。プロトタイプは、できるだけリアリティのあるものにする必要があるため、現実のユーザーがする必要があります。ただし、作成に数週間かけるべきではありません。

プロトタイプは、リアリティのあるものにする必要があります。
プロトタイプは、リアリティのあるものにする必要があります。

プロトタイプの作成では、時間とリアリティのバランスをとる必要があるため、極端にどちらか一方に傾かないように注意してください。 いずれの場合も、最終的に時間を無駄にすることがあります。

デザインのユーザビリティ テスト

テストラボがあると最高です。ない場合でも、ユーザーにとって気が散らない快適な環境の作成を意識している限り、テストラボの作成は難しくありません。通常、テストにはユーザーと 2 人のチームメンバーが参加し、1 人はメモを取り、他の人は質問をします。ハングアウトなどのアプリを使用してアクションを録画することをお勧めします。これは、チームの残りのメンバーに別の部屋から見てもらう場合にも便利です。アプリメーカーである我々はデザインを自然の状態で見ているため、これを行うことにかなり恐怖を感じます。これは斬新で目の覚めるような経験となり得ます。

ストーリーボードは、すべてのスケッチとアイデアを 1 つのフローにまとめたものです。
ストーリーボードは、すべてのスケッチとアイデアを 1 つのフローにまとめたものです。

質問の内容

デザインをテストするときに、ユーザーにアプリのタスクを実行して、実行している内容とその理由を声に出して話したり、言葉で表現したりしてもらいます。これは奇妙なことですが、ユーザーが何を考えているか聞くことができます。ユーザーに割り込んだり、ユーザーが行き詰ったときに何をするべきかを教えないでください。完了後(または未完了時)に特定のフローを選択した理由を聞くだけです。

知る必要がある内容は次のとおりです。

  • プロトタイプについて好きな点は何か。
  • プロトタイプについて嫌いな点は何か。
  • 問題点は何か。
    • フローが機能した理由
    • フローが機能しなかった理由
  • ユーザーは何を改良したいか。
  • デザインまたはフロー全体はユーザーのニーズを満たしているか。

デザインと再テストの再検討

作業中のプロトタイプにフィードバックがあります。ここで、デザインを見直し、何が動作して何が動作しなかったかを分析します。 まったく新しいワイヤーフレーム ストーリーボードを作成することを恐れず、新しいプロトタイプを作成してください。 最初からやり直すほうが、以前のプロトタイプで物事を先に進めるよりも優れたフローを作成できます。 プロトタイプにすぎないので、懲りすぎないようにしてください。

デザインが完成したら、再テストしてさらに改良します。プロトタイプがまったく的中しない場合は、プロジェクトが失敗しているのではないかと心配になることがあります。実際には失敗していません。実際にデザインを構築した場合よりも開発時間が短かった可能性があり、ユーザーの実際の好みをもっとよく知っています。デザイン スプリントでは、成功または習得の指針を掲げています。アイデアが計画どおりにうまくいかなくても、自分をあまり責めないでください。

実行

アイデアのテストが完了しました。ユーザーはそのアイデアを気に入っています。利害関係者は、最初から参加しているため注目しています。次は実行です。既に、実行する必要があることとエクスペリエンスの優先度を明確に把握しているはずです。プロジェクトの各マイルストーンで、作業の検証や管理に役立つユーザビリティ テストの導入が必要になることがあります。

正しい解決策ではない可能性があるものに多くの作業、時間、労力を注ぐ前にできるだけ多くの情報を得ることの重要性は強調できません。

この記事では、UX の基本的な知識と UX の重要性を示します。UX はデザイナーまたはリサーチャーの役割とみなすべきものではありません。実際には、プロジェクトに関係するすべての人の責任であり、すべての機会に参加することをお勧めします。

フィードバック

Was this page helpful?
Yes
What was the best thing about this page?
It helped me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had the information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had accurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was easy to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
No
What was the worst thing about this page?
It didn't help me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was missing information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had inaccurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was hard to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.