Archive for the ‘PaperPrototyping’ Category
金曜日, 3月 14th, 2008
長い間、検証を進めてきたが、ここで、おれ等流PPのためのツール、および、PPを利用したユーザビリティ調査の手順をまとめておく。
おれ等流 ツール類 for PP
画用紙（八つ切り以上のサイズ）
マジック（黒×人数分、赤、青）
はがせるテープ（検索窓に書き込んでもらって、それを結果画面に利用などの用途）
テープ（修正用）
はさみ
蛍光ペン
ダンボールか新聞紙（背景用）
未使用コピー用紙（下書き、トグルのヒンジ、その他応用可能）
おれ等流 PPを利用した・・・（中略）・・・手順
キックオフミーティング
コアチームを組む
目標、リスク、考慮事項などについて話し合う
ユーザーのプロフィールを想定する。
スケジュールを立てる
ユーザーの募集（今回は社内人員なので略）
新規の成果物であれば、ここで、おおよそのイメージを共有して確認しておく。
課題設計 ユーザビリティテストに利用する課題の内容を決める。手順１で話し合った目標、リスク、考慮点などを参考にすること。
プロトタイプの作成 ここに一番時間がかかる。
画面遷移図のまとめ
作業分担を決める。
コピー用紙で下書き＆文字サイズのサンプルを作成しておく
インターフェース動作をインデックスカードにまとめて、分類しておく
ウォークスルーテストを行う。
改善しておく点が一致したら、改善を行う。
心の準備
ユーザビリティテスト
テストの実行
テストの振り返り
次のテストの前に改善点があればPPを修正する。
問題点のまとめ
テストで挙がった問題点を分類・整理する。
問題点の対応方法・（問題点が多ければ）順位付け
改善の実行
ウォークスルーテスト
（※）必要と余力があれば、７番から６番に戻ってもいいかも
この最終成果物は、インターフェース仕様書とインターフェース動作仕様書である。
使ったフォーマット
課題シート
フォーマット化したいもの
インタビューシート
インターフェース動作仕様シート、もしくは、インデックスカードの内容
Posted in PaperPrototyping, 未分類 | No Comments »
金曜日, 3月 14th, 2008
今日は、いよいよ被験者にPPを使ってサイトを使ってみてもらうことになった。
被験者 ()内は想定しているユーザープロファイル --
A氏（業務でWeb開発を行っている：jQueryで製品を作る:Javascriptは上級:jQueryを既に利用している）
B氏（趣味でWeb開発を行ったことがある:jQueryには興味がある:Javascriptは初心者:jQueryは初めて）
C氏（業務でWeb開発を行っている:jQueryで製品を作る：Javascriptは中級:他のライブラリを利用している）
D氏（業務でWeb開発を行っている：jQueryに興味がある:Javascriptは初心者：jQueryは初めて）
４名の方は、ユーザープロファイルにもっともマッチしてそうな社内の人に時間をもらった。
課題に関しては事前に準備したシートをプリントアウトして、各被験者に実行してもらいたいテーマをそれぞれ提示して、テストを行った。また、テスト実施側３名の役割分担は、１名は、記録係固定（経験があるので、比較的、経験をつまないとならない他の役を２名にゆずる）、他２名はコンピュータ役、進行役を被験者ごとに変えて実施することにした。
さて、テスト本番。一人ずつ被験者に来てもらい、今回の目的、テストされるのは、プロトタイプであって、被験者でないことを一通り説明し、課題説明に移る。
第一の被験者に対しては、社内の人相手ということもあり、フランクすぎる雰囲気になってしまった。リラックスしてやってもらうつもりで語りかけていたが、逆にぐだぐだな感じに・・・なかなかもって進行役は難しい。
人の話、感情を引き出すということがこんなにも難しいことだとは思わなかった。職歴上、こういうことに長けている、記録係固定のメンバーに助けてもらう場面も多々あった。あとで聞くと、被験者に対して、「弟子入りするような気分で」接していないとのことだった。被験者の声に真摯に耳を傾け、想定していたユーザープロファイルと異なっていれば、それに応じた課題に変更するなどして、テストを行う。最初から決め付け、こうだろうという気持ちがあると、それが態度に表れて、被験者に伝わってしまい、最悪、被験者側が、そのイメージに合わせた形で、テストが行われてしまいかねない。相手のことを知りたいんだよという態度でなければ、コミュニケーションは失敗する。
今回の進行役を務めた中で、本当に最悪だと思ったのは、あまりに予想外だった被験者の反応に対して、意外だという感情をストレートに顔に出してしまったことだ。テストされているのはプロトタイプなのに・・・。
さて、課題そのものの内容に関しては、簡単な課題なので、あっという間に終わってしまうんではないかと思っていたが、やってみると、案外と、人それぞれ、いろいろな方法でサイト操作を行っていることが確認できた。そのときの気持ちも言葉にしてもらうことで、どういう部分で悩むのかがよりわかりやすくなった。
このあとの見直し作業に関しては、記録係が記録した被験者インタビューの内容から浮かんだ問題点を、PPのインターフェースに関するものと、テストに関するものに分割し、後者は今後の反省点として生かし、前者は、さらに分類していく。このようにKJ法を用いて、問題を分類、整理し、すぐ対応したほうがいい問題点を選別して、PPに反映する。PPの修正は慣れたもので、ピックアップした２つの改善点を２０～30分ほどで行った。PDCAをきっちり回す。
この後、ウォークスルーテストを行い、思ったとおりの改善が行えたか確認し、一旦PPによる開発の実験を終了した。
さて、この見直し作業で、課題図書を読んで手順を確認してみたが、この見直しの部分で、面白い記述があった。
インターフェース仕様書＝PPとして利用できる。確かにPPの目的のひとつではあった。
インターフェース動作の文書化。PPはインターフェースの要素を示すもの。それらがどのように相互作用するかといった情報、カーソルのようにプロトタイプ化が難しい要素の動作に関する情報はコンピュータ役の頭にあったりする。これらの情報をインデックスカード化する。でも、これはテストの前に作っておくべきものではないか・・・早く言ってよ・・・
<今週の成果>
インタビューは相手のことを知りたいという気持ちで臨む。いいたいことを言ってこうでしょ、ではまったく意味をなさない。
こうすべきというイメージを持って臨むのはNG。
PDCAをしっかり回して、どんどんとPPを改善することに意義がある。インターフェース仕様書をブラッシュアップしていこう。
PPの修正は、手馴れてくると、どんどん早くなっていく。修正を恐れずに、修正すべき点の検討に時間をかけよう。
インターフェース動作を文書化しよう。学生時代に使った英単語・熟語を覚えるための、リングつきインデックスカードでもいい。そして、これは、テストの前に一度整頓しておいたほうがよいだろう。
Posted in PaperPrototyping, 未分類 | No Comments »
金曜日, 2月 29th, 2008
ペーパープロトタイプ（以下PP）開始準備
今日は、メンバーのうち、一名が、業務上、遅れて参加することとなった。残った二名で、先行して作成を進めていく。
まず、先週に、お互い作成したイメージに基づき、これから作成するプロトタイプの中身の概要をリストアップする。その後、作成にあたって、下記の約束事を決めた。
＜決め事＞
簡単な下書きをしよう。ただし、鉛筆・シャープペンでやろう。
絶対にフリーハンドで書いていくことにしよう。
コンピュータ役の負担も考えて、工夫しながら作成すること。
字は大きく書きましょう。
PP作成開始
とりあえず、HOME画面から作ってみることにする。
さぁ、作るぞ、と腕まくりをしてとりかかろうとしたときに、ハタと気が付いた。
先週、課題図書にあった順序 「課題作成 -> PP作成」が感覚的に疑問だよね、作ってみないと課題が浮かんでこないよね、という話になったのだが、逆に、課題がまとまってないと、「どの部分を手を抜いて作っていいのか」、「どこは手を抜いてはならないのか」が明確にならないので、結果的に何に重点を置いたPPなのかわからないものができてしまう。
今回のチーム内では、正しい順序は、「課題作成・共有」⇒「PP作成」 ⇒・・・、ただし、既存のものがない場合には、さらに前に、「作るもののイメージの共有」という工程が必要だよね、という結論に至った。
さて、 そんなことを議論しながら、作成を進める。お互い、『？？何かおかしい・・・それは、あの前提が誤っているのではないか』、と感じながらも、黙々と作業を続ける・・・「あー、腹減った」と思っていたときに、遅れて参加の一名が登場。
『字がでかい』
二人が感じていた違和感 をそのままストレートに表現されてしまった。
ちょっとしたショックを感じつつも、ご飯を食べてから再出発を誓う二人であった。
第３週目の成果
A4のコピー用紙でもよいので、下書きをして、より具体的な構成を考えてから行動しよう。作成中に気付く点も多いので、下書きを一度することで、より課題が明確になることが期待される。
字のサイズはおおきければいいってもんじゃない！！！大きすぎると、テスト時に逆にデザインの粗悪さに目が行ってしまい、本来のユーザビリティのテストではなくなってしまう可能性が高い。また、機能も埋もれて見えてしまう。⇒文字サイズをあらかじめサンプル化してから作成しましょう。
作業を分担して行う場合は、黒マジックは人数分必要。
共通で使うパーツはその部分だけを作成して積極的に使いまわそう。
A4サイズ、B4サイズなど、必ずしも定型の形になるとは限らないので、セロハンテープでの切り貼りも必要になる。
多少の外科手術（※）は可能。本来の目的は、ミテクレのテストではなく、ユーザビリティのテストにある。見た目はあまり気にするな。
API詳細などは、Web上で同様のものがあるのであれば、それを印刷して代用することもできる。
画用紙であるのはなんでだろうか？⇒普通のコピー用紙だと、複数回のユーザビリティテストの再利用、修正に耐えられない。
（※）外科手術とは・・・紙を切り貼りして、誤字の修正や、表示の追加を無理やり行うこと。見た目は多少悪くなるが、手数は減る。
Posted in PaperPrototyping | No Comments »
金曜日, 2月 29th, 2008
会議室が空いていないこともあり、別棟に空きを見つけて実施。
よほどの緊急時でなければ、電話中断などが入らないという利点があり、しばらくここを利用することとなった。
本日は、各自持ち寄った課題図書を読み合わせながら、進めていくことになった。
全体の手順をさらっと確認し、特に重要そうなところを重点的に確認した。
不明な点は、お互いに「これってどういういみなんだろうね？」とかやりながら実施。
手順は大きく
キックオフミーティング
ユーザの募集
課題設計
プロトタイプの作成とウォークスルー
ユーザビリティテストと改良の繰り返し
問題点とアクションプランの優先順位付け
結果の通知
と分かれるそうだ。
とりあえず、その手順に沿ってやってみることとなった。
１．キックオフミーティング
作業手順は以下のように分かれる
目標、リスク、考慮事項について話し合う
ユーザーのプロフィールについて同意を得る
コアチームを組む
スケジュールを立てる
所要時間３時間となっている。
うーーん・・・ できたのは、コアチームを組むところだけ。最初からこの3人がコアチーム。
本当にキックオフでボールを蹴り出しただけになってしまった。
コアチームを組む前の手順ってなんだ？
なぜこんな順序で書かれている？
なんで、これらがコアチームを組むより前にあるんだろうか？
というところでお昼休みにした。
さておいしいご飯を食べて帰ってきてから、気を取り直して、一つ一つ確認していくことになった。
おそらく正しい手順は、こうなのだろう。チームが集まって、顔見せし、そこで、目標についてや、想定ユーザー、スケジュールなどを話し合う。当たり前な気がする。本の記述順に踊らされたかもしれない。
目標、リスク、考慮事項について
今回の目標は、ペーパープロトタイプの実施自体と、jQueryチームの公開用サイトのインターフェース仕様作成だ。
リスク、考慮事項については、
更新がしやすいサイトであること（jQueryライブラリのバージョン変更があるため）
別のサイトとの差別化（とほほのように、ブランディング？したいよね）
ユーザープロフィール作成
今回に関しては、自分たちも含めて、周囲にごろごろしている技術者をモデルにすればよいので、簡単簡単。
そして、顔見知りなだけに、いつでも想定ユーザーを呼ぶことができる。
２．ユーザーの募集はそこらへんにいてくれるので、特に行わない。課題図書によると、社外ユーザーにお願いする際には、
募集要項など決めて、報酬なんかも考えてやるとのこと。
３．課題設計
課題設計？？なぜだろうか？これだけの材料では課題の設計ができないことに気がつく。
そう、メンバー間で、大まかなサイトイメージが共有できてないことに違和感をかんじたのだ。
そこで、先ほど作成したユーザープロフィールを元に、サイト構成のイメージを共有する。
コピー用紙を利用して、お互いイメージを出し合って、大まかなイメージを合わせた。
これなしで課題設計が行えるのは既存のサイトがある場合だよね、と満場一致。
課題に関しては、Excelでフォーマットをつくり、書き込んでいく。サイトの目的がシンプルなので、思った以上に課題が少なく感じる。「ユーザーに対する指示」を最後に作成して帰宅した。
第２週目の成果
キックオフの前にユーザープロフィール作成、目標、リスク、課題の洗い出しなんてできない。コアメンバーを決めてから話し合うこと
新規サイトは、課題設計の前にサイトイメージのたたき台を一度、共有しておこう。
ユーザープロフィールシート（ペルソナはペルソナで興味深い）と課題シート
Posted in PaperPrototyping | No Comments »
金曜日, 2月 29th, 2008
数多くある研究テーマの中で、ペーパープロトタイピングをやることになったのは、3名（うちリーダー1名）です。
キックオフということで、ペーパープロトタイピングについて、リーダーにざっくり説明してもらいました。
そして、その後、各自でGoogle先生に、ペーパープロトタイピングについてお聞きすることになりました。
調べた結果
ペーパープロトタイピングならば、初期段階のデザイン・アイディアのユーザーテストが非常に安価に実施できる。これによってユーザビリティ問題が修正できるので、使えないものを実装してお金を無駄にすることがなくなる。
使用されない理由
シンプルすぎて信用できない
手を抜いているような気分になる
使用すべき理由
デザイン上で必要な変更点を早期に発見できるため、プロジェクト全体での変更による費用発生が極小に抑えられる。
完成度が低いので、ユーザーも気軽に意見が言える⇒フィードバックが多く得られる効果がある。
と、かの有名なウェブ・ユーザビリティの大家、ヤコブ・ニールセンがおっしゃられていました。
その他多数の記事を調べ、とりあえず、必要なものを買いにいくことになりました。
久しぶりに訪れる文房具屋にどきどきしながら、購入したものは
画用紙 八つ切 ２０枚
サインペン（黒、青、赤）
はがせるテープ（今はそんなものがあるんですね）
足りないものは会社から借りることにしました。
さて、今回、ペーパープロトタイピングを行う対象についてですが、
jQueryを研究しているチームが作成しようとしている、jQuery説明サイトとなりました。
参考にする予定の書籍が手元になかったので、とりあえず、ヒアリングを行うことに。
ヒアリング中に「wikiっぽいサイト」という言葉で語られ、これがインタビュアーたちの
イメージを束縛することになってしまった。聞き手はゼロベースで聞かなければならないのに、
語り手の言葉に流されてしまった。なかなか、要望の本質的な部分を聞き出すのも難しいものです。
最後に、残り時間で、想定されるユーザー像とユースケースを想定。ペルソナとか手法は
あるようですが、今回は、ペーパープロトタイピングが主題なので、思うがままに、意見を
出し合って、終了した。
第１週目の成果
足りない物の準備
メリット整理
課題図書決定（「ペーパープロトタイピング - 最適なインターフェースを効率よくデザインする」 オーム社 ISBN4-274-06566-9 税別3200円）
ヒアリングでは、語り手のイメージは聞き流せ。一通り語ってもらってから、本質的なところを聞きなおせ
Posted in PaperPrototyping | No Comments »
金曜日, 2月 29th, 2008
会社内の技術研究の機会（週１日）で、Paper Prototyping(以下、ペーパープロトタイピング）の検証機会の時間をいただきました。
ペーパープロトタイピングは、その名のとおり、試作品を紙で作ってしまおうという方法です。Webサイトだけでなく、あらゆる（ちょっと言いすぎ？）ものづくりの場面で知恵と工夫しだいで適用可能な手法です。
メリットは、
本物により近い試作を作成するよりは、時間がかからない。
本物により近い試作を作成するよりは、安価である。
本物により近い試作よりは、やり直しが簡単である。
本物により近い試作を作っている間に、ユーザビリティのテストができる。
（人にもよるが）なにより、作っていて楽しい時間が過ごせる。
という面があります。
今後、このPaper Prototypingの検証結果を、順を追って、書き綴っていこうと思います。
Posted in PaperPrototyping | No Comments »
