自分でサービスを作るチャレンジを行いましょう。このコースでは過去のフィードバックなどの動画をシェアします
このパートでは実際に自分でユーザーを調査し、定義して、価値をデザインしてみることにチャレンジをしてみましょう。「UX入門」のやり方が解説になるので特に解説パートはなしです。（他のメンバーのフィードバック内容や補足などあれば追加していきたいと思います）
ポートフォリオの中でも大事なアウトプットになるので、まずは練習として期間を決めてやる、その後にブラッシュアップする。のもお勧めです。もしくは一旦飛ばして、全ての基礎学習が終わりポートフォリオを準備する際に腰を入れてデザインするのも良いと思います。
こちらにやる上で参考になるドキュメントを置いておきます。
https://takumikai.notion.site/484aa17fc80042c9836dae8a29646a05
解説はなく、UX入門のやり方と流れで”自分のアイデアではなく、顧客の声をベースにアイデアを出し、具体的な形”に落としてみてください。
先人のBONOメンバーの事例を紹介しています（詳しくは下のリンクでみれます）。
取り組む前にゴールイメージとやるべきこと、ポイントのイメージを持ちましょう！
『ゴールイメージ&ダメな例を知ろう！』
https://takumikai.notion.site/de1714e38740422a98744479ae248fed
実際のアウトプットを題材に「何が良くないのか」「どうすればよかったか」の改善ポイントを考えていく動画です。
自分のアウトプットもこうなってないか？という目線で見ていくと良いて思いますー！
▼ 動画で題材にしているアウトプット
https://figma.fun/UvJTgn
○ 【ヒアリング疑問】仮説あるのにユーザーインタビュー、必要なの？【フェーズで役割が違う】
ー質問に答えてます
www.bo-no.design/contents/ux-hearing-userinterview
○ この要件設定は具体的になってるのかな...？を解決する2つの方法
ー質問に答えるpart.2
https://www.bo-no.design/contents/ux-gutaika-quesition
WHYの深堀はこちらで詳しくやってます🙋♂️
https://www.bo-no.design/contents/ux-beginner04
00:05 ①Whyの深堀で考えを具体化する方法
04:43 ②アイデアを具体化するフローのイメージ
07:50 まとめ
▼ 関連
○ ”自分目線”になってない？ユーザーからアイデアに気づく手順と方法
www.bo-no.design/contents/ux-interview-feedback
○ 【ヒアリング疑問】仮説あるのにユーザーインタビュー、必要なの？【フェーズで役割が違う】
ー質問に答えてます
www.bo-no.design/contents/ux-hearing-userinterview
このテキストは、UXデザインの授業や教材の一部のようで、受講生が課題として提出した行動フローに対する講師からのフィードバックです。講師はまず、課題を解決するにはゴールを定義することが重要で、ユーザーの現状を把握する必要があることを説明しています。その上で、課題とは現状と理想のギャップであると定義づけ、ユーザー行動のフローを具体的に記述することで、現状とギャップを見極めやすくなると説明しています。受講生の提出した行動フローには、ゴールが明確でなく、ユーザー像が描かれていないため、課題が定義できず、解決策のアイデアにも結びついていないと指摘しています。
課題を解決するには、まずゴールを定義する必要がある。ユーザーがしたいこと(理想)を明確にして、現状とのギャップを課題としてとらえる。ゴールを明確にしないと、課題の定義が曖昧になり、解決策のアイデアに結びつかない。
課題とは、ユーザーの理想と現状のギャップである。抽象的な「知名度がない」「お金がない」ではなく、具体的なユーザーが困っていることを課題として定義する必要がある。
ユーザーの現状を可視化するために、行動フローを具体的に記述する。これにより、現状と理想のギャップをイメージしやすくなる。行動フローから直接課題が見えるわけではないが、課題を見つける手掛かりとなる。
□ 動画で見ているドキュメント
https://takumikai.notion.site/470c5abf075040f5952e94c8d8bf75fd
ー ー ー ー ー ー ー ー ー ー ー ー
【ライブデザインに関するご質問｜UX入門】
①「インタビューであがった意見に対する優先順位の付け方」が難しいです。
（※実務だと工数とか費用とか判断基準が色々あると思いますが、あくまで「ポートフォリオに載せる自由課題」の前提です）
例えば「サブスク管理するアプリ」をお題に4名にインタビューしたのですが
と色々意見いただきました。
こういう考えをもってこの意見の中からこんなふうに解決案（UIデザイン）に落とし込んだ」という考え方をまとめてポートフォリオに載せるのが大事だと思っているのですが、、この辺りアドバイスいただけると嬉しいです
自分は、誰の、どんな課題に対して、1番価値提供したいのか
誰
→みんな、「現状」と「課題」、「目指すものが違う」
基本敵に価値提供の図は「現状から、なりたい姿になりたいのだけど、その間にある何かが邪魔をしている。それを取り除くもの」になります。
なのでヒアリングでは基本的に「現状」「なりたい姿」「その間の障壁」を聞いて明確にする、解像度を上げることが大切になります。
が、単純に「〜〜ですか？」と聞いて答えてくれても、それが本当なのか、また、”なぜそう思うのか”が分からないとその人のことを理解したことにはなりません。
なので相手には意見を求めるのではなく、「実際に取った行動」を聞くのがコツです。
Waggleフィードバック1 - 恋愛で学ぶ課題定義
www.bo-no.design/contents/zerokara-waggle01
筋トレ継続サービスのフィードバックを受けて、顧客の原因を具体的に把握すること、解決策を顧客の感情や行動に即したものにすること、サービスの対象を絞ることの重要性が指摘されています。500文字以上の要約を3段落に分けて記載しました。
顧客の原因を具体的に深く理解することが解決策を立てる上で大切。日記を書くこと自体に注目するのではなく、なぜ日記を書いているのか、なぜ日記を見返すと励みになるのか、といった原因を掘り下げる必要がある。
解決策は顧客の現在の感情や行動に沿ったものである必要がある。ボットに相談することは筋トレを継続するためのサービスに即した解決策とは言えない。
筋トレを始める時と再開する時では状況が異なるので、一つのサービスで両方に対応するのは難しい。対象者を絞ったサービス設計が必要。
意見を聞くとユーザーさんの理想で語っちゃったり、”一般的にはこうかもね〜（私は違うけど）”が出たりします。
つまり本音ではないということなんですね。
なので、なるべく”実際にとった行動”を深堀していくのが良いです。なので、事前に”こういう時どういう行動しただろう？”とか、”どういう行動今はとってるか”をリストアップしておくと台本が作りやすいと思います。
例：BONOでロードマップ作る時
・実際にUIデザイナーに独学でなった人に
・どんな勉強をしたか？どんな順番でしたか？
・ポートフォリオを見せてもらう
＝実際に身につけたデザインスキル、勉強法がわかる（行動/事実）
質問に答える形で動画にしてみました！
学びなどはツイートやシェア歓迎です👌
？：１度インタビューして”仮説”が固まっているけどヒアリングってこれ以上必要なの？
→ 仮説を具体にしたときにちゃんと方向性が間違ってないか？具体のイメージは合っているか？
▼ 目次
00:05 仮説あれば進められるからヒアリングする必要はあるの？
02:30 仮説の確かさを上げるためにヒアリングは使える
03:40 方向性と具体案を定めるそれぞれの段階がある
06:10 インタビュー相手は同じ人が良い？
▼ 関連
○ ”自分目線”になってない？ユーザーからアイデアに気づく手順と方法
www.bo-no.design/contents/ux-interview-feedback
○ この要件設定は具体的になってるのかな...？を解決する2つの方法
ー質問に答えるpart.2
https://www.bo-no.design/contents/ux-gutaika-quesition
動画の中で解像度が高い/低いの話をしています。全体的なフィードバック内容としては「顧客の解像度を上げよう」をテーマにしゃべっています。
ユーザーの反応の裏側にある事実から、感情を紐解くことで、最初に課題のように見えることのコアにある”行動を阻害している要因”に辿りつきやすくなると思います。
完璧にやるのは難しいですが、この”阻害要因”を掴むことが課題の定義になります。
「どんな人と結婚したい？」「付き合いたい？」と聴くといろんな要素を教えてくれると思います。
ただその人が相手として選ぶ要因として全て必要か？と考えるとそうではないケースが多いと思います。
課題を見つける時、サービスの提供価値を考えるときも、何が”コア”か、行動が変わるぐらいボトルネックになっている要素なのか、そしてそれはなぜか。を発見していくことが大切になります。
Waggleフィードバック2 - 課題とヒアリングのコツ
www.bo-no.design/contents/zerokara-waggle02
サービスデザインにおいて、顧客理解を通してより良い未来のために解くべき課題を発見することが求められます。その時に自分が設定した”課題”は本当に解くべき”課題”なのか？について解説します。
多くは解像度が低すぎて「ただ起きていること」になっており、解決するべき要因/原因まで落とせていません。その解像度の上げ方も含めてお伝えしていきます。
OpenAIの原稿アイデア
ただ起こっていること、漠然と困っていることではなく、”達成の障壁になっている要因や原因”を特定できている状態。この状態に至っていると課題定義として正確であると思います！
といってもよく分からないので具体例で見ていきましょう
例えば「スパイスカレーが作れるレシピサービス」を題材に不十分な課題設定を考えてみるとこんな感じになります。
→ 課題：既存のレシピサービスではスパイスカレーのレシピが探しづらい。
ちなみに解決策はこんな感じ
→ スパイスから検索できるレシピサービスを作る
これは何が問題なのでしょうか？
問題なのは「レシピが探しづらい」というのは困っているかもしれませんが、ただ”発生していること”です。これを解決しようとすると”なぜ探しづらいのか？”が分からないとアイデアをぶつけてみても「ん〜それで解決するのか？」となると思います。
つまり発生している大元が特定できてない。ただ”発生している事象”を課題にしているのです。
「うちの子はテストの点数がいつも低い」といって親は塾に通わせるかもしれませんが、勉強を長時間やってて低いのか、全くやってて低いのか、そこそこやってて低いのか。実は授業中にずっとスマホいじってるから帰宅して勉強時間を取ってても低いのかもしれません。もしくはそもそもテスト対策してないから低いだけかもしれません。
要因がわからないのに安易な解決策を提示しても本人（ユーザー）は嫌がるか、興味を示しません。
なので要因を特定することが大事です。
この要因が特定できているか？課題をWHY-なぜで深掘りして要因を明らかにできているか？が本質的な課題かそうでないかの違いになります。
なぜ”よくない事象が発生しているのか？”を”なぜ”で深掘りをしていくことが大事です。
これをヒアリングを通して、その人の生活や心情をふかぼっていく理由になります。数字でもアンケートでも、ここを把握することは難しいです。人に聞く利点（N＝1インタビューをするメリット）がここにあります。
発生している要因を解決することこそが、真の課題解決に近づき、ユーザーの行動をポジティブな方に変化させることにつながります。原因がわからないのに当てずっぽうでアイデアを出しても顧客を理解しているとは言えません。
正しい解決策はユーザーが障壁に感じていることの原因と密接にリンクしています。
なのでUIを作る時も、この原因にフォーカスすることが大切になります。発生している課題に見えていることに対して、適切な原因を突き止める。その原因を解決できるアイデアを定義し、その解決策がUIになる。この状態ができると”ユーザーをハッピーにできるUI”をデザインする1歩につながります。かっこよくいうと真のデザインができている状態になります。
ここまで書くと、「ユーザーが課題だと言ってることを解決策にすればいいんだ！」と思うこともあるかもしれません。ただ、それは間違ってます。ユーザーの9.5割は答えを知りません。ただ感情や事象（起こったこと）を共有するだけです。その裏にある原因や要因を特定する必要がデザイナーにはあります。
原因/要因を軸に、要因を取り除くアイデアを顧客の心情に従う、ある種”縛り”のなかで、発想する。その結果解決策が顧客に紐づくものになります。
というわけで今日も楽しく人を理解して、素晴らしいアイデアをクリエイションしていきましょ〜〜〜〜！
ユーザーリサーチ前の仮説のアイデアのフィードバックをしてみました。
次にやると良さそうな行動の話をしながら、アイデア定義の考え方を喋っています。
□ 動画で見ているドキュメント
https://www.notion.so/takumikai/10-ece1645ef87f4d5795c7b2a937a9613e
■
ポートフォリオの課題解決性についてのフィードバックです。現状のUIは一通り完成しているものの、課題解決が十分でない点があるとのこと。改善点は、ユースケースを具体的に想定し、課題の要因を明確化して、その要因を取り除く解決策を考えること。UIもユースケースに合わせて絞り込み、1画面で必要な機能を提供する方がよい。
UIは一通り完成しているが、課題解決が十分ではない。解決策が甘く、課題定義が抽象的。ユースケースを具体的に想定し、要因を明確化して解決策を考える必要がある。
実際の利用シーンを考え、課題解決のために必要な機能を明確にする。出発から目的地までの一連の行動を考え、解決すべき要因を整理する。
解決策の提供形態をユースケースに合わせる。検索UIは統一し、1画面で必要な機能を提供する。画面移動はユーザーへの負担になるため避ける。
