ユーザインタフェース　第9回 シナリオとペルソナ

インタビュー結果の分析 シナリオ／ペルソナ法 シナリオとは：　 ユーザを主人公とした製品使用上のエピソード 利点 コンテキストを失わないこと どんな状況で、どんな行動で、どんな結果になったかという、一連のプロセス　を詳細に記述できる。 主語と目的語を明示して、あいまいな表現は用いないので、読み手によって解釈が変わることがない。

シナリオの例 頭で想像したような単純なプロセスでなく、 本当にあったプロセス を書く [悪例] 本当にあったプロセス　　を書く [悪例] スプーンを持ち、容器の蓋を開け、ゼリーをすくい、口に運んだ。 [良例] 真知子は中身が飛び散らないように、蓋をゆっくりはがし、蓋をテーブルに上向きに置いた。食べ終わったら、ゴミを容器に詰め込んだ。 春樹は蓋をはがして内側をなめた 太郎はゼリーを細かく砕いて容器から直接口に流し込んだ 肇は口の中で具のフルーツとゼリーを分離して食べるのが好きである。

シナリオの書き方 インタビューではメモをとる。画像や音声を記録。 記憶が消えないうちに書く（ インタビュー実施日に ） 記憶が消えないうちに書く（　インタビュー実施日に　） インタビューを振り返って、メモにすべてが書かれているかを確認 個別のエピソード　をひとつずつ書いていく 主語と目的語を明示し、具体的に　書く。あいまいな表現をしない。 重複しないように、書いた事実はメモに線を引き消す。 エピソードを　時間順に　並べる。 因果関係や包含関係　があるエピソードはまとめる。 （例）　ゼリーの蓋を剥がして、上向きに置いた。

シナリオの例 － プロフィールといきさつ － プロフィール シナリオの例 　－　プロフィールといきさつ　－ プロフィール Pさん（３０歳 男性）は、大学の情報系学部の教員である。Pさんは、専門上、インタネットを使うことが多く、多くのサイトに会員登録している。 メールマガジン整理が必要になったいきさつ Pさんが、クリップアートを無料でダウンロードするために、あるサイトに会員登録したとき、メールマガジンの送付に特に理由なく同意した。後日、そのサイトが送ってくるメールマガジンにユーザ中心設計の手法が紹介されており、研究を進めるのに役立った。それ以来、ここぞと思ったサイトのメールマガジンには登録するようになった。メールマガジンの数が増えると多くの記述を読まないといけないが、役に立つ情報も１０回に１回程度はあるので、 Pさんは仕方ないかと思っている。

シナリオの例 ー 利用場面（多いほど良い） ー シナリオの例 ー　利用場面（多いほど良い）　ー Pさんは、メールマガジンが届いたときには、発信者名と件名から、だいたいの内容を想像したうえで、本文の見出しだけを斜めに読み、毎日５０通のメールマガジンを読んでいる。 どのメールマガジンも有益な情報は最初と最後にあるとPさんは考えている。そのため、ひとつのメールマガジンを読むときは、Pさんはひとおとり見出しを最後まで見て、興味があった見出しの内容だけをじっくり読んでいる。 Pさんは、懸賞やキャンペーン情報が好きであるので、これらの見出しがついた記事はしっかり読む。また、Pさんはメールマガジンの最後についている人気のコラムも読むようにしている。 メールマガジンが届き始めてから最初の５通ぐらいは、Pさんは読むようにしている。もし、あまり興味がわかないのなら、Pさんは配送を解除している。 Pさんは解除用のアドレスをクリックして興味がわかない配送を解除している。このアドレスは、たいてい、メールマガジンの最後についている。解除用のアドレスがメールマガジンにないときは、Pさんは発行元のサイトを訪れ、解除方法を探している。解除にIDやパスワードが必要なときは、それがわからず解除できないこともある。解除できないとき、Pさんは発行元に問い合わせることはしない。そのようなメールマガジンは届いても読まずに削除すればいいとPさんは考えている。

シナリオの検証 シナリオ記述時に、ユーザの行動について疑問があれば、 再面談 を実施 できたシナリオを、ユーザに確認してもらう シナリオ記述時に、ユーザの行動について疑問があれば、　再面談　を実施 できたシナリオを、ユーザに確認してもらう 記述がユーザの意図したものでないものであった。 ユーザ自身が、違うことをインタビューで話していた シナリオを見てユーザが削除を求めることがある。 削除しては本当のプロセスが記述できない プライバシが保護されることを説明して、納得してもらう シナリオの検証は、必ず、ユーザと顔を合わせて実施

