グーグルはAndroidに「ユーザー体験デザイン(UXD)」を追加開発するようです。機能の開発が終わったあとで、スパイスをふりかけるように。
これまで追求してきた重要な機能に関してはそろそろ一段落した、というのが、チームの今の認識だ、と情報筋は言っている。もちろん、細部の練り上げ磨き上げは今後も続くが。今Googleが求めているのは、携帯電話のメーカーやキャリアが独自のUI...Sense、Motoblur、Ninjablurなどなど...を加えるのをやめさせたいということ。
それらは、シェルのできが良くないし（HTC EVOを見よ）、それにデバイスをのろくしている場合が多い。
Googleは、そういう傾向にストップをかけるために、次のGingerbreadではユーザ体験に開発努力の多くを傾注する。Android体験をiPhoneに近いものにしたい、と彼らは考えている。
グーグルがAndroidを作るのに採用した方法（プロセス）では、システム開発の下流工程（GUI設計作業など）に「ユーザー体験の向上」という作業が含まれているのかもしれません。このプロセスでも、好ましいユーザー体験を実現できるのかもしれませんが、茨の道です。
ユーザー体験デザインはシステム開発に先立つ
もっといい方法があります。上流工程にユーザー体験デザインを位置づけることです：ユーザー体験を機能に先立って考えます。理想的なユーザー体験シナリオを描き、そこに現れるユースケース（システムの使われ方）を洗い出し、それを機能要件に整理することで、システム開発の機能要件を定めます。デザインの成果として機能要件を規定します。
リリース後の改善
ユーザー体験に焦点を合わせた開発プロセスを採用しても、好ましくない結果になることはあります。製品のリリース後に、実際のユーザー行動が予期せぬものになるといったように。
最初からユーザー体験に焦点を合わせていれば、理想と現実のギャップを特定しやすく、それゆえ問題解決も比較的容易です。なお、そのような「実際のユーザー行動にもとづく修正」を正式リリース前に行うために「プロトタイピング」という手法があります。現実のユーザー行動によって直接に検証することで、ユーザー体験デザインの精度を高めるわけです。
ユーザー体験デザイン不在の開発チーム
これに対し、好ましいユーザー体験を事前に考えていなかった場合は、そもそも何が問題なのかを特定するだけでも大変です。問題解決の前に、問題設定について、開発チームの意見が一致しない可能性があります。
リリース後にユーザー体験上の問題が発覚し、開発チームで議論して、そこで初めて認識のズレが明らかになる。じつは個々のメンバーがバラバラのユーザー体験（製品）を思い描いて開発していたというズレ。これを修復するには、実装済み機能の仕様変更や、ロードマップの変更などといった手戻りが発生します。
このような手戻りは、最初からユーザー体験デザインによって機能要件を定めていれば、ずいぶん少なくなるでしょう。
ユーザー体験デザインをとりまく周辺事情
ユーザー体験デザインにはコストがかかります。アップルはiPhoneの開発に数年間（たしか4年ほど）かけたといいます。ハードウェアとOSと主要なアプリケーションをあわせて開発すれば、年単位の時間がかかってしまっても不思議はない。
〔注：とはいえ、ユーザー体験デザインが結果として時間の節約になるような方法を私は提案しますので、クライアントには安心して頂きたく。ユーザー体験デザインはタダではないけれど、それがシステム開発投資のムダを省く点で、けっこう相殺します〕
グーグルはiPhoneへ対抗するためにAndroidのリリースを急いだのでしょう。本稿ではそういった事業戦略全体については論じません。ユーザー体験デザインを後回しにしたツケを払うという過程に限定して、製品開発論の観点で考えました。
まとめ
ユーザー体験デザインは、システム開発の下流工程ではなく、システム開発に先立つ上流工程に位置づけるほうが好ましい。ただし、それを可能にする経営判断、経営環境あってこそ。
関連記事：