業務システムでのユーザーインタビューをより良くするために意識していること

電通総研 UXデザインセンターのしぶやです。

電通総研は多種多様な業務システムの開発に携わっており、要件定義時にUXリサーチとしてユーザーインタビューを行うことも多いです。

並行して行う業務要件定義でのヒアリングや、BtoCでのユーザーインタビューと比較すると、「業務システムのユーザーインタビュー」でこそ特に意識することがあります。今日はその一部をご紹介します。

ユーザーの使う言葉を事前に徹底理解する

電通総研の開発するシステムは製造や会計業務など専門性の高い領域のものが多い中、私たちUXデザインセンターは各案件にスポットで参加するため、毎度業務知識のない状態から始まります。

業務知識を知らない状態でインタビューに挑むと「そこから説明しないとならんのか」と煙たがられるし、質問もインタビュー設計もままなりません。

エンドユーザーへのインタビュー前に、以下のような方法で事前の理解を徹底しています。

• 関連する業務資料や書籍、担当者へのインタビュー記事などを読み込む

• 社内の開発メンバーやコンサル、顧客の開発担当者にインタビューして感触を掴む

• 用語集を作り、正式名称や略称も含めて言葉の意味を理解する

ちなみに開発者の作った要件定義資料だと開発独自の言葉が混ざるため、最初に見ないよう気をつけています。

エンドユーザーに話を聞ける貴重な時間を最大限活かせるよう、あらゆる手段を用いて準備しています。

業務ヒアリングでは拾わない細かな情報項目や優先度を拾う

ユーザーインタビューではユーザー視点での課題・ニーズ・使い勝手に目線を当てる一方、業務ヒアリングは業務や課題の全体網羅が主目的で、立ち位置が異なります。

業務ヒアリングだけをインプットにすると、情報の優先度まで聞き切れてなく、後続フェーズで業務マニュアルや既存画面をベースに画面整理する形になりがちです。

そのまま進むとユーザー視点の情報の強弱が見えず、「確かに必要な情報は揃っているが、なんだか使いにくい」画面を生む要因になってしまいます。

後の画面設計で困らないよう、インタビューで業務の流れ・特に気をつけること・システム利用時の工夫などを深掘り、ユーザーが本当に見ているものの詳細を知ることで、情報設計に必要なインプットを獲得していきます。

一方ユーザーからすると「要件定義ヒアリングで答えたことをまた聞かれてるな」と思われかねないので、
・目的や違いをしっかり伝える
・同じテーマならまとめて行う
など、全体の進め方も含めて工夫しています。

自分でなく、チームが分かっていないことを事前整理する

事前準備を経て「ユーザーに聞かないと分からなそうだ」と判断したことが、業務に詳しいプロジェクトメンバーの暗黙知として眠っていることも多々あります。

そのため「この情報は何のために確認する？」「特に知りたい情報は何か？」などユーザーに聞きたいことを、まずはチーム内で確認して、チームで分かっていること・分かっていないことを整理します。

そうすることで、ユーザーインタビューの結果がチームとしての新たな知見になることをお互いに確認し、ひいてはプロジェクト全体にとって有益だとメンバーにも感じてもらい、共に改善案を考える味方として巻き込めるよう心がけています。

時にインタビューが「既知の情報をデザイナーにインプットする場」と誤解され、新たな情報を得られないまま「あとはデザイナーがいい感じにしてくれる」と思われるケースもあります。そうならないよう、目的や期待値の前捌きも気を抜かずに進めています。

おわりに

まとめ

「業務システムのユーザーインタビュー」を軸に、リサーチの効果を最大化して、結果がプロジェクト内で広く活かされるよう意識していることをいくつか書き出してみました。
改めて整理すると、業務システムに限らずどんな場面でも大切な内容でもありますね。何かの参考になれば嬉しいです。

ちなみに業務システムでのインタビューの進め方全体像は、クラウドワークスさんのnoteや、ベイジさんのブログがとても詳しいです。興味のある方はぜひ読んでみてください。

それでは！！

Written by しぶたく
1歳児を育てながらUXリサーチや組織デザインに取り組んでいます。