- 印刷する
ユーザーリサーチがアプリ設計に役立つ理由
ユーザーリサーチによって、KPIを絞り込み、アプリの要件に優先順位をつけ、特定のプロセス用にカスタマイズされた直感的なアプリを構築することができます。
ユーザーリサーチでは、物理的に現場に降りて、アプリのエンドユーザー(オペレーター)を観察し、インタビューします。現場の活動を調査・理解せずに設計すると、思い込みが生じます。ナビゲーションボタンを備えたアプリの開発に時間を費やしているうちに、オペレーターが作業の大半で手袋を着用しており、タッチスクリーンを使えないことに気づいたとしよう。事前のリサーチがあれば、フットペダルやバーコードスキャナー、あるいはナビゲーションを自動化する他の方法を使う決断ができたはずだ。
オペレーターが必要なデータやボタンの位置を理解するのに苦労し、1画面あたり数秒を無駄にすることは、長期的には莫大な生産コストにつながる:
1 hour a day of inefficiency x 200 operators = 毎年、正社員25人分の仕事が無駄になる:
ユーザー・リサーチの実施方法
ユーザーリサーチは通常、ディスカバリーリサーチと ユーザビリティテストの2種類に大別される。アプリのデザインは、アジャイルで反復的なプロセスであり、現場の状況を正確にモデル化したアプリを構築するために、生産プロセスやオペレーターのタスクフローを知るためのニーズ分析と最初の発見インタビューから始まります。
アプリが設計され、構築され、公開された後、ユーザビリティテストがアプリの機能を評価し、修正の機会を見つけます。
これら2種類の調査をバランスよく行うことで、オペレーターのニーズを満たし、ワークフローを合理化し、進化する要件に適応するアプリが生まれます。ディスカバリー・インタビューは基礎を固め、ユーザビリティ・テストはデザインの前提を検証し、改善のためのデータに基づく洞察を提供します。
ディスカバリーインタビュー
参加者の募集
理想的には、インタビューには2人必要です。1人は質問し、1人はメモを取ります。また、1人の参加者の回答が他の参加者の回答に影響を与えないようにするため、一度に1人の参加者にインタビューを行うようにします。
覚えておいてください:
- 何を学ぼうとしているのか、明確な目標を持つ。
- 参加者は5~7人を目標にする:5人以下ではただの人の意見になり、7人以上ではエコーチェンバーになる。
- 経験レベルも属性も異なるオペレーターにインタビューする。
- 質問リストやチェックリストを用意する、メモを取る、スケッチブックを持参する、音声やビデオを録音する機器を持参する。
オペレータのタスクフローを理解する
ディスカバリーの段階でオペレーターを観察しながら、オペレーターにアプリに合わせてワークフローを変更させるような設計ではなく、オペレーターのワークフローを最適化する効果的なアプリを設計するのに役立つ質問をすることをお勧めします。
- 製造活動にはどのような機器が関わっているのか?
- オペレーターは、ハンドオフ、マテリアルフロー、設備の共有など、プロセス全体とどのように相互作用しているのか?
これらの観察から、アクティビティOFDを構築してみてください:
以下のOFDテンプレートをダウンロードして、構築方法を学んでください。 Tulip University{target=_blank
}.
物理的空間のマッピング
物理的OFDでは、物理的空間をマッピングし、作業が行われる場所での物理的制約を検討することも必要です:
- ソリューションの対象となるエリア、場所、セルはどこか?
- オペレータがこのエリアから出なければならない特定の時間帯があり、その物理的スペースではアプリにアクセスできない、またはアプリの価値が低くなっていませんか?
- オペレーターはどのような機器や機械とやり取りしますか?どのような工具が関係するのか?手袋をしていてタッチスクリーンが使えない場合は?
以下のOFDテンプレートをダウンロードして、構築方法を学んでください。 Tulip University{target=_blank
}.
発見観察の質問
物理的な制約* 作業スペースはどのようなものか * 騒音レベルはどの程度か * 作業者は工程のどの時点でも手袋を使用しているか * 障害を持つ作業者はいるか
どのような入力が必要であったか * これらのステップを組み合わせることができるか * どのステップを自動化できるか * 不要なステップはあったか * ユーザーはどこで摩擦に直面したか * どのような入力が必要であったか * どのような入力が必要であったか * これらのステップを組み合わせることができるか * どのステップを自動化できるか * 不要なステップはあったか
* ユーザーはどこで摩擦に直面しましたか?(ユーザーはどこで摩擦に直面すべきか?) * 専門的なトレーニングが必要なステップはあったか? * オペレーターはいつ手作業で書き留めているか?
関係者
- プロセスに関与しているのは誰か?
- 検査を行う権限を持つのは誰か?
- 他の人はいつ来るのか?
- 署名は必要か?
ユーザビリティ・テスト
アプリのプロトタイプをテストする
アプリを公開し、フロアにデプロイした後は、ユーザビリティ・テストを実施することをお勧めします。ユーザビリティ・テストは、アプリが使用された直後に開始する必要があります。
有効な結果を得るには、テストプロセス中の中断を制限します。オペレータに独立してアプリを操作してもらいます。混乱、検索の困難さ、過度に長いタスク、または繰り返されるナビゲーションのエラーなどの事例があれば、オペレーターに修正せずにメモしてください。これらの観察結果はすべて、アプリのセカンドバージョンの設計に反映されます。
中立的で偏りのない質問をする
質問は中立的で偏りのないものにし、オペレーターを誘導するような回答は避けましょう。
- 具体的に:"どのくらいの頻度でこの作業をしますか?"ではなく、"過去数週間に何回この作業をしなければいけませんでしたか?"と聞いてください。
- 中立的な質問をする:"このボタンを押すとここに着きますか?"ではなく、"そのボタンを押すと何が起こると予想しましたか?"と質問する。
- 決めつけないこと:"何がイライラさせられましたか "と聞く代わりに、"そのタスクを完了させるのに何が簡単でしたか、それとも難しかったですか "と聞いてください。
- "ナビゲーション・バー "など、インターフェイスの要素に名前を付けず、"画面上部のこのエリア、あれは何ですか?"と言う。
- "もっと教えてください "とか "どんなものか見せてもらえますか?"といった問い合わせで常にフォローアップする。