ユーザーリサーチでビジネス価値を高める

ユーザーリサーチがアプリ設計に役立つ理由

ユーザーリサーチによって、KPIを絞り込み、アプリの要件に優先順位をつけ、特定のプロセス用にカスタマイズされた直感的なアプリを構築することができます。

ユーザーリサーチでは、物理的に現場に降りて、アプリのエンドユーザー（オペレーター）を観察し、インタビューします。現場の活動を調査・理解せずに設計すると、思い込みが生じます。ナビゲーションボタンを備えたアプリの開発に時間を費やしているうちに、オペレーターが作業の大半で手袋を着用しており、タッチスクリーンを使えないことに気づいたとしよう。事前のリサーチがあれば、フットペダルやバーコードスキャナー、あるいはナビゲーションを自動化する他の方法を使う決断ができたはずだ。

オペレーターが必要なデータやボタンの位置を理解するのに苦労し、1画面あたり数秒を無駄にすることは、長期的には莫大な生産コストにつながる：

:::(Error)1 hour a day of inefficiency x 200 operators = 25 Full Time Employees' worth of work wasted every year.
:::

ユーザー・リサーチの実施方法

{高さ="" 幅=""｝

ユーザーリサーチは通常、ディスカバリーリサーチと ユーザビリティテストの2種類に大別される。アプリのデザインは、アジャイルで反復的なプロセスです。ニーズ分析と最初の発見インタビューから始まり、生産プロセスとオペレーターのタスクフローを知ることで、現場の状況を正確にモデル化したアプリを構築することができます。

アプリが設計され、構築され、公開された後、ユーザビリティテストがアプリの機能を評価し、修正の機会を見つけます。

これら2種類の調査をバランスよく行うことで、オペレーターのニーズを満たし、ワークフローを合理化し、進化する要件に適応するアプリが生まれます。ディスカバリー・インタビューは基礎を固め、ユーザビリティ・テストはデザインの前提を検証し、改善のためのデータに基づく洞察を提供します。

ディスカバリーインタビュー

参加者の募集

理想的には、インタビューには2人必要です。1人は質問し、1人はメモを取ります。また、1人の参加者の回答が他の参加者の回答に影響を与えないようにするため、一度に1人の参加者にインタビューを行うようにします。

覚えておいてください：

1. 何を学ぼうとしているのか、明確な目標を持つ。
2. 参加者は5～7人を目標にする：5人以下ではただの人の意見になり、7人以上ではエコーチェンバーになる。
3. 経験レベルも属性も異なるオペレーターにインタビューする。
4. 質問リストやチェックリストを用意する、メモを取る、スケッチブックを持参する、音声やビデオを録音する機器を持参する。

オペレータのタスクフローを理解する

ディスカバリーの段階でオペレーターを観察しながら、オペレーターにアプリに合わせてワークフローを変更させるような設計ではなく、オペレーターのワークフローを最適化する効果的なアプリを設計するのに役立つ質問をすることをお勧めします。

• 製造活動にはどのような機器が関わっているのか？
• オペレーターは、ハンドオフ、マテリアルフロー、設備の共有など、プロセス全体とどのように相互作用しているのか？

これらの観察から、アクティビティOFDを構築してみてください：

チューリップ・ユニバーシティ{target =_blank}のOFDテンプレートをダウンロードし、構築方法を学びましょう。

物理的空間をマッピングする

物理的OFDを使用して、物理的空間をマッピングし、作業が行われる場所での物理的制約を検討することもできます：

• ソリューションは、どのエリア、場所、セルをカバーするのか？
• オペレータがこのエリアから離れなければならない特定の時間帯があり、その物理的スペースではアプリにアクセスできない、またはアプリの価値が低くなっていませんか？
• オペレーターはどのような機器や機械とやり取りしますか？どのような工具が関係するのか？手袋をしていてタッチスクリーンが使えない場合は？

チューリップ・ユニバーシティ{target =_blank}で、これらのOFDテンプレートをダウンロードして構築する方法を学びましょう。

発見観察の質問

物理的制約* 作業スペースはどのようなものか* 騒音レベルはどの程度か* 作業者はプロセスのどの時点でも手袋を使用しているか* 障害を持つ作業者はいるか

どのような入力が必要であったか？ * どのようなステップを組み合わせることができるか？* ユーザーはどこで摩擦に直面しましたか?(ユーザーはどこで摩擦に直面すべきか?)* 専門的なトレーニングが必要なステップはあったか?

関係者

• プロセスに関与しているのは誰か？
• 検査を行う権限を持つのは誰か？
• 他の人はいつ来るのか？
• 署名は必要か？

ユーザビリティ・テスト

アプリのプロトタイプをテストする

アプリを公開し、フロアにデプロイした後は、ユーザビリティ・テストを実施することをお勧めします。ユーザビリティ・テストは、アプリが使用された直後に開始する必要があります。

有効な結果を得るには、テストプロセス中の中断を制限します。オペレータに独立してアプリを操作してもらいます。混乱、検索の困難さ、過度に長いタスク、または繰り返されるナビゲーションのエラーなどの事例があれば、オペレーターを修正せずに書き留めてください。これらの観察結果はすべて、アプリのセカンドバージョンの設計に反映されます。

中立的で偏りのない質問をする

質問は中立的で偏りのないものにし、オペレーターを誘導するような回答は避けましょう。

• 具体的に："この作業をどのくらいの頻度で行っていますか？"ではなく、"この作業を過去数週間に何回行う必要がありましたか？"と聞いてください。
• 中立的な質問をする："このボタンを押すとここに着きますか？"ではなく、"そのボタンを押すと何が起こると予想しましたか？"と質問する。
• 決めつけないこと："何がイライラさせられましたか "と聞く代わりに、"そのタスクを完了させるのに何が簡単でしたか、それとも難しかったですか "と聞いてください。
• "ナビゲーション・バー "など、インターフェイスの要素に名前を付けず、"画面上部のこのエリア、あれは何ですか？"と言う。
• "もっと教えてください "とか "どんなものか見せてもらえますか？"といった問い合わせで常にフォローアップする。