ユーザビリティの第一人者で「Usability Engineering」(邦題「ユーザビリティエンジニアリング原論」) の著者であるJakob Nielsen氏(リンク)が、アジャイル手法がユーザビリティをデザインする従来のアプローチを脅かすことに懸念を示している。彼が言うには、ユーザビリティに対するアジャイルのもっとも大きな脅威は、それがプログラマによって提案された手法であり、主にシステム開発の実装サイドに取り組んでいることである。Alistair Cockburn氏(リンク)がこの主張は事実ではないと反論する。
- 良いアイデアを誰が提案したかは問題ではありません。問題なのはアイデアが良いかどうかだけです。
- これは、協力する「私たちプラス彼ら」の代わりに、コミュニティの中で対立した「私たち対彼ら」を作り出します。
- Nielsen氏の名前で挙げられた他のスレッドとは違って、彼は解決策を提供していません。そのため、「私たち対彼ら」の未解決の問題を私たちに残しています。これは、受け入れられません。
提案された解決策: ただ良いアイデアを使うだけです。どこから来たのか気にする必要はありません。Kurt Morris氏がアジャイルユーザビリティリストに投稿した通り(リンク),、「一旦、『私たち対彼ら』という不自然な考え方をやり過ごすと、成し遂げられることは驚くべきものになります。」
Nielsen氏は、続けて問題を提起した。ストーリーを小さなタスクに分けていくアジャイルの習慣は、ユーザエクスペリエンス全体を分かりにくくするおそれがある。それは、機能が一貫性のないやり方で開発されるからだ。彼が言うには、最も悪いのは「ユーザインタフェースがつぎはぎだらけになってしまう」ことである。Nielsenの解決策は以下の通りである。
- ユーザビリティテストを速く繰り返し行う。彼は言う。「毎週のテストは完全に実現可能です(リンク)。それは、もっとも短いスプリント内でさえ、複数のユーザのフィードバックを統合する確実な方法になります。」
- 平行トラックによって、開発作業の一歩先にユーザビリティの作業を終えることができる。
- (紙などの)あまり厳密ではないプロトタイプを使う。それによって、コーディングのために前もって使う時間を最小限に抑える必要がない。
Jeff Patton氏(リンク)は、12個のユーザビリティのベストプラクティス (Nielsenのものもいくつか挙げて) を書き出した。
- 機動力になります。UX実践者は、顧客やプロダクトオーナーチームの一部です。
- 事前に調査して、モデルを作り、設計します。しかし、ほぼ十分な分だけでかまいません。
- 設計作業を細かく分けます。
- 平行トラック開発を使い、早く作業を終え、後に続きます。
- 複雑なエンジニアリングのストーリーに設計時間を使います。
- 継続的なユーザ検証を使うため、ユーザ検証グループを育てます。
- 開発とは別のトラックで継続的ユーザ調査をスケジュールします。
- 複数のアクティビティでユーザの時間を活用します。
- 開発の前にUIを繰り返すためにRITEを使います。
- あまり厳密でないプロトタイプを作成します。
- プロトタイプを仕様として扱います。
- 設計のファシリテータになります。
Jeff氏が述べたRITE(リンク) (pdf) 手法は、MicrosoftのGames Studioから来ている。「RITEは、『従来の』ユーザビリティテストとは異なります。RITEは、非常に速い変化と、これらの変化の有効性を検証することに重点をおきます。」具体的には、問題が見つかってその解決策が分かるとすぐに、実践者はUI (プロトタイプやアプリケーション) に変更を加える。ボタンの名前を変更したり、メニューアイテムのテキストを変更したりする変化は、他の参加者が到着する前によく起こる。もっと複雑な、しかし、明らかな変化はできる限り急速に行われる。このようにすれば、変化はできる限り速くテストすることが可能になる。
その上、Jeff氏は彼の役割が変わったことに気づいている。「アジャイルチームで働き始めると、共同制作の設計を好むように私のアプローチは代わりました。」ますますファシリテータの役を務めるようになり、大きな集団から情報を集め、モデルにします。私は、ユーザシナリオを書き、ユーザインタフェースのデザインをスケッチして、ユーザや開発者のグループで作業をしていることに気づきました。
最後に、Alistair氏(リンク)は言います。(開発者とユーザビリティの分裂に関して) 「ただ覚えていてください。あるのは私たちだけだいうことを」