UX要件定義に関する疑問を解決

先日開催したオンラインセミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」では、セミナー中・終了後とも多くのご質問をいただきました。

多くの方の参考になりそうな良いご質問が多かったので、回答・公開できるものをピックアップしてここでご紹介します。
（なお、ご質問の文言は当社で編集しています）

UX要件と機能要件の関係

回答
いずれもご質問いただいた通りです。UXを実現するための一要素としての機能となるため、UXを上位として考えます。また、機能を先に決めてしまってその制約の中でUXを考えると「解決策の幅が狭くなる」といえます。
まず「ユーザーにとっての価値がなにか」を明確にして「UX要件」を検討したうえで、次に他の要件を肉付けしていくことで、ユーザーにとって価値あるサービスをつくりやすくなると考えています。

UX重視の要件定義にかかる期間

回答
UX要件定義のフェーズだけで考えると、最短で1日で行うことも可能です。しかし、当然ですが検討範囲は狭く、精度は低いものになります。時間を掛ければかけるほど検討範囲が広く、精度が高くなります。
弊社の参画事例の多くはUX要件定義フェーズで3ヶ月程度かけることが多いです。1日で行う場合は、本当の要件定義を行うというよりは「UX要件定義のやり方を体験してみる研修」というような位置付けで行い、その後もお客様側で継続的にUX要件の検討に取り組んでいただくようなかたちが多いです。
スモールスタートするための具体的な工夫をひとつ挙げると、ペルソナの数を絞る（本来複数必要な場合でも最優先のペルソナひとつだけではじめてみる）という方法が考えられます。

既存サービスの改善への適用

回答
既存サービスや製品の改善事例もあります。基本的にはプロセスは変わらず、UX要件の再定義も業務要件の再定義も行います。しかし、どの程度しっかり時間をとってプロセスを回すかは目標とする改善レベルに依存します。
軽微な改善であれば簡易的なプロセスとなりますし、しっかりした改善目標であれば、セミナーでご説明したレベルでのプロセスを回す場合もあります。
また、既存サービスのUI改善のようなプロジェクトであればヒューリスティック評価という簡易的な改善の方法があります。 セミナーでご説明したようなUXデザインプロセスは用いず、専門家の知識や経験則を用いてUIを改善する方法です。

UX要件定義の進め方

回答
ご質問にあるクライアントとは支援先企業のことを指しており、その先に使用者（ユーザー）がいると仮定して回答します。
当社では、UX要件定義はクライアントと一緒に作業しながら進めていきます（ワークショップ形式と呼んでいます）。したがって、何かかたちができた後でクライアントに確認するのではなく、常にクライアントの確認を入れた状態で進めています。別途確認をする必要はありません。
そしてクライントとの仮説が正しいかどうかはワイヤーフレーム作成後にユーザーテストを行うことで検証します。

回答
もちろんさまざまな制約はあると思いますが、ペルソナやインサイトを共有する必要があるメンバーにはできるだけワークショップの場には参加頂いたほうが良いです。
参加できない場合は後で資料だけ渡すのではなく、ワークショップの議論内容を常に共有していく方が良いと考えています。

回答
その段階で分離をする必要はありません。

回答
弊社の定義しているプロセスの「目的の共有」は最上位の施策の目的を共有するということです。そしてその共有した目的はいつでもどこでも見られようにするという工夫をしています。
ご質問にある目的共有の難しさはもしかすると弊社が定義している目的よりも少し下位、もしくは具体的な目的かもしれません。そのレベルの目的はワークショップを通じて共有していくことが有効だと思います。

回答
プロトタイプによるユーザーテストにて判断します。

ペルソナについてのご質問

回答
使用対象者全てのペルソナを定義する必要はありません。戦略的にターゲットとしたいユーザー層など、特別で快適なユーザー体験を与えたいユーザー層についてペルソナを定義します。そして、戦略的にターゲットとしたユーザー層にも優先順位があると思います。その順番に従って定義することが大切です。

ペルソナの数が増えればジャーニーマップも増えるため、すべてを検討するのは現実的ではないケースもあります。ペルソナをいくつつくるのが妥当かという数の基準はありませんが、ペルソナやジャーニーマップづくりにかかるコストと得られる効果を考慮して判断することはできるのではないでしょうか。

ユニバーサルサービスの場合も基本的な考え方は同様です。
身体的な弱者などへの配慮が必要なケースも多いと思いますが、そうしたユーザーが主要層ではない場合はUX要件定義の対象として優先的には考えず、セミナーでご紹介した業務要件定義のプロセスで要件を補完することが良いと思います。

その他のご質問

回答
基本的には計画段階からUX要件について計画しておくべきです。全てのサービスにUX要件が必要かどうか？重要度はどのくらいか？は個別に異なると思いますし、サービスオーナーの思想によっても異なると思います。一般論として、ユーザーのUXへのニーズは高くなっていると思いますので、その市場のニーズをどのように捉えるか、言い換えると経営判断の領域かと思います。

回答
セミナーでは要件定義の結果が仕様書になるという前提でご説明しています。
UX要件、業務要件のプロセスが進んで行くに従い、仕様書はブラッシュアップ・更新されていきます。

回答
基本的な観点、プロセスはセミナーでご紹介したものと同じと考えています。UXデザインはアプリやサービスだけに特化したものではありません。
また多くの場合、WEBサイトやLPは何かのサービスに関連するものであり、そのサービスのUXを構成する一部になっているはずです。ユーザーとそのサービスの複数あるタッチポイントの中で、WEBサイトやLPがどう貢献すればサービス全体での体験をより良いものにできるかを考えるのが大切だといえます。

回答
一般的なデザイナーの仕事よりもかなり幅広い範囲を担当するので、細かいプロセスの理解や、そのプロセスにおけるユーザー体験のヒアリング実施、ファシリテーション能力などが必要であるのが大変なところです。

以上、弊社主催のセミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」でいただいたご質問と回答を紹介しました。皆さまの参考になれば幸いです。

UXデザインのご相談はNCDCへ

これから新しいシステムを企画していく方（発注者となる方）、とくに古いやり方を変革し、よりよりUX/UIデザインを取り入れたシステムを実現したい方にとって、ここで紹介した要件定義の進め方は有効な手法の一つになると思います。

NCDCではUX重視した要件定義から実装まで、ワンストップでサービスを提供しています。
デジタルを活用した新規サービスの企画やアプリの開発はNCDCの得意分野なので、もし課題をお持ちの方がいればぜひご相談ください。

また、最近はさまざまな業務用ツールの内製化に取り組まれている企業も多いようで、自社でシステムの設計をするために、UXデザインの基礎知識を知りたいというご相談も増えています。
今回は要件定義にポイントを絞ってお話しましたが、UX/UIデザインに関するもっと多くの知識をお伝えするための研修などもサービスとして提供しています。
こうした内容を社員研修や内製化プロジェクトの一部として取り入れたい方も、ぜひご相談ください。