O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

UXデザインの前にすること - UX CatchUp

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 32 Anúncio

UXデザインの前にすること - UX CatchUp

Baixar para ler offline

HCDを基板としたUXデザインの手法では、ユーザーのインサイトや、UXの可視化を考察できるなど新たな発見があります。しかし制作フェーズでのクライアントとの合意形成においては、手法だけでカタチにしていくのは難しいという現実もあります。UXデザインを実践していく前に、私たちが目指す方向をできるだけぶれずに進められる方法について考えてみます。

HCDを基板としたUXデザインの手法では、ユーザーのインサイトや、UXの可視化を考察できるなど新たな発見があります。しかし制作フェーズでのクライアントとの合意形成においては、手法だけでカタチにしていくのは難しいという現実もあります。UXデザインを実践していく前に、私たちが目指す方向をできるだけぶれずに進められる方法について考えてみます。

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a UXデザインの前にすること - UX CatchUp (20)

Mais recentes (20)

Anúncio

UXデザインの前にすること - UX CatchUp

  1. 1. 15/5/2015 UX CatchUp - Osaka / Kazuki Yamashita - Designed by IMPATH の前にすることUX Design
  2. 2. 山 下 一 樹 Web、アプリの設計・開発 プロトタイプ、UIの設計 UXデザインによる改善
  3. 3. UX Design
  4. 4. UX Design 関わる人が共創しながら 良いUXを設計すること
  5. 5. 理解する 改善する ユーザーを知る Human: User HCD
  6. 6. ユーザーを知る 理解する 改善する ユーザーシナリオ アクティングアウト カスタマージャーニーマップ ペルソナ ユーザーインタビュー エスノグラフィ 上位下位分析法 オブザベーション プロトタイピング ユーザーテスト ヒューリスティック評価 HCD
  7. 7. 手法によるプロセスからは 「新たな発見」はあるが、            が、    カタチにするまでが難しい。
  8. 8. クライアントから要件が出ない 制作プロセスを阻むシーン①
  9. 9. クライアントから要件が出ない 「まずペルソナを定義しましょう。  そしてユーザーのコンテクストを洗い出し… おそらく進みません
  10. 10. 要件のためのプロトタイピング いきなり ワイヤーフレーム
  11. 11. ユーザー・環境の理解 ユーザー調査 コンテキスト ペルソナ定義 ユーザーのゴールと機能 メンタルモデル エクスペリエンスマップ イメージ化 画面遷移 UIワイヤーフレーム プロトタイピング機能要件 UX Design のワークフロー ワイヤーフレームは本来、後の工程です
  12. 12. そもそもクライアントの要件とは 「アプリやアプリ! 「 「カレンダー風にしたら毎日やるんちゃうか 「パッと出してシュッとする動きで みたいな、なんか楽しそうなやつ それでもカタチにしてみることで気づきが生まれる
  13. 13. - モノクロ+1色
 ⇒ 色が入るとイメージや議論を発散させます - 制作時間をかけないパワポや Keynote で十分
 ⇒ 作っては再作成し議論・検証を繰り返すため - 遷移など動きを表現 - 実際のサイジングと実際に近いテキストを入れる
 ⇒ 具体的な利用中の体験を再現します ワイヤーフレームのポイント
  14. 14. プロトタイピングにより話が前に進みます ユーザー体験の疑似体験ができます 早期に失敗に気付きやすくなります 要件が出なければ いきなり ワイヤーフレーム
  15. 15. 要件が出てきたと思ったら発散する 制作プロセスを阻むシーン②
  16. 16. 「男女でも両方いけそうな色で 「フラットデザインでしょ、でも使いやすく 「カスタマイズできる機能は絶対に要るよ 「通知機能があれば便利やね 彼らはユーザーではありません
  17. 17. あれこれ言わせないために ガイドライン・ステートメントをつくる
  18. 18. Source: Google design guidelines デザインのための「スタイルガイド」
  19. 19. - デザインの原則(ex. 大胆で力強く) - カラー、タイポグラフィ、ワーディング - レイアウトパターン - アクセシビリティ - Do / Don’t スタイルガイドに含まれるもの デザインのための「スタイルガイド」
  20. 20. Source: Apple iOS Human Interface Guidelines サービス・アプリのための「ステートメント」
  21. 21. アプリ定義ステートメント 各項目の例はあくまでも文例であり実際のサービスとは異なります  1. アプリのステートメント このアプリの一文で表す説明、アジャイルやリーンスタートアップでも推奨しているピッ チ形式で( )を埋めると完成する。 ex) (Google)というサービスは、 (インターネット上のあらゆる情報をすぐに検索しマッチしたサイトを表示)したい (インターネット世界ユーザー)向けの、 (検索エンジンサービス)である。 ユーザーは(無料で利用かつ最速で結果表示)ができ、 (Yahoo!)とは違って、 (リッチスニペットやオーサーランクを基準に採用した、検索者に最も有益だと思われるコンテンツを表示する機能) が備わっていることが特長である。 2. ターゲット 年代別、性別ではなく、職業属性や地域など具体的なセグメンテーションが望ましい。 ex) 研究者、医学系のポストドクター 3. 利用シーン ユーザーはアプリをいつ、どのように使われるのか利用シーンを想定する。 ex) ユーザーの多くはスマートフォンを利用しており、通勤時やちょっとした待ち時間でアプリを起動し利用する。また ユーザーは、日中はオフィスで ノートPC を利用する仕事スタイルであり、Webブラウザでインターネットにアクセス できる環境にある。 (サービス名)というサービスは、 (潜在的なニーズを満たし、抱えている課題を解決)したい (ターゲット)向けの、 (アプリのカテゴリー)である。 ユーザーは(対価に見合う価値)ができ、 (競合サービス)とは違って、 (差別化要素)が備わっていることが特長である。 4. 利用シーンを踏まえた特徴的なもの 利用ユーザーと利用シーンに最適な機能や特徴はどういったものがあるか。ここではすべ ての機能を検討するのではなく、なぜその機能や特徴がアプリに必要なのかに絞る。 ex) スマートフォンと PC を行き来するユーザーのために、スマートフォンでチェックした内容を PC でも持続して閲覧 できる機能が必須である。スマートフォンでは少しの時間の合間でチェックする程度のため、検索画面はシンプルかつ 入力は最小限にとどめる必要がある。スマートフォン用とPC用の違いを明確化する。 5. ユーザー数の拡散ポイント アプリのユーザーが増える要素は何か。ここでは販売広告やチャネル拡大といったマーケ ティング要素ではなく、アプリで実現し得るポイントを検討する。 ex) ユーザーが利用するためにはユーザー登録が必要であるが、互いをフォローし合い、それを数値で可視させることで フォロー度合いを確かめることができる。フォロー結果が周囲にも通知されるため、フォローを誘発させる。また、ユー ザー属性が近いユーザーのフォローをリコメンドする機能もある。登録されることが第一のコンバージョンであること から、ユーザー登録のステップは最短である必要がある。 6. ビジネス(キャッシュ)ポイント アプリの課金ポイントはどこにあるか。そのポイントをゴールとし、ユーザーが迷わずに たどり着けるフロー検討する。 ex) 登録は無料であり、機能の大部分が利用できる。データを保存する容量には限りはないが、3か月経過するとデータ は消失するため、データを保持したいユーザーは月額料金を支払うことにより、1年単位で継続してデータを保持するこ とができる。月額料金を支払わないでデータを保持するには、データを手動でコピーしそれぞれファイルに保存するこ とはできるが、ユーザーにとってその手順が面倒であり、データ保持サービスの対価はユーザーに有益である。 7. このアプリでは将来においても実装しないこと アプリはリリース時、または将来的にユーザーの要望などにより機能を多く望まれること がある。ただしアプリのステートメントから離脱した機能の安易な実装は、設計思想から 外れていくことを意味する。ここでは望まれるであろう機能であっても、ステートメント を一貫するために実装しない機能を定義しておく。 ex) ユーザーが検索条件を定義し履歴などで保持しておくカスタマイズ機能は実装しない。これは検索操作を1∼2単語 で検索しても、最もマッチした検索結果が表示できるというステートメントにより、シンプルな設計で検索から結果参 照までの操作を統一するためである。また、過去に検索した条件を保持しておく必要性は低く、参照履歴があるため、 これと重複することになる。 サービス・アプリのための「ステートメント」
  22. 22. アプリ定義ステートメント 各項目の例はあくまでも文例であり実際のサービスとは異なります  1. アプリのステートメント このアプリの一文で表す説明、アジャイルやリーンスタートアップでも推奨しているピッ チ形式で( )を埋めると完成する。 ex) (Google)というサービスは、 (インターネット上のあらゆる情報をすぐに検索しマッチしたサイトを表示)したい (インターネット世界ユーザー)向けの、 (検索エンジンサービス)である。 ユーザーは(無料で利用かつ最速で結果表示)ができ、 (Yahoo!)とは違って、 (リッチスニペットやオーサーランクを基準に採用した、検索者に最も有益だと思われるコンテンツを表示する機能) が備わっていることが特長である。 (サービス名)というサービスは、 (潜在的なニーズを満たし、抱えている課題を解決)したい (ターゲット)向けの、 (アプリのカテゴリー)である。 ユーザーは(対価に見合う価値)ができ、 (競合サービス)とは違って、 (差別化要素)が備わっていることが特長である。
  23. 23. 2. ターゲット 年代別、性別ではなく、職業属性や地域など具体的なセグメンテーションが望ましい。 ex) 研究者、医学系のポストドクター 3. 利用シーン ユーザーはアプリをいつ、どのように使われるのか利用シーンを想定する。 ex) ユーザーの多くはスマートフォンを利用しており、通勤時やちょっとした待ち時間でアプリを起動し利用する。また ユーザーは、日中はオフィスで ノートPC を利用する仕事スタイルであり、Webブラウザでインターネットにアクセス できる環境にある。 (潜在的なニーズを満たし、抱えている課題を解決)したい (ターゲット)向けの、 (アプリのカテゴリー)である。 ユーザーは(対価に見合う価値)ができ、 (競合サービス)とは違って、 (差別化要素)が備わっていることが特長である。
  24. 24. 4. 利用シーンを踏まえた特徴的なもの 利用ユーザーと利用シーンに最適な機能や特徴はどういったものがあるか。ここではすべ ての機能を検討するのではなく、なぜその機能や特徴がアプリに必要なのかに絞る。 ex) スマートフォンと PC を行き来するユーザーのために、スマートフォンでチェックした内容を PC でも持続して閲覧 できる機能が必須である。スマートフォンでは少しの時間の合間でチェックする程度のため、検索画面はシンプルかつ 入力は最小限にとどめる必要がある。スマートフォン用とPC用の違いを明確化する。 5. ユーザー数の拡散ポイント アプリのユーザーが増える要素は何か。ここでは販売広告やチャネル拡大といったマーケ ティング要素ではなく、アプリで実現し得るポイントを検討する。 ex) ユーザーが利用するためにはユーザー登録が必要であるが、互いをフォローし合い、それを数値で可視させることで フォロー度合いを確かめることができる。フォロー結果が周囲にも通知されるため、フォローを誘発させる。また、ユー ザー属性が近いユーザーのフォローをリコメンドする機能もある。登録されることが第一のコンバージョンであること から、ユーザー登録のステップは最短である必要がある。 6. ビジネス(キャッシュ)ポイント アプリの課金ポイントはどこにあるか。そのポイントをゴールとし、ユーザーが迷わずに たどり着けるフロー検討する。 ex) 登録は無料であり、機能の大部分が利用できる。データを保存する容量には限りはないが、3か月経過するとデータ は消失するため、データを保持したいユーザーは月額料金を支払うことにより、1年単位で継続してデータを保持するこ とができる。月額料金を支払わないでデータを保持するには、データを手動でコピーしそれぞれファイルに保存するこ とはできるが、ユーザーにとってその手順が面倒であり、データ保持サービスの対価はユーザーに有益である。
  25. 25. アプリの課金ポイントはどこにあるか。そのポイントをゴールとし、ユーザーが迷わずに たどり着けるフロー検討する。 ex) 登録は無料であり、機能の大部分が利用できる。データを保存する容量には限りはないが、3か月経過するとデータ は消失するため、データを保持したいユーザーは月額料金を支払うことにより、1年単位で継続してデータを保持するこ とができる。月額料金を支払わないでデータを保持するには、データを手動でコピーしそれぞれファイルに保存するこ とはできるが、ユーザーにとってその手順が面倒であり、データ保持サービスの対価はユーザーに有益である。 7. このアプリでは将来においても実装しないこと アプリはリリース時、または将来的にユーザーの要望などにより機能を多く望まれること がある。ただしアプリのステートメントから離脱した機能の安易な実装は、設計思想から 外れていくことを意味する。ここでは望まれるであろう機能であっても、ステートメント を一貫するために実装しない機能を定義しておく。 ex) ユーザーが検索条件を定義し履歴などで保持しておくカスタマイズ機能は実装しない。これは検索操作を1∼2単語 で検索しても、最もマッチした検索結果が表示できるというステートメントにより、シンプルな設計で検索から結果参 照までの操作を統一するためである。また、過去に検索した条件を保持しておく必要性は低く、参照履歴があるため、 これと重複することになる。
  26. 26. 発散しないために ガイドラインに力関係は働きません 宣言によりビジョンを共有できます 全員がデザインに関わることができます ガイドライン・ステートメントをつくる
  27. 27. ガイドライン・ステートメント ワイヤーフレーム の前にすることUX Design
  28. 28. UX Design 関わる人が共創しながら 良いUXを設計すること
  29. 29. UX Design 共創しながら
  30. 30. 手法のやり方にこだわらない 作業や合意のサイクルをどんどん回す 迷ったときはユーザーはどうだろう?と問う オーナーを含め、みんなで UX Design
  31. 31. 主役はあくまでもユーザー
  32. 32. Thank you

×