たまには方法論的なトピックです。これまで多くの得意先の受注案件や自社サービスのRIA案件のユーザーインターフェース開発を担当させて頂きましたが、RIAxDNPチームがUIデザインを行う上で、気を付けている／気を付けたいポイントを１０コまとめてみました。
（01）実現したい目標、目的の「その先」を把握する
（02）最初は手書きのスケッチから始める
（03）UIデザインパターンを利用する
（04）一度ルールを決めたら一貫性を保つ
（05）全てのことに意味を考える
（06）技術的な裏付けをもつ
（07）最終的な判断は発注者に委ねる
（08）UI設計上の議論の中で「UI系ワード」を使わない
（09）シンプル＆スモールからフィードバックを得て改善する
（10）ある程度の妥協を許容する
UI設計の参考書やUIコンサル系のWebサイトに書いてあるようなことではなくて、ノウハウというより自分たちへの心構えという意味合いが強い感じです。
（01）実現したい目標、目的の「その先」を把握する
開発するシステムによって「データ入力効率が１０％向上した」、「コンバージョンが20%上がった」といった「目標・効果」のKPIは開発案件で設定されることがあるかと思います。
それも大事なのですが、もう一歩踏み込んで「効率化した時間を何に活かすのか？」「ユーザーがそのサービスをもう一度使いたいと思うには？」といった内容をステークホルダーで議論すると、UIにもうひと工夫できるし、「価値」が生まれるかなと思っています。
ちなみに案件によってはペルソナも用意しますが、マーケティングリサーチのためのペルソナでなく、ユーザーターゲットのためのペルソナとして妥当な範囲に留める様にしています。
（02）最初は手書きのスケッチから始める
いきなりPowerPointやPhotoshopを使ってUI検討のためのワイヤーフレームを作るのではなく、まずは紙とペンでフリーハンドでプランニングするようにしています。
最初からアプリケーションを使うと、「見栄え良くする」「綺麗にそろえる」とかに時間を費やし、なんだかドキュメント化することが目的になるからです。
そうなると、バリエーションを考えることが疎かになったり、修正が億劫になったりという自体になったりします。
手書きのスケッチからすぐモックアップ、それがマスターになれば画面設計書さえ不要なこともあります（現実的には仕様書で発注者に確認…というケースが多いですが）。
（03）UIデザインパターンを利用する
およその業務系RIA案件では、UIデザインパターンの組み合わせでこなせる案件がほとんどだと思います。
新たに「革新的なUIを発明」する必要はありませんし、「素晴らしいエクスペリエンス」を印象付ける必要もありません。なので優れたデザインパターン事例集や、作ろうとするシステムの競合や、自分がよく使っているシステムやサービスのUIから、パターンを「借りて」きて、再構成することで設計できます。
設計上の制約が大きい程（画面が小さいとかフレームワークに則るとか）、設計上の自由度は下がるので、そんなに外さないUIになります。ソシオメディアさんのUIデザインパターンとか、iPhoneならhttp://mobile-patterns.com/を参考にしたりします。
（04）一度ルールを決めたら一貫性を保つ
たくさん機能があったり、いくつも画面（ステート）があるようなシステムでは、全体を通して一貫性を保つのが難しくなってきます。
例えばラベリングでは「選択する」なのか「選択」なのか、ある画面では「テキストフィールド+検索ボタン」だけど、他の画面では「テキストフィールドのみでEnterで実行」とか。
コントロール系、表示系、メニュー系等のゾーニングも徹底する必要があります。
スマートフォンだといくつもの画面に分割してナビゲーションするので、画面数自体は増えていきますが、これらは時間をかけて画面間を見直すことで齟齬を無くしていきます。
（05）全てのことに意味を考える
ゾーニングから、コントロールの配置、各画面間の遷移のためのモーション、配色等のアピアランスをそのように設計した意味や理由があるようにすることが必要です。
その意味や理由はエンドユーザーがシステムを使うときの潜在的な「メンタルモデル」につながるからです。
（06）技術的な裏付けをもつ
構築するUIが実際の開発コストとスケジュールの中で実現できそうなのかを見極めることは言うまでもなく重要です。
UI設計のスキルを磨くだけでなく、自分が実装したらどこが大変そうか、この表現を実現するためのUIコンポーネントやAPIはあるか、日頃から開発してノウハウを溜めておくことが大事です。
特にRIA技術（FlashやSilverlight、HTML5のAPI等…）は進歩が著しいので、日頃のキャッチアップを怠らない様に（したいです）。
（07）最終的な判断は発注者に委ねる
自分たちが「こうした方が良い」と思う設計が、発注者からしてみれば「こうして欲しい」と言われることは多々あります。
アプリケーションやWebシステムのUIデザインパターンと親和性が高い設計が、発注者の「ビジネス慣習」や「既存システムの慣れ」と反発するような場合です。
もちろん議論を重ねて擦り合わせ、説得を行うのですが、最終的に決めるのはお金を出す発注者だと思います。自分たちはそのUIをずっと使い続けるわけでもないし、また失敗してビジネスに支障が出ても責任を取れないからです（UIのカリスマとかUXコンサルなら違うのかもしれませんが…）。
（08）UI設計上の議論の中で「UI系ワード」を使わない
作成したワイヤーフレームや画面設計の議論は大いやるのですが、自分たちが議論するとき、「これは【ユーザビリティ】が悪い」「これは【直感的】じゃない」「これは【アフォーダンス】が悪い」という「UI系ワード」を使うのは避けたいと思っています。
これらの言葉の背景として具体的にどういうことなのか、「言い換え」が必要です。「直感的かどうか」は、そのUIデザインパターンを過去に経験しているかどうかであり、またアフォーダンスという知覚能力を引き出すUIは、ディスプレイ上の「画面」では滅多に無いと思います。（プロダクト系やユーザーが低年齢とかは別かもしれません。）
（09）シンプル＆スモールからフィードバックを得て改善する
手書き→ワイヤーフレーム→モックアップ→プロトタイプ→ベータ→リリース、というフェーズ毎にステークホルダーから様々な意見をもらって改良していき、さらにリリース後にエンドユーザーの意見を聞いたり、滞りを観察して完成度を高めていく、というのはやられることだと思います。
しかし要件定義時から多機能にしたり、多くのアクターやユースケースをカバーしようとしたりして、結局余り使われなかったというのもよくありがちです。
本当に提供したい機能をシンプル＆スモールな仕様で試してみて、イテレーションで拡充を図る方がスマートだと思います（UIの話じゃないかもしれませんね）。
（10）ある程度の妥協を許容する
「唯一最善のUIは無い」ですよね。あらゆるユーザーが一度もタスクを間違えずに使えたり、初めて使うユーザーが最初から使いこなせたり…。
感覚的に７０％〜８０％のテストユーザーで大きな問題が無かったら、先ずリリースして後から改良を重ねていいと思います。非常にレアケースだと考えられるタスクフローと、本質的かつメインとなるタスクフローとは優先度を切り分け、メリハリつけたUIを構成する必要があります。
他にも気をつける点はあると思いますが、区切りがいいので１０コにまとめてみました。今後もアップデートしていければと思います。
我々は優れたUIデザインをウリにしているわけではなく、UXコンサルタントというのもいません（なれればいいですが）。
いない場合は経験豊富な「UIコンサルタント」や「UXデザイナー」を雇ってプロジェクトに参加してもらえれば良いですが、そんな予算に潤沢な案件にはなかなか恵まれることはなかなかありません。
我々もエンジニアの延長で如何に望ましいUIデザインができるか、日々勉強と経験していかなくてはと思っております。