「確実にRIAに失敗するための10の方法」というプレゼンで、EffectiveUI社の社長であるAnthony Franco氏は、RIAプロジェクトに失敗したい人に送る10のアドバイスを紹介した。また、SAP AG社のGerd Waloszek氏は、「ひどいユーザインタフェースのための18のゴールデンルール」を書いた。
以下がFranco氏の挙げた10のアンチアドバイスであり、なぜ避けるべきなのか、代わりに何をすべきなのかを説明している。
- 失敗したいのなら、エンドユーザを理解するな。 – ITプロジェクトの70％はユーザの受け入れに失敗する。
- 失敗したいのなら、開発者は優れた設計判断をすると信頼せよ。 開発者は、完了した機能の数によって進捗管理されるため、まずい設計判断をしがちだ。プロジェクトの締切りに遅れそうになると、開発者はエンドユーザのことを考えるのではなく、機能を削ることに注力してしまう。
- 失敗したいのなら、銀の弾丸となる設計を期待せよ。 すばらしいアイデアは大歓迎だが、すばらしい機能だからと言って、すぐれた健全なUI設計を置き替えてはいけない。
- 失敗したいのなら、万人のために作れ。 「会社が万人のための製品を作ろうとすると、結局は誰のためにもならない製品を作るのが落ちだ」
- 失敗したいのなら、ローンチしたら忘れてしまえ。 製品をローンチした後は、さらに洗練して完成させるためのイテレーションが必要だ。
- 失敗したいのなら、成功を定義するな。 成功を定義しなければ、どこに向かって進んでいるのか誰も分からない。
- 失敗したいのなら、衝突を避けよ。 衝突は必ずしも悪ではない。なぜなら「衝突のないところに進歩はない」ためだ。部屋にいる全員がアイデアに同意するときには、待ったをかけるべきだ。
- 失敗したいのなら、人を納得させる必要はないと考えよ。ステークホルダは組織内部を納得させようとすべきであり、単に受け入れられることを期待してはいけない。なぜなら、それはステークホルダからもたらされたものだからだ。そのために、次のような質問に答えられるよう準備しておく必要がある。ROIがどれくらいか、成功とは何なのか、なぜ今なのか、今やらなければどうなるのか？
- 失敗したいのなら、万全を期せ。 最初からすべてを計画しようとすべきではないし、計画されることを期待すべきではない。なぜなら、たぶんそうはならないからだ。
- 失敗したいのなら、製品よりもプロセスを重視せよ。 こう言い換えてもよい。「失敗したいのなら、リスクを冒すな」使っている開発プロセスを重視するのは大いに結構だが、「くだらない製品を期限内に納品することを意味しているわけではない」。反復アプローチを使って、望まれている製品を作る方がずっと簡単だ。
以下がWaloszek氏の18のゴールデンルールであり、従うべきでない否定的な例とともに挙げる。
- 不必要な作業でユーザを忙しくさせよ - ユーザにデータを入力させて、後から、そこにはデータを入力できないことを教えよう。（例えば、休日や週末のデータをユーザに入力させて、後から、その日には働けないことを教えるなど）
- 標準には従うな - メニュー項目を通常あるべきカテゴリや場所に置いてはいけない。（例えば、"Editメニュー"に"Save"を置くなど）
- 遅くしろ - ソフトウェアを遅くするにはほぼ無限の可能性がある。例えば、長時間にわたるチェックやユーザ入力応答でもよい。あるいは、ユーザに対してダイアログボックスを何度も繰り返し出してもよい。
- できる限り略語を使え、特に十分空白があるところでは - "date" の代わりに "dat" を、"Tolerance Key" の代わりに "TolKy" を、"Next Object" の代わりに "NxOb" を。他にもたくさんあるだろう。
- 技術用語でユーザを教育せよ - 常にUTF-8としてURLを送信する(再起動が必要)。（MS Internet Explorerの詳細設定より）
- 重要なよく使われる機能をユーザの目から隠せ - 重要な機能はユーザが思いもよらないメニューに隠せ。
- マウス操作だけにせよ – キーボードショートカットなんて提供するな
- アプリケーションを使うことをチャレンジングなものにせよ - そのアクションが深刻な結果をもたらす恐れがあっても、ユーザに警告してはいけない。
- エンドユーザには近づくな - たくさんのエンドユーザにはたくさんの意見があり、あなたにはあなたの意見がある。あなたの意見を実装する方がずっと簡単ではやい。
- まずい例を広めて、それに従え - このページにあるゴールデンルールのいずれかに従えばよい、それが絶好のスタートになる。
- まずいデフォルト設定になるよう細心の注意を払え。ユーザの期待に反するもの、悲惨なもの、面倒なもの、使えないもの – それを決めるのはあなただ。- 例えば、Webフォームではオプション設定をデフォルトにして、ユーザが望んでいないニュースレターやお知らせができるよう、アドレスをばらまかせよう。
- システム応答後には作業内容を破棄せよ - システムが応答したら、選択されていた画面要素を非選択にしよう（例えば、1往復で）。
- ユーザの生活を楽にする機能を削れ – ユーザには苦労（面倒）をさせよ - ユーザがアイテムをリストに追加するときには、リストの末尾だけにアイテム追加できるようにして、ユーザに正しい位置までアイテムを動かさせよう。つまり、望む場所にアイテムを挿入できるような追加機能を提供してはいけない。ちょっとスパイスを効かせて、ユーザがアイテムを途中まで動かすと、アイテムを末尾に戻すような偽のエラーを入れよう。
- 時間のかかる処理やリソースを必要とする処理をユーザに中断させるな - ユーザの知らないうちに、バックアップやインデックス処理を始めよう。この処理はキャンセル困難、つまり、ユーザのマウスクリックやキー入力を無視するようにしよう。
- 非論理的にせよ - 操作を準備するためだけのボタンをつけて、その操作がすでに行われたとユーザに思い込ませよう。実例を挙げよう。多くのメールアプリケーションでは、転送ボタンでは実際にはメール転送をせず、転送する準備をしているだけだ（なぜなら、まだ受信者を設定したりする必要があるためだ）。
- 時々、システムをクラッシュさせるか、アプリケーションをフリーズさせよ - エディタや編集フィールドを予測不能な頻度でフリーズさせよう。そうすれば、ユーザは作業を頻繁に保存するという、いたずらに貴重なシステムリソースをムダにするような癖がつかなくなる。
- できるだけ頻繁に長時間、ユーザ入力をブロックせよ - ページ読み込みもユーザ入力をブロックするのにふさわしいイベントだ。ユーザはその間、ルームメイトとおしゃべりしたり、新聞を読んだりすることができる。何もない画面を見つめているだけでもいい。
- たとえ不必要であってもユーザ入力をブロックせよ - 画像ブラウザでサムネイル画像を更新しているあいだ、ユーザ入力をブロックするのがよい例だ。– ユーザがスクロールしたり、画像を選択したり、アクションを開始できなきゃいけない絶対的な理由はない。
ほかにも、RIAプロジェクトに失敗するための“役に立つ”アドバイス、いかなる犠牲を払っても避けるべきアドバイスはありますか？