UX ガイド (2)

UX ガイド を読んでいて特に興味を引かれたのは「デザイン原則」の項目だ。

機能をデザインするのではなく、エクスペリエンスをデザインする

個々の機能をデザインするのではなく、エクスペリエンスを最初から最後までデザインします。そして、製品全体のエクスペリエンスを通して、デザインするに当たって設定した基準を維持します。
たとえば、プログラムのセットアップが使いにくくてバグが多いものであると、ユーザーはプログラムそのものも使いにくくてバグが多いと考えます。そのように考えるのは当然のことです。

何もしなくても適切に動作するようにする

ユーザーは、さまざまなことを設定したり習得したいのではなく、プログラムを使用したいと思っています。初期設定を選択し、最も一般的で重要なタスクの実行方法を明確にしたら、すぐにプログラムが機能するようにします。

シンプルさには開発者の努力が必要

パワーを維持しながらシンプルさを実現するには、内部をかなり複雑にしなければならないことがよくあります。通常、テクノロジーの設計をすべて公開するソフトウェアをデザインすることは、それを秘密にしているソフトウェアをデザインすることよりも簡単です。<中略>

シンプルさには、すべてを構成可能にする代わりに、厳しいデザインの選択が必要です。多くの場合、複雑なソフトウェアは、使ったことがない機能や理解できないほど複雑な機能に価値があるとするユーザーの誤解から生じています。

ちょっと強引かもしれないけど、上記はプログラミングにおけるデザインに置き換えて読むことができると思う。たとえば、多くの開発者が参加するソフトウェア開発において起こりやすい問題として、ざっと思いつくかぎりでは次のような点が挙げられる。

• 複雑な操作をユーザーに要求している (重複した) コードはないだろうか？
• 気を利かせて追加してみた機能は、本当に誰かが必要としているのだろうか？
• あるシステムを操作するために用意されたラッパーは、どうして存在するのだろうか？

どうすればこれらの問題に対処することができるのだろうか？一つだけ確実に言えることは、UX ガイドでも少し触れられているが、実際の経験から得る必要があるという点に注目したい。