業務アプリの改修を承認する前に、何を試すべき？

新しい画面はよさそうに見えます。開発会社が、注文の検索、変更、保存の手順を見せてくれました。開発を進めるために、改修を承認してほしいと言われています。

承認する前に、実際にアプリを使う人に重要な作業を試してもらいましょう。状況と達成してほしい結果を伝え、どう進めるかを見ます。説明を聞く人は、説明する人の案内についていけます。顧客の依頼に対応する人は、自分で必要な操作を見つけなければなりません。

重要な作業から始める

よく行う作業か、間違えると問題になる作業を選びます。例外が対応方法を変えるなら、そのケースも含めましょう。適切な範囲は、アプリと今判断したいことによって変わります。

仮の例を考えてみましょう。注文担当者が、発送前に配送先住所を変更してほしいという顧客の依頼を受けます。担当者は該当する注文を見つけ、住所を直し、変更が反映されたかを確認する必要があります。

架空の顧客情報を使ったサンプル注文を用意します。信頼できる顧客メッセージと、注文を特定するのに必要な情報を担当者に渡します。個人情報や業務情報を保護できない試作品には、実際の情報を入れないでください。

次に、依頼に対応してもらいます。「注文を開き、編集を選んで、保存を押してください」のように手順を指示しないでください。知りたい答えを先に教えてしまいます。

Marieke McCloskeyは、2014年1月12日付のタスクシナリオに関するガイドで、この違いを説明しています。意味のある状況と目標を伝えながら、画面の進み方は教えないという考え方です。

実際に使いそうな人に試してもらう

その仕事をしている人、または担当する可能性が高い人に試してもらいます。注文担当者が注文の修正を行うなら、提案中の画面をすでに知っているマネージャーでは代わりになりません。仕事の違いによって別の疑問が生まれるなら、ほかの役割の人も含めましょう。

仕事に関係する利用条件も合わせます。一日中デスクで働く担当者はキーボードを使うかもしれません。スマートフォンで注文を確認する人は、画面も入力方法も異なります。支援技術を使う人がいる場合は、該当する環境を用意し、試作品が対応できるか確認します。

GOV.UKのモデレーテッドユーザビリティテストのガイドでは、実際のユーザーや想定ユーザーが現実的なタスクに取り組む様子を観察する方法を紹介しています。政府の調査プログラム全体をそのまま取り入れなくても、確認したい業務にこの考え方を適用できます。

担当者がどこを見るか、どこで迷うか、操作を誤るか、情報を見落とすかを観察します。何が起きたと思っているのかも聞きましょう。手助けが必要になったら、いつ、どのように助けたかを記録します。案内を受けて完了した場合と、自力で完了した場合では、分かることが異なります。

「レイアウトが好きです」は、その人の好みを知る手がかりです。「住所を保存したと思ったのに、まだ編集画面でした」なら、調べるべき具体的な問題が分かります。

今度は、注文がすでに配送部門へ渡っていたとします

同じ仮の例で、顧客からの依頼は通常の修正が間に合わないタイミングでした。担当者は注文の現在の状態を理解し、次の対応を判断できるでしょうか。たとえば、マネージャーの承認を得るか、配送部門に連絡する必要があるかもしれません。

まず、次に何をすべきかを自社の業務に合わせて決め、そのうえで担当者に試してもらいます。試作品で対応できるなら、関係する画面や選択肢も含めましょう。結果が明確かを確認します。担当者は住所が変更されたか、ほかの人の対応が必要か、顧客に回答できるかを把握できていますか。

警告を模擬表示すれば、文言が分かりやすいかは確認できます。しかし、実際に動くアプリが権限のない変更を防ぐか、配送部門へ連絡を届けるかまでは証明できません。そうした点は、実際に確かめられる確認に回します。

知りたいことに答えられる試作品を選ぶ

スケッチがあれば、画面に何を載せるか、提案が理にかなっているかを話し合えます。クリックできる試作品なら、注文を探す、画面を移動する、確認メッセージを理解するといったことを試せます。ただし、それらの部分が実装されている場合に限ります。どの部分が動き、どの部分が模擬表示なのかを全員に伝えましょう。

担当者が住所の修正方法を見つけられるか知りたいなら、実際にその手順を試してもらいます。警告が分かりやすいか判断するなら、表示される状況で見せます。画面を使えると思うかを尋ねれば本人の予想が分かります。実際に試す様子を見れば、何をしたかを確認できます。

Katherine Alsopは、2014年8月27日付のGDSにおける試作品活用の記録で、変更されない関係者向けデモと、調査中に変更する試作品との違いを説明しています。また、稼働中のサービスを調査すれば、試作品では分からない応答時間やエラー処理の問題が見つかることも指摘しています。

これは改修を承認するときに大切です。クリックできる「保存しました」という表示で、担当者が結果を理解できるかは試せます。正しいデータが保存されたか、同じ依頼が繰り返された場合も安全に処理されるか、連携先のシステムに変更が届いたかを確認するには、適切な実装チェックが必要です。セキュリティ、実際に適用される権限、速度も、アプリの該当部分を動かして証拠を確かめます。

普段使っている支援技術の環境で試してもらうと、実際の障壁が分かります。ユーザーをアクセシビリティ評価に参加させるW3Cのガイドが説明するように、これはアクセシビリティ基準に照らした評価と合わせて行います。これらのタスクを完了できても、アプリがアクセシビリティ基準を満たす証明にはなりません。試作品が必要な環境に対応できない場合は、その制約を記録し、適切な後日の確認を手配してください。

説明できる判断を持ち帰る

見たことを忘れないうちに記録しましょう。実務に役立つ形でまとめます。

• 誰が何を試したか：参加者の役割、タスク、端末、入力方法、試作品が対応していた範囲。
• 何が起きたか：意図した結果に到達したか、どこで困ったか、どんな助けが必要だったか。観察と原因の推測は分けて記録します。
• 何を直して再度試すか：分かりにくいラベル、不足している情報、不明確な次の手順を具体的に挙げます。修正後、影響する作業をもう一度試してもらいます。
• 実際に動くアプリで確認すること：未解決の疑問、確認する人、確認時期を記録します。この例なら、発送後の住所修正を誰が承認できるか、配送部門へどう知らせるかなどです。

その結果をもとに、試行で裏付けられた方針を承認したり、つまずきがあった部分の修正を求めたり、適切な根拠が得られるまで特定の判断を保留したりできます。改修の部分ごとに異なる対応を選んでもかまいません。注文画面を承認しても、未検証の配送システム連携まで受け入れる必要はありません。

業務アプリの改修を準備しているなら、私たちのデザイン業務を、アプリを使う人、必要な作業、判断にあたっての支援について話し合うきっかけにできます。