ユーザインタフェース第9回シナリオとペルソナインタビュー結果の分析シナリオ／ペルソナ法 • シナリオとは： – ユーザを主人公とした製品使用上のエピソード • 利点 – コンテキストを失わないこと – どんな状況で、どんな行動で、どんな結果になったかという、一連のプロセスを詳細に記述できる。 – 主語と目的語を明示して、あいまいな表現は用いないので、読み手によって解釈が変わることがない。シナリオの例 • 頭で想像したような単純なプロセスでなく、 • 本当にあったプロセスを書く • [悪例] – スプーンを持ち、容器の蓋を開け、ゼリーをすくい、口に運んだ。 • [良例] – 真知子は中身が飛び散らないように、蓋をゆっくりはがし、蓋をテーブルに上向きに置いた。食べ終わったら、ゴミを容器に詰め込んだ。 – 春樹は蓋をはがして内側をなめた – 太郎はゼリーを細かく砕いて容器から直接口に流し込んだ – 肇は口の中で具のフルーツとゼリーを分離して食べるのが好きである。シナリオの書き方 • インタビューではメモをとる。画像や音声を記録。 • 記憶が消えないうちに書く（インタビュー実施日に） • インタビューを振り返って、メモにすべてが書かれているかを確認 • 個別のエピソードをひとつずつ書いていく • 主語と目的語を明示し、具体的に書く。あいまいな表現をしない。 • 重複しないように、書いた事実はメモに線を引き消す。 • エピソードを時間順に並べる。 • 因果関係や包含関係があるエピソードはまとめる。（例）ゼリーの蓋を剥がして、上向きに置いた。シナリオの例－プロフィールといきさつ－ • プロフィール Pさん（３０歳男性）は、大学の情報系学部の教員である。Pさんは、専門上、インタネットを使うことが多く、多くのサイトに会員登録している。 • メールマガジン整理が必要になったいきさつ Pさんが、クリップアートを無料でダウンロードするために、あるサイトに会員登録したとき、メールマガジンの送付に特に理由なく同意した。後日、そのサイトが送ってくるメールマガジンにユーザ中心設計の手法が紹介されており、研究を進めるのに役立った。それ以来、ここぞと思ったサイトのメールマガジンには登録するようになった。メールマガジンの数が増えると多くの記述を読まないといけないが、役に立つ情報も１０回に１回程度はあるので、 Pさんは仕方ないかと思っている。シナリオの例ー利用場面（多いほど良い）ー • Pさんは、メールマガジンが届いたときには、発信者名と件名から、だいたいの内容を想像したうえで、本文の見出しだけを斜めに読み、毎日５０通のメールマガジンを読んでいる。 • どのメールマガジンも有益な情報は最初と最後にあるとPさんは考えている。そのため、ひとつのメールマガジンを読むときは、Pさんはひとおとり見出しを最後まで見て、興味があった見出しの内容だけをじっくり読んでいる。 • Pさんは、懸賞やキャンペーン情報が好きであるので、これらの見出しがついた記事はしっかり読む。また、Pさんはメールマガジンの最後についている人気のコラムも読むようにしている。 • メールマガジンが届き始めてから最初の５通ぐらいは、Pさんは読むようにしている。もし、あまり興味がわかないのなら、Pさんは配送を解除している。 • Pさんは解除用のアドレスをクリックして興味がわかない配送を解除している。このアドレスは、たいてい、メールマガジンの最後についている。解除用のアドレスがメールマガジンにないときは、Pさんは発行元のサイトを訪れ、解除方法を探している。解除にIDやパスワードが必要なときは、それがわからず解除できないこともある。解除できないとき、Pさんは発行元に問い合わせることはしない。そのようなメールマガジンは届いても読まずに削除すればいいとPさんは考えている。シナリオの検証 • シナリオ記述時に、ユーザの行動について疑問があれば、再面談を実施 • できたシナリオを、ユーザに確認してもらう – 記述がユーザの意図したものでないものであった。 – ユーザ自身が、違うことをインタビューで話していた • シナリオを見てユーザが削除を求めることがある。 – 削除しては本当のプロセスが記述できない – プライバシが保護されることを説明して、納得してもらう – シナリオの検証は、必ず、ユーザと顔を合わせて実施シナリオの利用方法 • シナリオを、さまざまな設計者が見ると多くの解が見つかる。 • 以下を見つける • 本物のタスク – タスク：テストでユーザに実施してもらう作業 – 前述の悪例は偽のタスク。良例は本物のタスク。 – 一般的には、個別のエピソードがタスクになる。 • 真のユーザニーズ – シナリオ内には2種類のユーザニーズ – 「○○があれば便利」などという明示的ニーズ • 明示的ニーズをうのみにせず、背景の真のニーズを取る – ユーザは明示的に要求していないが、そのコンテキストにおいて当然必要であると論理的に推定できる暗黙のニーズ [例] 観察「口の中で具のフルーツとゼリーを分離させた」シナリオ「○○さんが口の中で具のフルーツとゼリーを分離させた瞬間、えもいわれぬ不思議な感覚が口の中にひろがった」真のニーズ未体験の食感をユーザに与えるゼリーが必要ユーザニーズ探索 • ユーザのプロセス全体を正しく支援することが目的だから、当たり前のニーズ、誰も気づかなかったニーズの両方が対象 • ステップ１：シナリオ分解 – シナリオをユーザの行動や場面の変わり目に注目して分解 • ステップ２：シナリオ分析 – 真のニーズを同定 ① 明示的なニーズから始め ② 暗黙のニーズを論理的に推定 – 分析では解を見つけない。何が求められているかを見つける • 同定したニーズに具体的な機能や手段が出てくれば要注意 • ステップ３：解決案の発想 – 技術的、コスト的、スケジュール的に実現可能な案 – 制約条件を満たしている、すべての案をリストアップ • この案をユーザテストでテストして、どれを採用するかを決める。シナリオのメリット • シナリオからのニーズと解決案を導出する例 • • • シナリオ「真知子は中身が飛び散らないように、蓋をゆっくりはがし、蓋をテーブルに上向きに置いた。食べ終わったら、ゴミを容器に詰め込んだ。」ニーズ「蓋がテーブルを汚す。蓋がゴミ箱のヘリにくっつく。」解決案「蓋が容器の上に巻きあがり、食後、再び閉じられるようにする」メリット • シナリオはユーザの実際の体験を再現したもの • 設計に適度な制約と自由度を与える • • シナリオに描かれたコンテキスト（場面や前後関係）が解決案に具体的な制約を与えるその制約の中でニーズを満たす解決案を自由に発想できる • シナリオは可逆的 • テスト結果が悪ければ、解決案を作った過程のどこが悪かったかを再検証可能ペルソナ（仮面） • ユーザの特徴を表すイメージ – アラン・クーパー著, 山形浩生訳, コンピュータは、むずかしすぎて使えない！, 翔泳社, 2000 – 開発に携わる組織全体を顧客志向に • 同様の特性をもつ実際のユーザ群を代表する仮想のユーザ像 – 以下を具体的にイメージできる – 自分たちが設計、開発しようとするものを実際に使うユーザがどういうゴール、役割をもち、どんな環境でどんな行動をするのか – ユーザは典型的にどんな活動をしているのかペルソナの抽出 • ユーザの情報を1人分ずつ1枚のカードに書き出す。 – 各ユーザのシナリオを取り出す – 名前、性別、年齢、職業、行動の特徴、雰囲気、印象的言葉などなど • カードを並べ替え、似たユーザをまとめる • ユーザのグループにタイトルを付ける – 頑張り屋、マイペース型など • ベースユーザを見つけるそれぞれのグループをもっとも代表しているユーザ – カードを見ながら、インタビューを思いだし選定 • ハイブリッドユーザに発展させる同じグループの他のユーザの要素も併せ持ったユーザ – ベースユーザの話を詳しく思い出して1つのシナリオとして書き出す。 – 同じグループ内の他のユーザの話から役に立ちそうな情報を引用して、ベースユーザのシナリオに書き加える • ペルソナの決定 – ハイブリッドユーザにもっとも適した架空の個人情報を創作し与える – 名前(例、ケイスケ)や職業だけでなく顔写真や似顔絵を用意 – 開発チーム全員が、ユーザイメージをつかむように「ケイスケ」を使用ペルソナの利用 • 1つのプロジェクトで3人から6人のペルソナ • ペルソナに必ず順位を付ける – さまざまな要因を関係者で十分に検討 – 各ペルソナの市場規模の大きさ、競合との差別化、成長力など、 • プライマリペルソナ – 優先順位1位のペルソナ • 設計チームはこのペルソナのニーズ実現に全力を傾ける – 2位以下のペルソナはセカンダリペルソナ • ペルソナの原則 – みんなのためにデザインするのではなく、1人のためにデザインする – プライマリペルソナの要求を優先する • 製品の機能や意匠が無秩序に拡大して混乱することを防ぐペルソナは目的ではなく手段 • ターゲットを絞り込んだ設計を可能にする – 設計チームの個々のメンバが描く勝手なユーザ像に振り回されない • ペルソナ作成で戦略策定の作業の半分は達成される – ペルソナは顧客を理解しようという意欲を駆り立てる – ペルソナとシナリオは2つ揃って初めて意味をもつ – インタフェース設計ではモノと人のインタラクションを描く – シナリオは、実際の行動の正確な表現 – 実ユーザのデータを元にペルソナをつくっただけでは新しい製品は生まれてこない – ペルソナを動かすシナリオを描いてこそ、新しい製品が生まれる作業の新しい方法を創作 • ペルソナ内のユーザが抱える問題を解決する，新しい work practice （作業の方法）を考える． – プライマリ・ペルソナから順に – その work practice を実現する製品を作る • Storyboard の活用 – 作業の方法を示した絵コンテ Storybord は具体的に部屋の壁に大きな付箋を貼って書く開発チーム全員が共有する Storyboard上のストーリを実現するユーザインタフェース • 新しい家の間取りを決めるのと似ている – この作業はこの部屋で • その部屋には何が必要か – 作業の流れに無理がないか • 個人（ペルソナ）ごとに作業の手順は異なる User Environment(ユーザ環境)の設計 • ユーザの作業環境を focus area に分割 – 間取りにおける部屋に対応 • 各 focus area は以下を示す – ユーザの仕事をどのように支援するか – どんな機能が備わっているか – 他の focus area から/へ，どのように移動するか各 focus area を構成する情報 • • • • タイトル目的機能リンク – どこから，どこへ • 使えるオブジェクト – どんな道具が使えるか • 制約 – やってはいけないこと • コメントソフトウェア製品の場合，各 focus area は各画面に相当する場合が多い（紙でつくった）プロトタイプでテストソフトウェア製品の場合，考案した画面で，思い通りの User Environment ができているかをテスト • この作業はこの (focus area に相当する)画面で – その画面に必要なものはそろっているか – それは使いやすいか – 他の画面と重複していないか • 作業の流れに無理がないか – どこでもやりたいことができるか – そのための方法がすぐに見つかるかユーザインタフェースレポート課題 • プログラミングに対して学生が、よりやる気を出して演習に取り組むようには、どのようなサイトを構築すればよいか考えるため、シナリオを作成することを考える。学生がやる気を出す場面の実例を調査せよ。 1. ふたり一組となって、それぞれ師匠（学生）と弟子（サイト構築者）の役割を交互に担い、弟子が師匠にインタビューを実施せよ。インタビューの内容を本レジュメの前回のスライドの「メールマガジンでの例」に習い、記録した文書を作成せよ。 2. インタビュー結果をもとに、本レジュメの「シナリオの例」のスライドに習い、シナリオを作成せよ。 • インタビュー対象者の氏名も記載すること． • インタビューは１０分以上３０分以内とする。その場合、通常、シナリオはA4用紙に１１ポイントのフォントで３枚以上となる． • シナリオの解析のため，電子ファイルとして作成したものと印刷物の２つを提出すること． – 印刷物の提出： • 学びステーション受付 • 本ページを切り取って提出時の表紙とすること – 電子ファイルの提出 – ファイルを添えつけではなく、箇条書きのテキストを以下にメールせよ – [email protected] – 期限２週間後授業日（学びステーション閉館まで）