要件定義の段階で重要なUXやUIを規定している問題

かつて受託でWeb開発案件をやっている時に、当然のことであるが要件定義から入っていた。要件定義というのは、お客様が欲しい機能を羅列してもらって開発要件を整理していく作業である。とりあえず夢も含めてほしいものを文章で羅列してもらって、それを元に開発見積もりをし、主に要件リストの文章単位で優先順位付けや取捨選択を行う。

ここではビジュアル前提ではなく文章で要件定義をしてしまっているのがポイントである。

Web開発案件における要件定義書の問題は、この要件を羅列した段階で、ほぼメインのナビゲーションに載せなくてはいけない情報量や、提供できるUXが結構決まってしまうところ。UXと言うとわかりにくいかもしれないが、例えばボタンひとつの単機能しか提供しないサービスと、あれもこれも提供するサービスではユーザーに訴求するポイントも変わるし、わかりやすさ、わかりにくさも変わってくる。結局の所、デザインのしやすさも変わってくる。ボタンひとつのUIにしたければ、要件定義の段階でUXを意識した企画になってなくてはいけない。実質的に要件とUI/UXは不可分であるとも言える。

要件定義主導で作られたWebサービスの要件は、UI設計、UIデザイン工程は、「情報をナビゲーションの中に詰め込むこと」が目的になりやすい。UI/UXマターではなく、要件定義マターでサービスを設計すると、無自覚にUIやUXに制約をもたらせてしまう。

無自覚にこのプロセスを進めてしまうと、あとからどうにもならない状態を作ってしまうことがある。使いやすいWebサービスを考える人は、使いやすさを担保するためのプロダクトコンセプトと、実現しなくてはいけない機能を同時並行にデザインしている。

それに対して、いわゆる要件マターのシステム案件として進んでしまうプロジェクトだと、デザイナーが関わるのは「後工程」であることが多く、後から「素敵なUI/UXをお願い☆」と言ったところで、時すでに遅しということも往々にしてある。要件の定義はすでに済んでしまっているからだ。結果として使いやすいプロダクトになりえないことがあるということは知っておいても損はないだろう。