web-dev-qa-db-ja.com

プロトタイプで機能しない要素を処理する方法は?

インタラクティブなプロトタイプでは、時間の制約のため、特定のユーザーテストの一部ではないなどの理由で、最終的には機能しない要素が表示される傾向があります。しかし、要素(ボタン、リンク、潜在的に相互作用する)まだユーザーに表示されます。そして、それらが存在するため、一部のユーザーwillは、その要素にまったく対応しないタスクに向けられた場合でも、ある時点で1つをクリックします。

ユーザーが非機能要素を操作しようとしたときに処理する最良の方法は何ですか?

私はいくつかの可能性を考えましたが、それらのいずれかが実行可能かどうか、または私が完全に気付いていないより良い解決策があるかどうかはわかりません。

たとえば、要素(ボタンなど)は表示できますが、ユーザーがクリックしてもまったく反応しません。ユーザーはその時点では何もしないことにすぐに気づくでしょう。

ボタンは、ツールチップや、特定の機能が現時点では使用できないことを示す視覚的なインジケータを表示する可能性があります。

doesが機能するすべてのインタラクティブな要素にホバー状態が含まれていることを確認することもできます。機能しないものはdo n'tにホバー状態があり、彼らが応答しないことをクリックします。

しかし、繰り返しますが、インタラクティブなプロトタイプの非機能要素との不注意なユーザーインタラクションを処理する最良の方法は何ですか?

9
gotohales

ホバー効果の使用の優雅さ(Kontursの回答で説明されているような)が好きですが、ユーザーがクリックしてはいけない領域を特定し、時間の経過とともに実際の成功率が上がるため、これらは調査結果を混乱させます。

実際、私は通常、カーソルの区別がまったく行われないようにして、カーソルが常にポインタまたは常にリンクカーソルになるようにします。調査内で一貫している限り、どちらでもかまいません。これは、ユーザーが次に何をクリックするかを理解しようとしているときに、競争の場を均等にするのに役立ちます。

また、ホバー効果はタッチでは機能しません。したがって、ツールチップが正しくないターゲットをタップしたときにのみ表示される場合を除き、モバイル/タブレットのテストではそれを使用できません。これは実際にすべてのソリューションの答えである可能性があります。誤ったターゲットの上で、そのターゲットを意図的に選択した場合のみ。このソリューションをタッチテストのジェスチャーに使用することもできます。ジェスチャが失敗してプロトタイプを忠実に再現したら、ジェスチャが実行された説明ウィジェットを表示します...

5
Cody Frew

以下のいずれかのようなカーソルは、ホバーしたアイテムがまだ使用できないことを視覚的に示す良いものだと想像できます。

enter image description here または多分 enter image description here

どちらも標準のブラウザスタイルであるため、HTMLベースのプロトタイプに実装するのに必要な作業はほとんどありません。 "feature not available"のような追加のツールチップも役立つかもしれません。

2
kontur

この情報はできる限り目立たないようにして、必要でない限り注意を引いたり、テストセッションやプレゼンテーションを妨害したりしないようにします。ただし、このような場合は、機能を使用できない理由を説明する際に明示する必要があります。

どのように情報を提供しても、最も重要なことはそれを明確にすることですwhy要素は使用できません。ユーザーは、自分が行った(または行っていない)ためではなく、製品自体に不可欠な動作のためではなく、プロトタイプで利用できないために、要素が利用できないことを理解する必要があります。

2
Matt Obee

非機能要素を無効にします: http://www.w3schools.com/tags/att_input_disabled.asp

さらに、要素が再生中でないことを示すために、要素が再生中であるが通常の使用例に従って無効になっていることを色で示すと役立ちますが、一部のブラウザーでは、一部の要素に色のCSSスタイルが影響しない場合があります。おそらく色付きの点線の枠が表示されますが、レイアウトが混乱する可能性があります。

いずれにせよ、アウトオブプレイ要素は、マークアップの外でスクリプトによって管理できます。

1
obelia

プロトタイプに機能が実装されていないことを視覚的に示すべきではありません。代わりに、ユーザーテストモデレーターは、参加者がプロトタイプを使用しており、実際に機能するコードではないという期待を前もって設定する必要があります。したがって、それを操作しようとしてもすべてが機能するとは限りません。これは、実際の作業コードではないため、フィードバックに基づいて変更を行う機会が増えるため、フィードバックは特に貴重であることを参加者に思い出させる良い機会でもあります。

機能するものと機能しないものを視覚的に示しているプロトタイプを使用する場合、参加者はマウスと目でプロトタイプをスキャンし、カーソルが変化するのを探して何をすべきかを理解します。クリックして先に進みます。成功率を人為的に増加させるだけでなく(そして、それが測定しているものである場合、タスクの時間に影響を与える可能性があります)、タスクを完了するためにクリックする必要があると思われる場所についても学習しません。このようなプロトタイプでテストする場合、「なぜそこをクリックしたいのですか?」と尋ねるオプションがあります。または「それは機能しません。それをクリックした場合、どうなると思いますか?」それ以外の場合は、「それは機能しません。別の方法を見つけることができますか?」と簡単に言うことができます。調査のユーザーの大部分が特定の方法でテストしようとしていないタスクを実行しようとしていることがわかった場合は、ユーザーのメンタルモデルとより一致するように設計を再検討する必要がある可能性があります。

1
nadyne