2012年8月22日水曜日

一人ブレスト サービス価値関数

価値を感じる状況は何か?

いろいろなモノやサービスを使うとき、たいていはそのサービスに価値を感じている。

サービスに価値を認め、対価を支払うのは人間である。
価値があるサービスを提供できれば、対価を支払ってくれる可能性は高い。


ここで着目したいのは、価値は受け手の頭の中に存在する、ということ。
だからあるユーザに対して、サービスの価値を左右する要素としては
  • サービス自体の持つ状態
  • ユーザの持つ状態
の2つを考慮する必要がある。


言い換えれば、価値 はサービスの性質と利用者の性質の関数である。
価値 v = f(x,y) 
ここでx:サービスの状態 y:利用者の状態
という式を考える


いろいろなユーザに対して df/dyを計算してみて、その分散が小さいサービスほど利用者の状態に影響を受けない。
yを年齢や性別と考えれば、万人受けするサービスの検証となるだろう。
yをユーザの利用期間と考えれば、熟練度が変わっても心地良いUXが提供できているサービスとなるだろう。

サービス提供者側ができること

yの定義域に対して、fを最大化させるには、
x = h(y)
のようにユーザの状態に応じて提供するサービスを変化させることが考えられる。

モノであれば、作ったままを届けることしかできないが、Webサービスであればユーザの状態を知ることができるし、それに応じてコンテンツの見せ方を変えることができる。


では、コンテンツの見せ方をユーザの状態をどうやって対応付ければよいのだろうか?
h(y)はどのような写像となるべきか?

普通ならこの部分はクリエイティブな仕事であり、法則化はされていない。
この写像を導出する方法論を確立できれば、いろいろなことがうまく廻るはず。





2012年8月19日日曜日

読書記録 アジャイルユーザビリティ


ユーザビリティテストをアジャイルに行うには?


  • 手を動かしながら考える
  • 上手に失敗する
    • Fast: 手遅れになる前に、“早め”に失敗する
    • Small: 大失敗は致命傷、“小さく”失敗する
    • Often: “何度も”失敗する。(1回の失敗ではすべての問題がわかるとは限らない)
    • Smart: 同じ過ちを繰り返さない。 “賢く”失敗を重ねる。



「使えない」製品が開発されてしまう理由


  • 「開発時にユーザテストを省略」している
  • 「製品が(ほぼ)完成してからテスト」している
なぜ省略もしくは後回しになってしまうのか?
“専門家”にテストを頼むと「高い・遅い・重い」
 = コストがかかるのであれば、あきらめるか、1回で済ませようとする。


ユーザビリティテストはよい製品を開発するための手段。

ユーザビリティテストをしっかり行うことが目的ではない。
よい製品を作るためにテストが貢献できれば、それで十分。

高速で低コストかつ“軽い”手法を使う
= アジャイルユーザビリティ


誰がこの本を読み、ユーザビリティテストを行うべきか

専門家でなくてもよい。プロダクトに関わる人ができる範囲で実施する。
  • プロダクトマネージャ / プロダクトオーナ
  • 開発者 / デザイナー