経験デザインとエスノグラフィを語る私的なブログ
<< 2014年夏 フィリピン親子旅行 第5日 アヤラセンター(マニラ) | TOP | シェ・カジモド(高倉二条) >>
UX KYOTO #05 ユーザービリティ評価(タスク設計)
DSC02731.JPG
 UX京都の#05はユーザー評価。
 これから3回連続で、ECサイトの評価を行う。
DSC02735.JPG
 まずはユーザーを特定する。
DSC02737.JPG
 今回はちょっと乱暴だが、私の方で作った条件に合わせて仮説ペルソナを作って貰った。
DSC02738.JPG
 偉かったのは、自分を投影し易い「36才男性エンジニア」とか「28才女性Webデザイナー」にしなかったこと。
 自分が想定しづらいペルソナを作ると、観察力が養われるのでマルだ。w
DSCF2589.JPG
 続いて、ユーザーの行動「タスク」と、その操作「インタラクション」をシナリオ化する。
DSC02740.JPG
 タスクが被験者に渡す課題で、インタラクションが評価者側が手元に持っている答えになる。
 被験者はタスクを読みながら、インタラクションの通りに操作が出来れば成功である。
DSC02754.JPG
 まずは、自分たちで「パイロットテスト」をしてみよう。
DSC02751.JPG
 被験者役は、ペルソナになり切り。
 頭の中に浮かんだことを「思考発話」しながら操作する。
DSC02744.JPG
 思考発話時の滑舌を良くするために、テスト前にタスクを全部声を出して読んでもらった。
 そうしたら、いくつかのチームでは、被験者がそれが課題だと思って。
 それ以降、タスクを見ないで操作だけしてしまうという失敗が起きてしまった。
 そういう課題の出し方をすると、被験者は課題全体を達成すれば良いと考えて、各自が様々な方向からサイト内を移動し始める。
 テストする側としては、タスクに書かれたユーザーのコンテキストに合わせて作業ステップを遷移してくれないと他の被験者との比較が出来なくなってしまうのである。
DSC02757.JPG
 「パイロットテスト」は評価者が作ったタスクで、評価自体が成り立つか試してみるものである。
 なので、本格的に被験者をリクルートして来て行う「実査」の前に問題が見つかって良かったわけやね。w
 早速、滑舌を良くするためには、別の関係の無いものを読んでもらうことにした。
 そういえば、私は評価をスタートする前にYahoo!のTopページを全部読んでもらったりしていたな。ww
DSC02756.JPG
 続いて、ユーザーのコンテキスト通りに操作してもらう為に、タスクの文章を物語形式(シナリオ)ではなく番号を振ったような箇条書きにしてしまうのもNGである。
DSC02759.JPG
 この物語形式のタスク文書のリアルさが、リアルな評価につながるのである。
 そうなると、それは「課題」では無く「答え」になってしまう。w
DSCF2579.JPG
 みなさん、上手く出来るかな。
DSCF2581.JPG
 問題や、やり難い箇所が出てたら、修正しよう。
DSCF2585.JPG
 スムーズに評価が出来るようになったら、次回は被験者をリクルートして来て「実査」に入ります。
DSCF2592.JPG
 ユーザー評価の技術は、次回の「実査」や次々回の「NE比分析」よりも、この「タスク設計」がキモだと思う。
 これが上手くユーザーのコンテキストに合わせて操作できるかどうかで、本当の評価が行える。
 PCサイトの評価でこれが分かってくると、更にユーザーのコンテキストに依存するスマホの評価に繋がってくるのである。

◇面白い記事があったので紹介:文章を「書ける人」と「書けない人」のちがい
◇参加者小澤さん:ユーザータスクとマイレージ

◇UX KYOTO 2014 アーカイブ
07月06日(日):#00ブートキャンプ
11月23日(日):#04カスタマージャーニーマップとRTD
12月13日(土):#05ユーザビリティ評価(タスク設計)
01月18日(日):#06ユーザビリティ評価(実査)
02月15日(日):#07ユーザビリティ評価(NE比分析)
posted by アサノ | 06:12 | 全国UXコミュニティー関連 | comments(0) | trackbacks(0) |
コメント
コメントする










この記事のトラックバックURL
トラックバック機能は終了しました。
トラックバック
Search this site