□ 基本となるデザインの流れ/やり方の全体像
BONOのコンテンツも増えて探しづらい状態が続いているので、試験的にちょこちょこ要望のあったデザインの流れを全てまとめてみました。
関連するコンテンツややり方のリンクも合わせて貼っています。が、フローを説明するように作られたコンテンツではないのでわかりづらい点はあるかなと思います。
狙い
このフローを理解することの目的は以下のようなものです
- デザインの全体像がわかることで、自分の担当業務のやり方や欠損に気づき、身につけるスキルのヒントになる
- 担当しているデザインフローのやり方に関する知識や全体像、意味がわかる
- 自分のやっているデザインに対して何を伸ばす必要がありそうか？のあたりをつけることができる。
キャリアについて考えたい場合はスキルマップについて合わせて読むとよいと思います。
『ジュニアデザイナーのためのスキルマップ - まず現場に貢献するデザインをするために何が必要か』
□ 需要の多いフローは優先してコンテンツ開発
需要の多いコンテンツに関しては優先度を高めてBONOでコンテンツを展開していこうと考えています。ぜひみなさんの声を聞かせてください。よりデザインを楽しめる場所を作っていきましょう。
質問はこちらに
□ フローを見る時の注意事項
フローは、UI/UXデザイナーと指されそうな人たちの業務範囲のほぼ最大です。ビジネス観点は一旦抜いてますが、全て1人でできる必要はありません。
上から順にフローが流れを書いていますが、上から順に流れるだけってことはありません。常に行ったり来たりして検証しながら進めていくことで、顧客に価値を届ける練度は高まります。
自分のやるべき方向性を知りたい方はスキルマップを参考にしてください。自分のキャリアは自分でデザインしましょう。
『ジュニアデザイナーのためのスキルマップ - まず現場に貢献するデザインをするために何が必要か』
🚩 UIUXデザイナーのデザイン全体像
□ フローの全体
1.調査
デザインは顧客を主語にして行っていきます。調査フェーズのメインは対象になる顧客を定義するために顧客にヒアリングを行い顧客のリアルな声を情報として得ることです。また他にもプロジェクトを進める上で考慮すべき内容を把握するために調査を行い情報を集めます。
2.モデル
集めた顧客情報などをもとに「顧客像の定義」と「提供価値＝顧客の変化」を定義して、プロジェクトの方向性を固めます。常に顧客を主語にして、リアルな声に基づいた定義を行います。
3.解決策の定義
定めた価値と顧客から洗い出した課題を元に解決アイデアを考えていきます。ここでも自分のアイデアではなく、顧客を主語にし顧客のリアルな声と紐づくアイデアを出し、顧客の観点で優先度を付け取り組むものを決めていきます。また決めた施策の内容も実行可能にするために定義していきます。
4.UI情報設計
定めた施策の要件定義をもとにUIで解決するために必要な情報を定義します。表示すべき情報やその関係性、ユーザーの行動に即したページフローなど、解決するためのUIに必要な情報を整理し、UIアイデアのパターンで出してベストなUIを検討していきます。
5.スタイリング
機能面が固まったUIの主に見た目部分を固めていきます。新規の場合はゼロベースでコンセプトからスタイルに落としていき、既存サービスの場合はデザインシステムを意識して整理していきます。
6.開発/リリース
開発にボールが移った後はスムーズに開発ができるようにエンジニアサイドからの要望に応えます。また機能がリリースされたら、定義した要件に適う結果が得られたか？得られてないのであればそれは何が原因か？などをチェックし、顧客に顧客に届くデザインに活かして行きます。
🚩 1.調査
まずは顧客を軸に作るため、ステークホルダーの条件を把握するため、など必要な情報を集めるところからスタートします。
□ 1.ユーザーインタビュー
▽ フェーズの目的
- 数字や統計では見えない”リアルな感情”を軸にデザインしなければ、物が溢れた世の中で価値が作りづらくなった。そのため顧客を軸に組み立てていくことがサービスデザインの軸になっている
- 数字では得られない、具体的な顧客のリアルの現状を把握し、ニーズや課題を深掘りする情報を得る
- 改善やデザインの方向性を決めるために、推定顧客のリアルを把握し、リアルな情報を広く得る
- 仮説で定義した価値がユーザーにフィットするのか？またフィットするとしたらどういう顧客か？を把握するために情報を広く得る
▽ このフェーズでやることのリスト
1 インタビュー仮説の定義
- 作ろうとしているサービスや機能、改善の”顧客目線の課題やニーズ”の仮説をまずは持つところから始める
- 仮説を作ることでデザインしようとしている物事に対する洞察を持て、”何を聞くべきか”や”顧客との対話の解像度”が充実した内容で実行できる確率が上がる
- 後のフローの価値定義や顧客定義、施策アイデア出しを使って事前に仮説を出しておくことで、”本当にこれは成り立つのか？”や”軸となる顧客の課題やニーズ”、”何を調べると達成確率が上がるのか？”などを考える
- ChatGPTを使って仮説の思考範囲を広く洗い出すことを行う（抽象度が高くなりがちなので過信せず深掘りは人のリアルな思考で行う）
2 台本作成
3 インタビュー相手の選定と決定
- 仮説をもとにインタビューするに相応しい相手を探し、インタビュー依頼を投げる
- 知り合いから探したり、会社の中で該当する人を探したりする
- １セグメントのユーザーにつき5人ほど聞ければ問題の7割ほどは聞けると言われている
4 インタビューの実施/録画
5 インタビュー結果のまとめ
▽ このフェーズで使えるコンテンツ
□ 2.関連/競合製品リサーチ
▽ フェーズの目的
- 他の製品/サービスでは、自分が取り組んでいることをどのように実行しているか？を調べて、使える仮説やイメージを先回りで持つ
- 顧客目線で周囲のサービスを調べ、利用、比較することで自分のデザインする対象へのヒントを得ることができる
▽ このフェーズでやることのリスト
- 競合の調査: ビジネス、マーケティング、機能性
- 競合のUI調査: 似た機能をUIでどうやっているか？など、デザイン面での調査を行う
□ 3.関係者インタビュー
▽ フェーズの目的
- 取り組んでいる分野の専門家から意見を聞き、事前に考えられるリスクや一般的な対応策などについて情報を得て失敗する確率を避ける
- 機能やサービスのオーナーにヒアリングし、外せないポイントやビジョン、目的などを把握することで、方向性のブレをなくす
▽ このフェーズでやることのリスト
- 専門家インタビュー
- 2.ステークホルダーインタビュー
🚩 2.モデル定義
□ 1. ペルソナ定義
▽ フェーズの目的
- 顧客像を価値観から定義していく。×：デモグラ（年齢/住んでる地域/性別)でやるのはNG。理由はサービスのアイデアにつながらないため。(4-2.ユーザー像のまとめ方【ゴールが大事】)
- 顧客のゴール（なりたい状態 / 価値観）をベースに、今とっている行動、ゴール達成を阻害する要因など、リアルな声を使ってまとめていく。
- デモグラは抽象度が高く意味をなさない。デザインリサーチに関してはほぼ使わない。顧客の価値観や感情、すでに取っているリアルな行動から顧客像をまとめる
- リアルな行動から動機や課題を見出すことで、他社が見出せていない、少し未来のニーズ/課題に対応することができる
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 2. 価値・課題定義
▽ フェーズの目的
- デザインする、機能やサービス、改善などの方向性を定義する
- 顧客を軸に「〜〜という人たちは、XXXXXをやりたいが、AAAAが障壁で上手くできない、なので『解決策に価値がある』」というまとめフォーマットで価値と課題を定義します。(UXデザインのよくある間違い - 要件定義の具体イメージ解説)
- 顧客の声を使って全て組み立てます。顧客のことを意識できるように「ユーザーの生活が想像できるような形」でユーザーストーリーとして定義するとさらにわかりやすいでしょう。
- まとめに頼りすぎず、『なぜその方向性なのか？』を実際のユーザーヒアリングから分かったことをベースに詳しく定義する
- 価値：顧客の現状とリアルな声を元に、何が価値になるのか？をアイデアを出し定義していく。場合によっては価値を定義した段階では仮説でしかないので、もう1度ヒアリングを行うことでさらに深く顧客理解をすることも一般的です。
- 価値とは「相手の変化量」です。その機能やサービスがユーザーに届くことで、”ユーザーはどれぐらい今よりポジティブに変わるのか？”の量が価値になります。
- 課題は”現状とゴールのギャップ”です。変化したい状態のゴールと、それに到達できない現在のギャップが課題になります。その課題が生まれてしまう”原因/要因”が解決すべき本当の課題になります。
- 場合によってはビジネス要件も踏まえて定義する必要があります。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 3. 価値検証/MVP
▽ フェーズの目的
- 定義した価値や課題が本当なのか？をより具体的な形で検証することを行います。
- 具体的に価値を体感できる、イメージできるプロトタイプを作成して、顧客にヒアリングをすることで本番リリース前の失敗を防ぎます(早く失敗するためのプロトタイピング作成のコツ)
- リリースして結果を見ることが最も客観的な結果を得られるので、小さい単位の開発の場合は無理に価値検証を挟む必要がないことも多いです。
- 大きな単位の開発の場合は手戻りを考えて前もって失敗して大きなミスを減らすことができるとともに、顧客理解をさらに深めることができます。
- 価値検証
- MVP
- 価値検証プロトタイピング
- 価値検証ヒアリング
🚩 3.解決案の定義
価値の方向性が定まったら”実行していく”アイデアを出して、最も顧客と価値にリンクするアイデアを施策として実行する準備を始めていきます。
□ 1. 解決方向性の策定
▽ フェーズの目的
- 定義した価値と顧客を軸に、価値を体感でき洗い出された課題を解決する策の具体的な実行策を考えていきましょう。
- まずは狭く考えず、定義した顧客と価値とに合致する範囲で広くアイデアを出していきます。
- 自分の頭の中だけでアイデアを出さずに、参考になりそうなものをリサーチし直したり、詳しい人にインタビューすることで視野を広げながらアイデアを出すことができます。
- チームでブレストをしてアイデアを出し、定義した価値と顧客と照らし合わせて優先度を決めることで、共通認識を深めることもできます。
- アイデアが出揃ったら、優先度と内容を考えて、取るべき施策を絞り決定します。
- 主にプロダクトマネージャーなど機能やサービスに責任を持つ人が意思決定しますが、デザイナーも良いプロダクトを作るためにこの領域に果敢に関わっていくことが重要です。
▽ このフェーズでやることのリスト
- 参考リサーチ: 機能面やユーザー価値の観点で調べる
- 課題の整理：ユーザー行動フロー / フィッシュボーン図（UIを体験にするアイデア整理 - ユーザーの理想の行動を具体化します）
- 課題に対する解決アイデア出し(****方向性の決めてはユーザーの声で。課題解決のアイデアをどう出すか？）**
4.アイデアを絞る
5.方向性の定義を行う
□ 2. 実施ロードマップ
▽ フェーズの目的
- プロジェクトを進めていく見通しを持つために「計画」「すすめ方」「期間」「締め切り」などを決めて、チームでの進め方を定義しましょう。
- この段階では仮でまずは決め、後述するラフやプロトタイピングでやるべきことが明確になるにつれて修正したり書き足していくのも常に行います
- 計画はドキュメントにまとめたりなどしてチームが進め方を認識して意識できるようにしていきましょう
- 主にプロジェクト進行をするメンバーがリードして行います
□ 3. 施策定義
▽ フェーズの目的
- 最初に行う解決のための施策内容を定義します。主にUIを作成するならどんなことを意識しないといけないのか？外せない機能やユーザーの状態は？などなど、具体施策を形にする上で考えなくてはならないことをまとめることで、「何のための施策で何をする必要があるか」を誰でも把握できるようにします
- 顧客を主語にして書きつつ、リリースによって得たいビジネス的な成果も添えるのが良いと思います。
- 合わせて期限やリリース日、進行計画のイメージも共有できるとチーム一体となって施策を実行できそうです。
- 主にPdMなど機能やサービスに意思決定を行うメンバーが中心で作成します。デザイナーが入っても問題ないです（むしろ良いと思います）
▽ このフェーズでやることのリスト
- 解決施策の要件定義書を作成する
- 施策を行うことでユーザーをどういう状態にしたいのかを定義しておく
- 進め方や期限など期限など進行に関するものを決めておく
□ 4. UI要件定義
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
→ 1. UIの要件定義の作成
▽ フェーズの目的
- 施策の要件を踏まえて、UIに必要な情報を整理しながら”どのようなUIになりそうか”をイメージしていきます。
- いきなり作りはじめる前に”何を達成するべきか”、そのためには”何が必要条件になるか”、”どんな情報が必要か”などなど、UIを作る上で必要な情報と、情報の関係性（優先度やグループ、画面の流れ）などを整理します。
- まずはラフ程度に素早く作成し、後述するUIラフを作成、具体物と一緒に方向性を吟味していくことがポイントです。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
→ 2. UIのラフ作成
▽ フェーズの目的
- 文字情報だけでは実際のユーザーに近い体験とは程遠いので荒い形でUIを作成して施策の具体的な形を体感できるUIを作成します。
- 早めに成果物に近いものを触っておくことで”何がこの施策の成功に必要か？”、”考えていることはあっているか？具体的か？”を早い段階で認識することが可能になります。
- 早めに触ること、UIで実現すべきことに対する解像度を高く持つことができ、UIで考慮すべき内容に早い段階で正確に知ることができ、後戻りが少ない質の高いUIを作ることが可能です。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
→ 3. チーム共有
▽ フェーズの目的
- 施策に対するUIのラフができた段階で、チームに共有しましょう。
- どういうUIになりそうか？定義した要件定義の方向性とズレはないか、PdMとすり合わせましょう
- また開発メンバーにも早めに共有することで今の段階で考えるべき開発要件の視野も拾っておきましょう。念を押して”これは決定したUIではない”ことを伝えながら会話をしましょう。
- 文字だけでは見えなかった考慮するべきことを把握することがここまでの目的です。場合によっては方向性の間違いに気づき、フローを戻ることも十分にあり得ます。フロー通りにやるのではなく、よく考えるための型として使用していきましょう。
▽ このフェーズでやることのリスト
- 1.ラフUIでの要件定義を具体化した解決案の共有
- 2.ビジネスサイド、エンジニアサイド、要件サイド、から意見を多く抽出して考慮すべき視野を広げる
▽ このフェーズで使えるコンテンツ
🚩 4.インタラクションデザイン（情報設計）
UIの方向性が大体定まったら具体的なUIデザインに入りましょう。まずは機能性を決定する情報設計を具体的なUIで実現するアイデアを模索していきます。
□ 1. 情報設計/アイデア作成
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
▽ フェーズの目的
- まずはUIの機能面、画面の流れなどの部分のみを固めていきます。スタイルはその後に決めていく方が良いでしょう。（すでにコンポーネントが揃っている場合はスタイルを決める必要はほぼないでしょう）
- 方向性が定まったら具体的に課題を解決できるUIの形を模索します。１パターンだけではなく、さまざまな解決策の方向性をUIアイデアを出して検討していきます。
- なぜ機能面から決めるかというと、開発の着手が早くなるためです。スタイリングと機能面はエンジニアリング的に別にできる部分が広いので先に機能面を固めていくことでスピードを速くできます（見た目も顧客体験に大きく関わるサービスなどはこのフローに従う必要はないです。目安です）
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
▽ このフェーズで使える基礎スキル
基本UIパターンの理解
情報設計の基本
UIアイデア
- UI情報設計の参考探し
- フィッシュボーン図でしらみつぶしにパターン出し
- 解決UIのパターン出し
- UIの基本パターン
□ 2. 検証/プロトタイピング
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
▽ フェーズの目的
- UIアイデアを出したUIを客観視点で評価します。自分の主観だけではなく、客観的にはどう見えるのか？意図した操作を認識できるのか？など、目的/顧客のゴールを達成できるUIにするためにフィードバックを得ます。
- この段階での主な評価/フィードバックされるべき内容は”意図した操作を認識して実行できるか”になります。価値や意味に関しては前のフェーズで担保されているべきです。ただこの段階で気付いた場合は前のフェーズに戻ることも検討しましょう。
- 実際のユーザーに聞ければベストですが、操作性のみしか関係しなそうであれば、施策について全く知らない社内メンバーなどでも、操作性に関するフィードバックを十分に得ることはできます。
- 検証で分かったことを元に、もう1度情報設計を見直して、UI作成を行います。この際、もうすでに課題が明確な場合は再度検証は通さず、機能面のFIXに向かいます。
▽ このフェーズでやることのリスト
- 実際のユーザーにユーザビリティテストを行う
- 社内メンバーや身近な人で、施策について何も知らない人に、ユーザビリティテストを行う
▽ このフェーズで使える基礎スキル
- UIプロトタイピング
- 主要ゴール達成までの道のりをプロトタイピング
- 全体像を荒くプロトタイピング
- ユーザビリティテスト
- 社内テスト / ドッグフーディング
- ユーザビリティテスト
□ 3. UI情報設計をチーム共有
▽ フェーズの目的
- まずは機能面の部分だけチームに共有します。UIでいうと土台と骨の部分です。スタイルが当たってないだけで、本番に近いUIをデザインして共有しましょう。
- どうしてもアイデアを絞れない場合は複数アイデアを共有することも視野に入れましょう。ただその際は自分的にはこっちのアイデアが良い理由を決めて臨みましょう。UIに責任を持つのはUIデザイナーです。
- UIは必ず「プロトタイプ機能」を使って、実際の使用感に近い形で共有をしましょう。デザインファイルなどで顧客はそのUIと接しないため、UIの判断をチームで間違う確率がとても高くなります。必ず「プロトタイプ機能」でUIをプレゼンテーションしてください。
- 機能面について大枠固まったら開発メンバーには開発に着手してもらいましょう。
▽ このフェーズでやることのリスト
▽ 関連コンテンツ
【BONOラジ #12】ベストなUIを進めたいけど工数が理由で削減されちゃうよぴえん！
🚩5. スタイリング
定まったUIの機能に対して、見た目を施すフェーズです。ガイドラインがある場合はUIシステムの整理に使ったり、グラフィック要素を作る必要(アイコンやアイキャッチ、アニメーション)のあるUIの場合はその作成に充てます。
□ 1. UIスタイリング
▽ フェーズの目的
- 定まったUIの機能面の見た目部分をブラッシュアップさせていくフェーズです。
- 新規開発のサービスの場合はスタイリング要素である色や余白感、フォントサイズなどなど全て考えて決めていきます。
- 既存サービスの場合はデザインシステムや現在のスタイルを踏襲して進めていきます。
- UIのコンポーネント化のために整理をしたりすることもやりましょう。
▽ このフェーズでやることのリスト
- 新規開発の場合は見た目に関するテイストなどの詰めをこのフェーズで行います。コンセプトや大枠の方向性などを、前のフェーズから並行して行っておき、細かい詰めをこのフェーズでやるようなイメージが一般的には多いでしょう
- 既存サービスの場合は、UIのテイストを揃えていきましょう。既存のコンポーネントやスタイルでおかしいところがあれば、合わせて調整できない検討するアイデアをデザインします。
- コンポーネントの整理も合わせて行えると良いでしょう。
- スタイリングまで決まったら再度、PdMやエンジニアなどチームメンバーに”これでUIはFIX”であることを共有しましょう。
▽ このフェーズで使えるコンテンツ
▼ 関連コンテンツ
□ 2. エンジニアリング共有
▽ フェーズの目的
- スタイルも完成したのでUIがほぼ完成した状態で再度エンジニアメンバーにUIについて共有します。
- コンポーネントの相談や指定なども合わせてできるようなプロダクト体制になっているとなお良いでしょう。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
🚩6. 開発共有/リリース
顧客や要件にあった正しいUIを探り定義するフェーズ
□ 1. 開発支援
▽ フェーズの目的
- ドキュメントを共有してそれを見れば全て疑問点なく開発できることはほぼないでしょう。エンジニアさんが実装の中で出てくる困り事や疑問、決めなくてはならなかったことなどを、引き続き対応していきます。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 2. リリース
▽ フェーズの目的
- サービスがリリースされたら要件定義で定義した結果が得られるのかデザイン側もチェックしましょう。自分のデザインが世の中に受け入れられたのか？意図した結果にどれぐらい近づけられたのかを自らチェックします
- 結果が届かなかった場合は「同じ方向性で違う施策を試す」のか「違う方向性で試す」のか、「この施策についてはストップする」のかをPdMなどチームメンバーと一緒に話して決めていきましょう。
- 結果を見ることで顧客を意識してデザインを継続していくことが可能です。
▽ このフェーズでやることのリスト
- 意図した結果にデザインが貢献できているのか、数値でチェックする
- 場合によってはリリース後にヒアリングをしてリアルな声でチェックする
- 結果からPDCAを回すために改善点、次のアクションを定義する
以上になります！ご要望はフォームまで
要望の多いコンテンツに関しては優先度を高めてBONOでコンテンツを展開していこうと考えています。ぜひみなさんの声を聞かせてください。よりデザインを楽しめる場所を作っていきましょう。
質問はこちらに
□ 基本となるデザインの流れ/やり方の全体像
BONOのコンテンツも増えて探しづらい状態が続いているので、試験的にちょこちょこ要望のあったデザインの流れを全てまとめてみました。
関連するコンテンツややり方のリンクも合わせて貼っています。が、フローを説明するように作られたコンテンツではないのでわかりづらい点はあるかなと思います。
狙い
このフローを理解することの目的は以下のようなものです
- デザインの全体像がわかることで、自分の担当業務のやり方や欠損に気づき、身につけるスキルのヒントになる
- 担当しているデザインフローのやり方に関する知識や全体像、意味がわかる
- 自分のやっているデザインに対して何を伸ばす必要がありそうか？のあたりをつけることができる。
キャリアについて考えたい場合はスキルマップについて合わせて読むとよいと思います。
『ジュニアデザイナーのためのスキルマップ - まず現場に貢献するデザインをするために何が必要か』
□ 需要の多いフローは優先してコンテンツ開発
需要の多いコンテンツに関しては優先度を高めてBONOでコンテンツを展開していこうと考えています。ぜひみなさんの声を聞かせてください。よりデザインを楽しめる場所を作っていきましょう。
質問はこちらに
□ フローを見る時の注意事項
フローは、UI/UXデザイナーと指されそうな人たちの業務範囲のほぼ最大です。ビジネス観点は一旦抜いてますが、全て1人でできる必要はありません。
上から順にフローが流れを書いていますが、上から順に流れるだけってことはありません。常に行ったり来たりして検証しながら進めていくことで、顧客に価値を届ける練度は高まります。
自分のやるべき方向性を知りたい方はスキルマップを参考にしてください。自分のキャリアは自分でデザインしましょう。
『ジュニアデザイナーのためのスキルマップ - まず現場に貢献するデザインをするために何が必要か』
🚩 UIUXデザイナーのデザイン全体像
□ フローの全体
1.調査
デザインは顧客を主語にして行っていきます。調査フェーズのメインは対象になる顧客を定義するために顧客にヒアリングを行い顧客のリアルな声を情報として得ることです。また他にもプロジェクトを進める上で考慮すべき内容を把握するために調査を行い情報を集めます。
2.モデル
集めた顧客情報などをもとに「顧客像の定義」と「提供価値＝顧客の変化」を定義して、プロジェクトの方向性を固めます。常に顧客を主語にして、リアルな声に基づいた定義を行います。
3.解決策の定義
定めた価値と顧客から洗い出した課題を元に解決アイデアを考えていきます。ここでも自分のアイデアではなく、顧客を主語にし顧客のリアルな声と紐づくアイデアを出し、顧客の観点で優先度を付け取り組むものを決めていきます。また決めた施策の内容も実行可能にするために定義していきます。
4.UI情報設計
定めた施策の要件定義をもとにUIで解決するために必要な情報を定義します。表示すべき情報やその関係性、ユーザーの行動に即したページフローなど、解決するためのUIに必要な情報を整理し、UIアイデアのパターンで出してベストなUIを検討していきます。
5.スタイリング
機能面が固まったUIの主に見た目部分を固めていきます。新規の場合はゼロベースでコンセプトからスタイルに落としていき、既存サービスの場合はデザインシステムを意識して整理していきます。
6.開発/リリース
開発にボールが移った後はスムーズに開発ができるようにエンジニアサイドからの要望に応えます。また機能がリリースされたら、定義した要件に適う結果が得られたか？得られてないのであればそれは何が原因か？などをチェックし、顧客に顧客に届くデザインに活かして行きます。
🚩 1.調査
まずは顧客を軸に作るため、ステークホルダーの条件を把握するため、など必要な情報を集めるところからスタートします。
□ 1.ユーザーインタビュー
▽ フェーズの目的
- 数字や統計では見えない”リアルな感情”を軸にデザインしなければ、物が溢れた世の中で価値が作りづらくなった。そのため顧客を軸に組み立てていくことがサービスデザインの軸になっている
- 数字では得られない、具体的な顧客のリアルの現状を把握し、ニーズや課題を深掘りする情報を得る
- 改善やデザインの方向性を決めるために、推定顧客のリアルを把握し、リアルな情報を広く得る
- 仮説で定義した価値がユーザーにフィットするのか？またフィットするとしたらどういう顧客か？を把握するために情報を広く得る
▽ このフェーズでやることのリスト
1 インタビュー仮説の定義
- 作ろうとしているサービスや機能、改善の”顧客目線の課題やニーズ”の仮説をまずは持つところから始める
- 仮説を作ることでデザインしようとしている物事に対する洞察を持て、”何を聞くべきか”や”顧客との対話の解像度”が充実した内容で実行できる確率が上がる
- 後のフローの価値定義や顧客定義、施策アイデア出しを使って事前に仮説を出しておくことで、”本当にこれは成り立つのか？”や”軸となる顧客の課題やニーズ”、”何を調べると達成確率が上がるのか？”などを考える
- ChatGPTを使って仮説の思考範囲を広く洗い出すことを行う（抽象度が高くなりがちなので過信せず深掘りは人のリアルな思考で行う）
2 台本作成
3 インタビュー相手の選定と決定
- 仮説をもとにインタビューするに相応しい相手を探し、インタビュー依頼を投げる
- 知り合いから探したり、会社の中で該当する人を探したりする
- １セグメントのユーザーにつき5人ほど聞ければ問題の7割ほどは聞けると言われている
4 インタビューの実施/録画
5 インタビュー結果のまとめ
▽ このフェーズで使えるコンテンツ
□ 2.関連/競合製品リサーチ
▽ フェーズの目的
- 他の製品/サービスでは、自分が取り組んでいることをどのように実行しているか？を調べて、使える仮説やイメージを先回りで持つ
- 顧客目線で周囲のサービスを調べ、利用、比較することで自分のデザインする対象へのヒントを得ることができる
▽ このフェーズでやることのリスト
- 競合の調査: ビジネス、マーケティング、機能性
- 競合のUI調査: 似た機能をUIでどうやっているか？など、デザイン面での調査を行う
□ 3.関係者インタビュー
▽ フェーズの目的
- 取り組んでいる分野の専門家から意見を聞き、事前に考えられるリスクや一般的な対応策などについて情報を得て失敗する確率を避ける
- 機能やサービスのオーナーにヒアリングし、外せないポイントやビジョン、目的などを把握することで、方向性のブレをなくす
▽ このフェーズでやることのリスト
- 専門家インタビュー
- 2.ステークホルダーインタビュー
🚩 2.モデル定義
□ 1. ペルソナ定義
▽ フェーズの目的
- 顧客像を価値観から定義していく。×：デモグラ（年齢/住んでる地域/性別)でやるのはNG。理由はサービスのアイデアにつながらないため。(4-2.ユーザー像のまとめ方【ゴールが大事】)
- 顧客のゴール（なりたい状態 / 価値観）をベースに、今とっている行動、ゴール達成を阻害する要因など、リアルな声を使ってまとめていく。
- デモグラは抽象度が高く意味をなさない。デザインリサーチに関してはほぼ使わない。顧客の価値観や感情、すでに取っているリアルな行動から顧客像をまとめる
- リアルな行動から動機や課題を見出すことで、他社が見出せていない、少し未来のニーズ/課題に対応することができる
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 2. 価値・課題定義
▽ フェーズの目的
- デザインする、機能やサービス、改善などの方向性を定義する
- 顧客を軸に「〜〜という人たちは、XXXXXをやりたいが、AAAAが障壁で上手くできない、なので『解決策に価値がある』」というまとめフォーマットで価値と課題を定義します。(UXデザインのよくある間違い - 要件定義の具体イメージ解説)
- 顧客の声を使って全て組み立てます。顧客のことを意識できるように「ユーザーの生活が想像できるような形」でユーザーストーリーとして定義するとさらにわかりやすいでしょう。
- まとめに頼りすぎず、『なぜその方向性なのか？』を実際のユーザーヒアリングから分かったことをベースに詳しく定義する
- 価値：顧客の現状とリアルな声を元に、何が価値になるのか？をアイデアを出し定義していく。場合によっては価値を定義した段階では仮説でしかないので、もう1度ヒアリングを行うことでさらに深く顧客理解をすることも一般的です。
- 価値とは「相手の変化量」です。その機能やサービスがユーザーに届くことで、”ユーザーはどれぐらい今よりポジティブに変わるのか？”の量が価値になります。
- 課題は”現状とゴールのギャップ”です。変化したい状態のゴールと、それに到達できない現在のギャップが課題になります。その課題が生まれてしまう”原因/要因”が解決すべき本当の課題になります。
- 場合によってはビジネス要件も踏まえて定義する必要があります。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 3. 価値検証/MVP
▽ フェーズの目的
- 定義した価値や課題が本当なのか？をより具体的な形で検証することを行います。
- 具体的に価値を体感できる、イメージできるプロトタイプを作成して、顧客にヒアリングをすることで本番リリース前の失敗を防ぎます(早く失敗するためのプロトタイピング作成のコツ)
- リリースして結果を見ることが最も客観的な結果を得られるので、小さい単位の開発の場合は無理に価値検証を挟む必要がないことも多いです。
- 大きな単位の開発の場合は手戻りを考えて前もって失敗して大きなミスを減らすことができるとともに、顧客理解をさらに深めることができます。
- 価値検証
- MVP
- 価値検証プロトタイピング
- 価値検証ヒアリング
🚩 3.解決案の定義
価値の方向性が定まったら”実行していく”アイデアを出して、最も顧客と価値にリンクするアイデアを施策として実行する準備を始めていきます。
□ 1. 解決方向性の策定
▽ フェーズの目的
- 定義した価値と顧客を軸に、価値を体感でき洗い出された課題を解決する策の具体的な実行策を考えていきましょう。
- まずは狭く考えず、定義した顧客と価値とに合致する範囲で広くアイデアを出していきます。
- 自分の頭の中だけでアイデアを出さずに、参考になりそうなものをリサーチし直したり、詳しい人にインタビューすることで視野を広げながらアイデアを出すことができます。
- チームでブレストをしてアイデアを出し、定義した価値と顧客と照らし合わせて優先度を決めることで、共通認識を深めることもできます。
- アイデアが出揃ったら、優先度と内容を考えて、取るべき施策を絞り決定します。
- 主にプロダクトマネージャーなど機能やサービスに責任を持つ人が意思決定しますが、デザイナーも良いプロダクトを作るためにこの領域に果敢に関わっていくことが重要です。
▽ このフェーズでやることのリスト
- 参考リサーチ: 機能面やユーザー価値の観点で調べる
- 課題の整理：ユーザー行動フロー / フィッシュボーン図（UIを体験にするアイデア整理 - ユーザーの理想の行動を具体化します）
- 課題に対する解決アイデア出し(****方向性の決めてはユーザーの声で。課題解決のアイデアをどう出すか？）**
4.アイデアを絞る
5.方向性の定義を行う
□ 2. 実施ロードマップ
▽ フェーズの目的
- プロジェクトを進めていく見通しを持つために「計画」「すすめ方」「期間」「締め切り」などを決めて、チームでの進め方を定義しましょう。
- この段階では仮でまずは決め、後述するラフやプロトタイピングでやるべきことが明確になるにつれて修正したり書き足していくのも常に行います
- 計画はドキュメントにまとめたりなどしてチームが進め方を認識して意識できるようにしていきましょう
- 主にプロジェクト進行をするメンバーがリードして行います
□ 3. 施策定義
▽ フェーズの目的
- 最初に行う解決のための施策内容を定義します。主にUIを作成するならどんなことを意識しないといけないのか？外せない機能やユーザーの状態は？などなど、具体施策を形にする上で考えなくてはならないことをまとめることで、「何のための施策で何をする必要があるか」を誰でも把握できるようにします
- 顧客を主語にして書きつつ、リリースによって得たいビジネス的な成果も添えるのが良いと思います。
- 合わせて期限やリリース日、進行計画のイメージも共有できるとチーム一体となって施策を実行できそうです。
- 主にPdMなど機能やサービスに意思決定を行うメンバーが中心で作成します。デザイナーが入っても問題ないです（むしろ良いと思います）
▽ このフェーズでやることのリスト
- 解決施策の要件定義書を作成する
- 施策を行うことでユーザーをどういう状態にしたいのかを定義しておく
- 進め方や期限など期限など進行に関するものを決めておく
□ 4. UI要件定義
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
→ 1. UIの要件定義の作成
▽ フェーズの目的
- 施策の要件を踏まえて、UIに必要な情報を整理しながら”どのようなUIになりそうか”をイメージしていきます。
- いきなり作りはじめる前に”何を達成するべきか”、そのためには”何が必要条件になるか”、”どんな情報が必要か”などなど、UIを作る上で必要な情報と、情報の関係性（優先度やグループ、画面の流れ）などを整理します。
- まずはラフ程度に素早く作成し、後述するUIラフを作成、具体物と一緒に方向性を吟味していくことがポイントです。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
→ 2. UIのラフ作成
▽ フェーズの目的
- 文字情報だけでは実際のユーザーに近い体験とは程遠いので荒い形でUIを作成して施策の具体的な形を体感できるUIを作成します。
- 早めに成果物に近いものを触っておくことで”何がこの施策の成功に必要か？”、”考えていることはあっているか？具体的か？”を早い段階で認識することが可能になります。
- 早めに触ること、UIで実現すべきことに対する解像度を高く持つことができ、UIで考慮すべき内容に早い段階で正確に知ることができ、後戻りが少ない質の高いUIを作ることが可能です。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
→ 3. チーム共有
▽ フェーズの目的
- 施策に対するUIのラフができた段階で、チームに共有しましょう。
- どういうUIになりそうか？定義した要件定義の方向性とズレはないか、PdMとすり合わせましょう
- また開発メンバーにも早めに共有することで今の段階で考えるべき開発要件の視野も拾っておきましょう。念を押して”これは決定したUIではない”ことを伝えながら会話をしましょう。
- 文字だけでは見えなかった考慮するべきことを把握することがここまでの目的です。場合によっては方向性の間違いに気づき、フローを戻ることも十分にあり得ます。フロー通りにやるのではなく、よく考えるための型として使用していきましょう。
▽ このフェーズでやることのリスト
- 1.ラフUIでの要件定義を具体化した解決案の共有
- 2.ビジネスサイド、エンジニアサイド、要件サイド、から意見を多く抽出して考慮すべき視野を広げる
▽ このフェーズで使えるコンテンツ
🚩 4.インタラクションデザイン（情報設計）
UIの方向性が大体定まったら具体的なUIデザインに入りましょう。まずは機能性を決定する情報設計を具体的なUIで実現するアイデアを模索していきます。
□ 1. 情報設計/アイデア作成
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
▽ フェーズの目的
- まずはUIの機能面、画面の流れなどの部分のみを固めていきます。スタイルはその後に決めていく方が良いでしょう。（すでにコンポーネントが揃っている場合はスタイルを決める必要はほぼないでしょう）
- 方向性が定まったら具体的に課題を解決できるUIの形を模索します。１パターンだけではなく、さまざまな解決策の方向性をUIアイデアを出して検討していきます。
- なぜ機能面から決めるかというと、開発の着手が早くなるためです。スタイリングと機能面はエンジニアリング的に別にできる部分が広いので先に機能面を固めていくことでスピードを速くできます（見た目も顧客体験に大きく関わるサービスなどはこのフローに従う必要はないです。目安です）
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
▽ このフェーズで使える基礎スキル
基本UIパターンの理解
情報設計の基本
UIアイデア
- UI情報設計の参考探し
- フィッシュボーン図でしらみつぶしにパターン出し
- 解決UIのパターン出し
- UIの基本パターン
□ 2. 検証/プロトタイピング
インタラクションデザイン。顧客や要件にあった正しいUIを探り定義するフェーズ
▽ フェーズの目的
- UIアイデアを出したUIを客観視点で評価します。自分の主観だけではなく、客観的にはどう見えるのか？意図した操作を認識できるのか？など、目的/顧客のゴールを達成できるUIにするためにフィードバックを得ます。
- この段階での主な評価/フィードバックされるべき内容は”意図した操作を認識して実行できるか”になります。価値や意味に関しては前のフェーズで担保されているべきです。ただこの段階で気付いた場合は前のフェーズに戻ることも検討しましょう。
- 実際のユーザーに聞ければベストですが、操作性のみしか関係しなそうであれば、施策について全く知らない社内メンバーなどでも、操作性に関するフィードバックを十分に得ることはできます。
- 検証で分かったことを元に、もう1度情報設計を見直して、UI作成を行います。この際、もうすでに課題が明確な場合は再度検証は通さず、機能面のFIXに向かいます。
▽ このフェーズでやることのリスト
- 実際のユーザーにユーザビリティテストを行う
- 社内メンバーや身近な人で、施策について何も知らない人に、ユーザビリティテストを行う
▽ このフェーズで使える基礎スキル
- UIプロトタイピング
- 主要ゴール達成までの道のりをプロトタイピング
- 全体像を荒くプロトタイピング
- ユーザビリティテスト
- 社内テスト / ドッグフーディング
- ユーザビリティテスト
□ 3. UI情報設計をチーム共有
▽ フェーズの目的
- まずは機能面の部分だけチームに共有します。UIでいうと土台と骨の部分です。スタイルが当たってないだけで、本番に近いUIをデザインして共有しましょう。
- どうしてもアイデアを絞れない場合は複数アイデアを共有することも視野に入れましょう。ただその際は自分的にはこっちのアイデアが良い理由を決めて臨みましょう。UIに責任を持つのはUIデザイナーです。
- UIは必ず「プロトタイプ機能」を使って、実際の使用感に近い形で共有をしましょう。デザインファイルなどで顧客はそのUIと接しないため、UIの判断をチームで間違う確率がとても高くなります。必ず「プロトタイプ機能」でUIをプレゼンテーションしてください。
- 機能面について大枠固まったら開発メンバーには開発に着手してもらいましょう。
▽ このフェーズでやることのリスト
▽ 関連コンテンツ
【BONOラジ #12】ベストなUIを進めたいけど工数が理由で削減されちゃうよぴえん！
🚩5. スタイリング
定まったUIの機能に対して、見た目を施すフェーズです。ガイドラインがある場合はUIシステムの整理に使ったり、グラフィック要素を作る必要(アイコンやアイキャッチ、アニメーション)のあるUIの場合はその作成に充てます。
□ 1. UIスタイリング
▽ フェーズの目的
- 定まったUIの機能面の見た目部分をブラッシュアップさせていくフェーズです。
- 新規開発のサービスの場合はスタイリング要素である色や余白感、フォントサイズなどなど全て考えて決めていきます。
- 既存サービスの場合はデザインシステムや現在のスタイルを踏襲して進めていきます。
- UIのコンポーネント化のために整理をしたりすることもやりましょう。
▽ このフェーズでやることのリスト
- 新規開発の場合は見た目に関するテイストなどの詰めをこのフェーズで行います。コンセプトや大枠の方向性などを、前のフェーズから並行して行っておき、細かい詰めをこのフェーズでやるようなイメージが一般的には多いでしょう
- 既存サービスの場合は、UIのテイストを揃えていきましょう。既存のコンポーネントやスタイルでおかしいところがあれば、合わせて調整できない検討するアイデアをデザインします。
- コンポーネントの整理も合わせて行えると良いでしょう。
- スタイリングまで決まったら再度、PdMやエンジニアなどチームメンバーに”これでUIはFIX”であることを共有しましょう。
▽ このフェーズで使えるコンテンツ
▼ 関連コンテンツ
□ 2. エンジニアリング共有
▽ フェーズの目的
- スタイルも完成したのでUIがほぼ完成した状態で再度エンジニアメンバーにUIについて共有します。
- コンポーネントの相談や指定なども合わせてできるようなプロダクト体制になっているとなお良いでしょう。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
🚩6. 開発共有/リリース
顧客や要件にあった正しいUIを探り定義するフェーズ
□ 1. 開発支援
▽ フェーズの目的
- ドキュメントを共有してそれを見れば全て疑問点なく開発できることはほぼないでしょう。エンジニアさんが実装の中で出てくる困り事や疑問、決めなくてはならなかったことなどを、引き続き対応していきます。
▽ このフェーズでやることのリスト
▽ このフェーズで使えるコンテンツ
□ 2. リリース
▽ フェーズの目的
- サービスがリリースされたら要件定義で定義した結果が得られるのかデザイン側もチェックしましょう。自分のデザインが世の中に受け入れられたのか？意図した結果にどれぐらい近づけられたのかを自らチェックします
- 結果が届かなかった場合は「同じ方向性で違う施策を試す」のか「違う方向性で試す」のか、「この施策についてはストップする」のかをPdMなどチームメンバーと一緒に話して決めていきましょう。
- 結果を見ることで顧客を意識してデザインを継続していくことが可能です。
▽ このフェーズでやることのリスト
- 意図した結果にデザインが貢献できているのか、数値でチェックする
- 場合によってはリリース後にヒアリングをしてリアルな声でチェックする
- 結果からPDCAを回すために改善点、次のアクションを定義する
以上になります！ご要望はフォームまで
要望の多いコンテンツに関しては優先度を高めてBONOでコンテンツを展開していこうと考えています。ぜひみなさんの声を聞かせてください。よりデザインを楽しめる場所を作っていきましょう。
質問はこちらに
.webp)
.png)
0 Comments