シナリオの利用方法 シナリオを、さまざまな設計者が見ると多くの解が見つかる。 以下を見つける 本物のタスク 真のユーザニーズ タスク　：テストでユーザに実施してもらう作業 前述の悪例は偽のタスク。良例は本物のタスク。 一般的には、個別のエピソード　がタスクになる。 真のユーザニーズ シナリオ内には2種類のユーザニーズ 「○○があれば便利」などという　明示的ニーズ 明示的ニーズをうのみにせず、背景の真のニーズを取る ユーザは明示的に要求していないが、そのコンテキストにおいて当然必要であると論理的に推定できる　暗黙のニーズ [例]　 観察 「口の中で具のフルーツとゼリーを分離させた」 シナリオ 「○○さんが口の中で具のフルーツとゼリーを分離させた瞬間、えもいわれぬ不思議な感覚が口の中にひろがった」 真のニーズ 未体験の食感をユーザに与えるゼリーが必要

ユーザニーズ探索 ユーザの プロセス全体 を正しく支援することが目的だから、当たり前のニーズ、誰も気づかなかったニーズの両方が対象 ユーザの　プロセス全体　を正しく支援することが目的だから、当たり前のニーズ、誰も気づかなかったニーズの両方が対象 ステップ１：シナリオ分解 シナリオをユーザの 行動や場面の変わり目に注目して分解 ステップ２：シナリオ分析 真のニーズを同定 ①　明示的なニーズから始め　　②　暗黙のニーズを論理的に推定 分析では解を見つけない。何が求められているかを見つける 同定したニーズに具体的な機能や手段が出てくれば要注意 ステップ３：解決案の発想 技術的、コスト的、スケジュール的に実現可能な案 制約条件を満たしている、すべての案をリストアップ この案をユーザテストでテストして、どれを採用するかを決める。

シナリオのメリット メリット シナリオからのニーズと解決案を導出する例 シナリオは ユーザの実際の体験 を再現したもの シナリオ「真知子は中身が飛び散らないように、蓋をゆっくりはがし、蓋をテーブルに上向きに置いた。食べ終わったら、ゴミを容器に詰め込んだ。」 ニーズ「蓋がテーブルを汚す。蓋がゴミ箱のヘリにくっつく。」 解決案「蓋が容器の上に巻きあがり、食後、再び閉じられるようにする」 メリット シナリオは　ユーザの実際の体験　を再現したもの 設計に適度な制約と自由度を与える シナリオに描かれた　コンテキスト（場面や前後関係）　が解決案に具体的な制約を与える その制約の中で　ニーズを満たす解決案　を自由に発想できる シナリオは　可逆的 テスト結果が悪ければ、解決案を作った過程のどこが悪かったかを再検証可能

ペルソナ（仮面） ユーザの特徴を表すイメージ 同様の特性をもつ実際のユーザ群 を代表する仮想のユーザ像 アラン・クーパー著, 山形浩生訳, コンピュータは、むずかしすぎて使えない！, 翔泳社, 2000 開発に携わる組織全体を顧客志向に 同様の特性をもつ実際のユーザ群　を代表する仮想のユーザ像 以下を具体的にイメージできる 自分たちが設計、開発しようとするものを実際に使う ユーザがどういうゴール、役割をもち、どんな環境でどんな行動をするのか ユーザは典型的にどんな活動をしているのか

ペルソナの抽出 ユーザの情報を1人分ずつ1枚の カードに書き出す。 カードを並べ替え、似たユーザをまとめる ユーザの情報を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 に相当する)画面で その画面に必要なものはそろっているか それは使いやすいか 他の画面と重複して　いないか 作業の流れ に無理がないか どこでもやりたいことができるか そのための方法がすぐに見つかるか

ユーザインタフェース レポート課題 プログラミングに対して学生が、よりやる気を出して演習に取り組むようには、どのようなサイトを構築すればよいか考えるため、シナリオを作成することを考える。学生がやる気を出す場面の実例を調査せよ。 ふたり一組となって、それぞれ師匠（学生）と弟子（サイト構築者）の役割を交互に担い、弟子が師匠にインタビューを実施せよ。インタビューの内容を本レジュメの前回のスライドの「メールマガジンでの例」に習い、記録した文書を作成せよ。 インタビュー結果をもとに、本レジュメの「シナリオの例」のスライドに習い、シナリオを作成せよ。

インタビュー対象者の氏名も記載すること． インタビューは１０分以上３０分以内とする。その場合、通常、シナリオはA4用紙に１１ポイントのフォントで３枚以上となる． シナリオの解析のため，電子ファイルとして作成したものと印刷物の２つを提出すること． 印刷物の提出： 学びステーション　受付 本ページを切り取って提出時の表紙とすること 電子ファイルの提出 ファイルを添えつけではなく、箇条書きのテキストを以下にメールせよ scenario@de.is.ritsumei.ac.jp 期限　２週間後授業日（学びステーション閉館まで）