アジャイル・ユーザビリティを読んだ。

アジャイル・ユーザビリティを読んだ。以前試しにDIYユーザテストをしたのだが、気づきと疑問点が多すぎて関連書籍を探していたところ教えてもらった。本書はユーザビリティエンジニアリングの関連本。ユーザビリティエンジニアリングがUCD全体について書かれている一方、アジャイル・ユーザビリティはDIYユーザテストにフォーカスしている。 booklog.jp

CHAPTER1から5までは、マーカーだらけになりそうなくらいユーザテスト設計と実践に関するポイントが詰まっている。インタビューガイド例も載っているので、実際に設計する際の参考書としてかなり役立ちそうだった。前半はテスト設計の際に都度読み返すとして、後半のアジャイルにいかにUCDを取り入れるかという話が気になった。

アジャイルとUCD

CHAPTER6に、もともとのアジャイルはインクリメンタル（潮進的）、UCDはイテレーティブ（反復的）なアプローチだとあり、UI設計のフローと開発がやろうとしているスクラムのフローがなかなか合わない理由がなんとなく分かった。

開発とUXデザインを同時に走らせようとしてもうまくいかないので、『UXデザインを少し先行させること』がキモらしい。パラレルトラック法と呼ばれるそう。一個前のイテレーションでUI設計したものを開発の次のイテレーションに回すっぽい。しかし全体のユーザ体験とか画面遷移の食い違いをどこで担保するのかが未だよくわからない(´・ω・｀)

アジャイルUX

著者の樽本さんによる開発プロセスの一例がSlideShareに公開されている。

アジャイルUX物語 from Tarumoto Tetsuya

1.コンセプトをたてる

「誰のために、何を作るのか」を考えるフェーズ
簡易的なリサーチ（観察やインタビュー）を行い、「何か困っていることはないか？」を探る
課題が絞り込まれたらアイデア発想を行う
ストーリーボードやモックアップ、フェイクの製品広告などを使って、ユーザに高い評価を受けるまで調査・発想・検証を繰り返す

2.計画

ユーザ視点で議論を進めるためにペルソナ（プラグマティクペルソナ）を立てる
ユーザストーリーを使って要求定義をする
ユーザストーリーを見積もり（プランニングポーカーを使ったりする）優先順位をつける
製品の全体像を見失わないためにユーザストーリーマップを使う

3.開発

開発チームの進捗状況はタスクボードで管理される
UI設計もイテレーションの中でスケッチボード法を使い開発と並行して進める
レビューの終わったスケッチボードは簡易の画面仕様書になる
複雑な操作が必要な画面に関しては、ペーパープロトを作成して簡易的なユーザテストを行う

4. リリース

ユーザビリティ工学の開拓者ヤコブ・ニールセンの研究によると、５人のユーザにテストすればユーザビリティの8割の問題はは特定できると言われている（ただし、8割見つければ安心ということではない。2割は見つからない上にそこに致命的な問題が含まれる可能性もある）。アジャイルUXではこの5人も"重い"ということで、1人にテストして見つかったUI上の問題をすぐに改修して次のテストにかけるRITEという手法があるらしい。そのためには豊富な経験と見極める目も必要だし、かなりの開発スピードが求められるのでお勧めはしないとあった。

アジャイルは二人三脚に似ている

読後のポエム。今更かもしれないけど「アジャイルは二人三脚に似ている」と、最近思う。これまでの開発はリレー方式で、ワイヤーフレームからデザイン適用済の画面イメージまで、UI設計が固まってから開発に入っていた。各フェーズの担当が早く走れば全体のタイムは短くなるし、逆に遅くなればあとのランナーに響く。UI設計のスキルをうんとあげれば、その区間だけは早くなるかもしれない。じゃあアジャイルにすれば全体が早くなるか？というと、POと開発とUI設計側の意識が揃ってないと逆に足がもつれて全然進めない可能性もある。「右から出すよ！いち！に！いち！に！」誰かの意識が別で、走るのが早くても遅くても転んでしまう。そう考えると、ウォーターフォールより難しく感じる。