ユーザビリティエンジニアリング　樽本さん著　感想

すずきカレー @suzuki_curry

人間中心設計を段階的に導入していくとき、やりやすいところから初めてしまって良いのだろうか。決まったステップがあるのかな。

すずきカレー @suzuki_curry

10ヒューリスティックス。頻繁に使うユーザ用の近道って、なかなか難しい。ガラケーのaccesskeyも、妥当な割り当て難しい。

すずきカレー @suzuki_curry

クローズドのカードソートでUIのラベリングが最適化どうか調べるのは時間かからないし、使える気がする。

すずきカレー @suzuki_curry

プロトタイプを作るために、いくつかのスキルが必要。今の自分が「プロトタイプ作ってる余裕なんてない」て言うのは、そのスキルがないからだね。

すずきカレー @suzuki_curry

Webサイト。Tプロトタイプの話。用意できないページには全て1枚のhtmlを。「まだ作っていません。もどるボタンで戻ってください」これでユーザ評価が可能になる。

すずきカレー @suzuki_curry

事実(行動)を文書化するにあたって、情報の質と数が一定必要。個人的には、それも「事実だと認知するのに必要な思いこみの質と量」に過ぎない気がするけど、世界はそれをシナリオと呼ぶんだぜ。

すずきカレー @suzuki_curry

エスノグラフィを導入して調査するのは、その人が積み重ねてきた経験や、取得している感覚&スキル、行動の背景など、多層にわたる情報を抽出する必要があるから。

すずきカレー @suzuki_curry

熟練した設計者が、紙で作ったインターフェイスを用意する。そして、最適なユーザを用意できるのなら実用的かも。

すずきカレー @suzuki_curry

「コストかけずに作ったプロトタイプ」は、多くの中小企業にとってすでに十分にコスト高いぜっていうことなのかも。

すずきカレー @suzuki_curry

コストかけずに作ったプロトタイプを、プロトタイプとして機能させるのが大変だと思う。

すずきカレー @suzuki_curry

なんかでもWebサイトの場合、プロトタイプを「リニューアルしましたー」言って、公開することになる気がするけどダメなのかなー。

すずきカレー @suzuki_curry

プロトタイプで失敗したら、シナリオまで戻る。そして、もう一度ユーザーニーズと解決策を考えよう。思い違いがあるかもしれない。可逆的だから学びが多いという話。

すずきカレー @suzuki_curry

ブレストするにも適切なサイズが必要。シナリオ分解すると、適切なサイズがうまいことできあがる。

すずきカレー @suzuki_curry

人間、事実は安心する。

すずきカレー @suzuki_curry

シナリオは工程ごとに分解。ユーザーニーズと解決策を別々に見つけていく。

すずきカレー @suzuki_curry

ユーザーニーズを探してるときに、その解決策まで決めちゃったら、そのステップは行き過ぎよ話。

すずきカレー @suzuki_curry

ユーザーニーズを想定するとき、どうしても作り手の解釈が入ると思うんですけど、それってなんか、そこだけ得意な人にやらせたくなるような。

すずきカレー @suzuki_curry

設計者の考えるタスクは、実際の利用とかけ離れたものになりがちなので、シナリオからタスクを抽出しましょうという話。

すずきカレー @suzuki_curry

シナリオ検証するために再面談かー。コスト高すなー。

すずきカレー @suzuki_curry

シナリオって、星新一のショートショートみたいな文章になる気がする。

すずきカレー @suzuki_curry

ユーザの体験データをどうやって文書化するのか問題。

すずきカレー @suzuki_curry

師匠と弟子形式のインタビュー。専門家だと悟られると関係が逆転しちゃう。

すずきカレー @suzuki_curry

グループインタビューはユーザの体験じゃなく、意見を集めることになってしまうので役立たせるのが難しい。

すずきカレー @suzuki_curry

「ボタンが目立つ」の「目立つ」も、あやうい言葉だなー。レイアウトなのか表示位置なのかラベリングなのか。

すずきカレー @suzuki_curry

ユーザ調査。ユーザが自分の失敗に気づくとは限らない。