UIデザインの基本知識を解説したこれまでの解説とは異なり、今回は手戻りや予算オーバーを防ぐ段取りの教訓について解説します。これまでソシオメディアが経験してきた事例の中で、スムーズにUIデザインのプロジェクトが進まなかった類型的なケースから、3つ取り上げます。

ケースA:機能要件が決まった状態からUIデザインを始める

 多くのプロジェクトでは、ある程度の要件が定義されたうえで、画面設計としてラフな画面イメージを描いて、もっとこうなっていた方がいいね、といろいろ議論しているうちに、若干要件の方に変更を加えていくと思います。

 しかし公共系のシステムなど、あらかじめガチガチに要求仕様が決まっていて、それがRFP(提案依頼書)に厳密に書かれていると、いくら良いデザインを考えついても、仕様と違うという理由で受け入れられない場合があります。

 操作の合理性を考えればこの機能は余計だ、全体がごちゃごちゃするからちょっと隠したい、といったやり取りができればいいですが、たいていはそれが許されないわけです。

 例えば、ユーザー分析や調査をして、こんな機能、ほとんどのユーザーには不要だ、という結論になったとしても、もう引き返せないことが実際にはあります。

 画面をイメージしないで機能を決められても、GUIとして適切に表現できるものとできないものがあります。手書きのラフでも、どんなプロトタイプでもいいので、何か絵にしながらそういうシステムが実現できるかどうかを考えていく必要があります(図1)。要件定義をするプロセスは、できるだけデザインをしながら進めることが重要です。

図1●機能要件が決まった状態からUIデザインを始める
図1●機能要件が決まった状態からUIデザインを始める
[画像のクリックで拡大表示]