昨日の土曜日は、先週に引き続き、ユーザー中心のWebサイト設計・ワークショップの2日目の講師をしてきました（前回の模様は「
ユーザー中心のWebサイト設計・ワークショップ1日目」を参照）。
前回は、インタープリテーション・セッションによるワークモデル分析～KJ法でのデータ統合～ペルソナ作成までの作業を実際にやってもらいました。今回はその続き（まさに、
ペルソナ作って、それからどうするの？
）で、実際にペルソナがどうWebサイトを利用するのかというインタラクションを行動シナリオに書いて、画面フローを考え、最終的にペーパープロトタイプをつくるという一連の作業をやってもらいました。
具体的には、以下のようなスケジュールで実施。
10:00 講義、アクティングアウトのビデオ上映
10:30 シナリオおよび画面フロー図の作成
12:00 昼食
13:00 ペーパープロトタイプの作成
14:50 休憩
15:00 成果発表（各チーム15分ずつ）
15:30 リフレクション・全体のまとめ
16:00 終了・解散
講義は、前回のおさらいと、今回の作業範囲であるシナリオ作成の注意点、シナリオを元にどう画面フローや画面構成を考え、ペーパープロトタイプに落としていくかというところを軽くお話した程度。あとは最後にペーパープロトタイプを使って行うアクティングアウト（オズの魔法使い）形式でのプレゼンの仕方を、事前に撮影しておいたビデオを使って紹介しました。
シナリオおよび画面フロー図の作成
前回の終わりに、
- 作成したペルソナを表現する写真を探してくること
- ペルソナの行動シナリオを１シーン分考えてくること
の2つを、参加者それぞれの宿題として出しておきました。
そこで今回の作業のまず1つめは、各自が探してきた写真から各チームで1つペルソナに採用するものを選ぶことでした。
片方のチームは、前回手書きで作成したペルソナを、自分でデータに起こし、しかも、自分で探した写真をはりつけてペルソナ基本文書をつくってきた人もいました。そうやってきちんとした写真付きのドキュメントにすると、よりペルソナが実在する人物に見えてくるから不思議です。
そのあと、今度は各自が考えてきたシナリオを元に、チームで1つのシナリオにまとめる作業に入ります。
おなじペルソナがおなじ目的を達成するプロセスを描いたシナリオでも、ひとりひとり描いてきたものは違うので、それをまとめるのは大変そうでした。それでも、こんな風にシナリオを描くのと、そのプロセスをフロー図で描く作業を役割分担して行うと、わりかし作業はスムーズで議論も活発になっていたようです。デザインというとどうしてもひとりひとりが個別に作業をするイメージがあると思いますが、実はグループ作業を行う利点はこういうところにちゃんとあるんですね。
このシナリオの段階で、具体的にユーザーが行う行動・Webの操作の様子を描いていないと、そのあと、画面遷移図や画面にどんな情報要素が必要かということを考えられません。
実際にはシナリオを書いていく作業と画面遷移・画面に掲載する情報要素を考える作業は、並行して行うと、ユーザーがどのように画面をみてどう感じるかということと画面に何が必要なのかが具体的に見えてきます。
昨日の作業でもそうしてもらいましたが、これがうまくいくかどうかは、前回までのワークモデル分析～データ統合の段階で、どれだけ実際のユーザーの行動を詳細に把握できていたかによるんですね。ちゃんと分析ができていれば、ペルソナ行動シナリオや画面遷移図を考える際にも、発想のヒントがそこから得られるんです。
実際のユーザーの行動を詳細に把握しておくことで、それ自体がデザインのアイデアを発想するヒントになる。参加してくれた方のリフレクションを聞くと実際それを実感していただけて良かったなと思いましたが、それこそがユーザー中心のデザインの一番の利点です。
ペーパープロトタイプの作成
シナリオを描き、ある程度の画面遷移図とそれぞれの画面に必要な情報要素の洗い出しができていれば、ペーパープロトタイプをつくっていく作業はそれほどむずかしいものではありません。
予定では、午前中のうちにそこまで終わっているはずでしたが、両チームとも、画面遷移図とそれぞれの画面に必要な情報要素の洗い出しの作業はすこし残っていた状態で、まずはその部分をしっかり整理することから作業をはじめたようです。
ただし、実際にやってみるとわかることですが、ペーパープロトタイプの作成作業をすることによってはじめて、この要素も必要だとか、この画面遷移だとうまくいかないということが見えてきたりもします。ラフに画面を描いてみるだけでも気づきがあります。
「つくりながら考える」ことで発見を得ることこそがプロトタイプをつくる目的です。だから、どんどん具体的な画面を描いてみて、それがシナリオ通り、ユーザーにとって価値あるものになっているか。なっていないのだとしたら、画面に問題があるのか、それとも元のシナリオに問題があるのかを検討する。そういう繰り返しで、だんだんと自分たちの考え、デザインがまとまっていく。今回はその作業をやってもらいながら発表用にデザインコンセプトを1枚まとめてもらいましたが、こういう作業を繰り返しているとコンセプトをまとめるのもそれほど苦にならないのではないかと思います。
成果発表
さて、両チームのペーパープロトタイプができたところで、それぞれがデザインしたWebを別のチームにプレゼンします。
プレゼンは先にも書いたとおり、作成したペーパープロトタイプを使ってのアクティングアウトで行いました。ひとりがシステム役になり、そのほかの人がペルソナを演じたり、ペルソナの家族を演じたりして、ユーザーがどう操作を行い、それに対してシステムがどうフィードバックをするのかをプレゼンテーションしてもらうのです。
さすがに時間がなく、アクティングアウトのための練習をする時間は両チームともなかったようですし、演じる恥ずかしさもあってか、外野からのつっこみもあったアクティングアウトでしたが、両チームともどんなものをデザインしたのかは伝えられていました。
片方のチームが企画・デザインした旅行サイトは僕自身、本当にあったら便利だなと思うものになっていました。2日間という短い時間でもここまでできるんだなと一番実感したのはそこですね。
ユーザー中心デザインの本当のメリット
こんな感じで、先週との2日間計10時間のワークショップで、ワークモデル分析～ペーパープロトタイプの作成まで、ユーザー中心デザインのプロセスでのコアとなる部分の作業は体験してもらえました。
参加者の方が言っていたことで記憶に残ったのは、
- グループワークを行うことで、いろんな人のアイデアを聞きながら作業ができ、ひとりで作業していては思い浮かばないアイデアが出てくるし、アイデアが偏らずに済む
- ワークモデル分析やKJ法によるデータ統合がデザインするのに何の役に立つのか1日目が終わった時点ではわからなかったが、実際にシナリオを書いて画面遷移を考えたりプロトタイプをつくるなかで、分析作業で得たものからアイデアが生まれるのだということが実感できた
- 必ずしもペルソナが重要なのではなくて、実際のユーザーの行動を把握したり、それを元にシナリオを書くという過程がデザインの役に立つのだということが体験的にわかった
- 本を読んだだけではわからなかったことが、実際にやってみて腑に落ちた
といったところ。
まさにそうなんですよね。こういう点がユーザー中心デザインのプロセスを使ってデザインする利点だと思います。別に、ユーザーのためだけに、こんなめんどくさいプロセスを採用するわけじゃないんです。
むしろ、
デザインする側が、自分たちが何をデザインしているのかということを、ちゃんと実感しながら、しかも、それがきっとユーザーの役にも立つだろうと感じながらデザインできることにこそ、ユーザー中心デザインの一番のメリットがあると僕は思っています。
今回はじめて、こういうワークショップをやらせていただいて、主催者側としては運営面でいろいろ反省することがないわけではありません。でも、参加してくれた方から先のような言葉が聞けただけでも、伝えるべきことは伝えられたかなと思います。
参加してくださった方、お疲れ様でした。ぜひここで体験したことを普段のお仕事でも役立ててくださいね。
それから、前回同様、手伝ってくれた
矢野さん、そして、この機会をくださった林さん、ありがとうございました。
さて、いつということは決まっていませんが、このワークショップのシリーズは今後も続けていく予定です。次回の予定が決まりましたら、またここでも告知しようと思います。興味のある方はお楽しみに。
→
ユーザー中心のWebサイト設計・ワークショップ1日目関連エントリー
| このブログのURL
|この記事のURL
