ハートレイルズのサービスでもまだまだ実践できていないものがありますが、以下に私的なデザインの心掛けを列挙します。私にダメ出しを食らわないためのリストでもあるので、私にダメ出しを食らうかもしれない立場にいる方々は参考にしてください。（すげー偉そうですが、実際は全く偉くありません。）
（１） 平易で分かりやすい文章
平易で分かりやすく、できるだけ短い文章を心掛けます。平易さのチェックでは、辞書はもちろん、Google や Yahoo 等の検索エンジンで、その言い回しがどのくらい使用されているか等も参考にします。昨今のゲームが説明書を読まなくても気軽に遊べるように、web サービスも気軽に利用できるのが一番です。ダラダラと長く、難解な説明を前面に押し出したサービスなど私は利用したくありません。
機能上、やむを得ず長い説明を必要とするものもあるかもしれませんが、まず、そうした機能はそもそも必要ないか、あるいは、機能の見せ方に問題があるのではないかと疑ってかかるべきです。そうした熟慮を経てなお必要なものに関しては、例えば、上級者用のオプションとして限定的なユーザーにのみ見せる等、何らかの工夫を施すことを検討します。
（２） 機能の単純化 （複雑化の回避）
まず、そのサービスのコアが何かということを徹底的に固め、コアの充実に集中します。機能は一旦追加するとその削除が容易ではないため、機能の追加に関しては慎重に検討します。また、機能を追加する際には他の機能との関係、重要度を考慮し、適切な場所に追加します。こうした重み付けを行わずに複数の機能を並列に扱うことは、ユーザーの混乱の元となる可能性があり、場合によっては愚の骨頂です。
なお、実装すべき機能の取捨選択に関しては、コアに深く関連する機能以外は全て他のサービスとの連携に委ねても良い、くらいの心積りでいた方が無難です。とりわけウチのようなベンチャー企業では、何もかも自社開発しようとすると破綻します。livedoor が Gmail を採用したのは個人的には良い例だと思いますが、より良い代替手段が既に存在している場合、コアの範疇にない機能を一から開発するのは全くお勧めできません。
（３） 画面遷移、入力項目の適正化
必要のない画面遷移、入力項目は極力排除します。入力項目が多岐に渡る場合はできるだけ必須項目を減らし、また、入力補完等のユーザビリティに配慮します。
（４） 標準への準拠
独自性を持ち込まなくても解決できることに独自性を持ち込むのは、一部の例外を除いてユーザーの混乱の元にしかなりません。スタンドアロンな GUI のデザインでも同様ですが、なるべく標準の UI コンポーネントを組み合わせてサービスを構築すべきです。ユーザーが蓄積してきた経験をスムーズに適用できる UI になっているかどうか、ユーザビリティテスト等を通じて定期的に検証していく必要があります。
（５） 最速のレスポンス
レスポンスが遅いことは、そのサービスが利用されない致命的な要因になります。
（６） 広がりの重視
ブログパーツや API 等、広がりを加速させ得るものに関しては予め準備しておきます。特に、きちんとした API を定義し各機能を独立、疎結合させることは、仮にその API を公開しなくても様々な面から有用に働きます。
以上、他にもたくさんあるのですが、書くのが面倒になってきたので今日はここまで。気が向いたら後日加筆修正するかもしれません。
