目指すUX
ユーザー満足度が高い
いいUXが持つべき特徴
userful
usable
findable
valuable
desirable
accesible
credible
(上から満足度の向上(Experience)→機能の提供 Task)
meaningful (「価値がある」ここまでなると、口コミが広がる)
pleasurable
convenient
usable
reliable
functional
ウォータフォール(1つのプロセス) vs アジャイル(イテレーションごとの改善)
規模は異なるが、プロセスは一致する
UXデザイン UIデザイン ユーザビリティテスト
(要件定義→設計→実装→機能テスト)
リリース後もユーザビリティテストは行われる
UXデザインのタスク
だいたいこのように分かれる
ユーザー調査
コンテキスト調査
ペルソナ定義
ストーリーボード作成
メンタルモデル作成
機能一覧作成
データモデリング
UIスケッチ
画面フロー作成
UIプロトタイプ作成
ユーザー調査(ユーザーは誰か？→マーケット調査 サーベイ インタビューなどで実施→成果物:ペルソナや補足資料)
ITプロセスの要件定義タスクの一環として行うのが現実的
担当の話だけを聞いてはだめ。必ず直接使用者に会うこと。
「ユーザーに弟子入り」
コンテキスト調査(ユーザーはどのような環境状況にあるか？→マーケット調査 サーベイ インタビューなどで実施→成果物:ストーリーボード、メンタルモデル)
ITプロセスのプロジェクト立ち上げ及びスコープ確定と連携
プロジェクト全てのステークホルダーと会ってプロジェクトに対する意図を確認。ビジネスゴールを確認。
ペルソナ定義(代表的なユーザー像を出来るだけ具体的に定義する→ユーザーの特徴、環境、欲求などを具体的に記述する リアル感を出す)
ユーザーの思考 行動を想像するためのツール。ただし凝りすぎる必要はない。絵はwebから拾った有名人の画像より、手書きのほうがよい。絵を描きながら背後の環境などを知ることも出来るからオススメ。営業部の写真とか、背景とかの写真でもよい。複数のペルソナを定義する必要もある(主役ペルソナ、脇役ペルソナ)。ペルソナの視点に立って考える。
ストーリーボード作成(ユーザーの行動を具体的に定義し、理解する)
ストーリーボードはシンプルに書くべきか細かく書くべきかは賛否両論ある。
ユースケース作成タスクと並行、あるいはユースケース作成の代わりに実施する。ユーザーを囲む環境を描写する。(時間、騒音、明るさ、室内など)システムではなく、ユーザーの視点で作成する。用語の定義もちゃんとやる必要がある。既存のストーリーボードと理想的なストーリーボードを描いて比較する
メンタルモデル作成(ユーザーは何を考えているか？ユーザーの認識 なぜ良いデザインを求めるのか、なぜそのUXなのかを説明する部分)
ユーザーの行動に対して「なぜ？」を確認する。しかし、多くの場合、ユーザーは自分の行動の動機を理解などしていないが、5W1Hの手法を使い、真の動機を確認する。
ユーザーの行動を確認して、「何をしたいか？」を確認し、共通点を洗い出してペルソナを取得する
機能一覧/データモデル作成 (ストーリーボードの各ストーリーを実現するために必要な機能とデータを洗い出す)
この後のUIスケット、画面フロー、プロトタイプ作成時の基礎資料となる。
UIスケッチ/画面フロー作成 (各ストーリーを実現するために必要な画面と処理フローを構想する 紙とペン等出来るだけ手軽で多量のアイデアを短時間で出せる道具を使う=アナログツールは未だ健在)
アイデアを出す→良いアイデアを出す→アイデアを収束させる
でもよく考えたらiPadで紙+ペンと同じようなことが出来る。画面やフローを作成するソフトウェアも存在する。コピーも簡単(ただし、アイデアのブレストには向かない)
UIプロトタイプ作成 (動きをつけて検証する)
画面スケッチと画面フローでストーリーを実現できるかを確認する
ユーザーまたは被験者が実際に触りながら画面操作と画面の処理フローを確認うる
ペーパープロトタイプでもある程度のテストは可能(ただし動きをテストするには効果が落ちる)
プロトタイピングができるソフトもあるよ(5000円くらい？もっと安い？)
keynotopia(keynoteのテンプレート)
プロトタイプが使えるものか前もって確認する。
ユーザビリティテスト
どこまでやるの？
作成したプログラムが目的した価値をユーザーに提供しているか確認し、改善点を出す。
ヒューリスティックテスト
定量的に評価可能なKPIの定義と測定
初期テストからある程度期間を置いてもっぺんテストする
専門的な機関にユーザーテストを依頼すると、それなりのコストが発生する。(1ヶ月以上で100万)なので、友人、同僚3人でやればよい。
ヒューリスティックテスト(専門家の経験則からテストを実施)
データの収集はリリース前にやったほうがよい。(出来るだけ早い段階で)
リリース後もユーザビリティテストはやったほうがいい。
e.g. NCDCの方法論
UX Driven Development
ベストプラクティス(ささやかな経験則)
- UI/UXデザインに正解は存在しない(トレードオフが存在する 適切に定義されたペルソナとUXデザイナーの経験と判断が必要。)
- みんなを幸せには出来ない(人によってニーズは異なる 対象を広げると質は落ちる 製品やサービスのペルソナを定義し、そのペルソナの満足だけに集中する)
- 既成概念を捨てて、常識を疑う(一般的によいものが必ずいいとは限らない コンテキストとユーザー、ユーザーのゴールによってよいものがある e.g.タブレットPCvsハンディターミナル ダムターミナルvsRIA)
- 部分だけでなく、全体に注目する(エンジニアは部分に注目する傾向がある。一つの場面での最適解がUX全体の一貫性を壊すことがあるので、常に全体としての一貫性を意識するように気をつける 核心機能でないかぎり、ここだけの解は避ける)
- 顧客から製品やサービスを守る(顧客=スポンサーとユーザーを区分する。顧客のためにデザインしたものは結果的にうまくいかないので、顧客のエゴや思い込みから製品を守る ペルソナ定義やメンタルモデル作成に顧客を参加させるが、最悪の場合ユーザーテストの結果で顧客を説得する必要がある)
- ユーザーになりきる!!(UI/UXについて考えたり議論したりするとき、必ずユーザーの視点で考える必要がある)
- 誰でも準専門家になる(ヒューリスティックテストに必要な専門家の経験則を形式知として組織で共有する 専門家のガイドラインやチェックシートを利用して、作業)
- ユーザーテストは逃げ道ではない(ユーザーテストは仮説検証の場。正しい仮説を持たずにユーザーテストをしても無駄。まずはベストの案を出し、その後に検証するためにユーザーテストを行う。ユーザーテストは複数の案が対立したときに有効 ←どっちの案が重要かユーザーテストで比較する)
- UI/UXを導入するには今がチャンス。スマートフォン/タブレットの普及により、ユーザーの要求水準が高くなってる。既存SIerの危機感がすごくて、大手ソフトウェアベンダーも「デザイン」をキーワードとして取り上げている。社内向け説明資料は十分。customer experience
- できることから徐々にやってもいい。(UI/UXデザインのすべてのタスクを一挙に導入する必要はない。)
- 既存プロセス/見積りとマージする。(要件定義と設計のフェーズにUXデザインのタスクをマージする→顧客の説得にはビジュアルイメージをうまく理由する)
推奨の本
UXデザイン入門
UXデザインプロジェクトガイド
最後に
デザインは相手に対する心遣い
UI UXはユーザーにたいする「もてなし」のこと。
http://nextcontceptdc.comから後日この資料はアップロードします。
次回2013年1月 「エンタプライズアプリの今と未来」
