プラットフォームのユーザビリティをどのように比較しますか？
現在、一連のキオスクのユーザビリティ分析を行っており、比較分析段階にあります。問題は、プラットフォームの使いやすさを比較する方法が正確にわからないことです（そのプラットフォームの特定の実装とは対照的です）。これは、SharePoint、Drupal、およびWordpressを比較して、ヒューリスティックなユーザビリティ評価を試みることと似ています。この種のことを行うためのガイドラインはありますか、それとも私たち一人でですか？
使いやすい製品を提供する方法としてプラットフォームの使いやすさを評価したいようです。そのため、2種類の利害関係者と2つの異なる目標セットがあります。開発者としての目標と、ユーザーベースの目標です。 SUS（またはその他のユーザビリティ評価フレームワーク）を使用する場合、それを2回適用し、結果を重み付けする方法を特定する必要があります（おそらくエンドユーザーに有利です）しかしそれはあなたの呼び出しです）。
ユーザビリティ自体は、4つの主要な測定可能な品質で構成されています。
- スピーディー;ユーザーが目標を達成するまでの時間（時間、インタラクションステップの数）-「クリック」が少ないほど良い
- 直感的;手順はどの程度明白か（明示的でよく知られた比喩は優れていますが、目に見える選択肢は少ないほど優れています-ナビゲーションの速度が低下する可能性があります）
- 収容;ユーザーは間違いから段階的に回復できます（元に戻す、元に戻す）
- 邪魔ではなく役立つ。ユーザーはチュートリアルとコンテンツ固有のヘルプまたはガイダンスにアクセスできます。多くの場合、例は参照情報よりも使いやすい
指標に関しては、投資できる労力に応じて、各プラットフォームを測定できる実用的な方法がいくつかあります。
- 特定のユーザビリティー向上開発者またはユーザー機能の存在
- そのプラットフォーム上で特定のアプリの小さな、しかし十分に関連性があり、多様なセットを開発するのに必要な時間
- サンプルユーザーのセットが特定のタスク（学習と操作を含む）を実行するのにかかる時間、およびタスクのバリアント（主に操作）
機能だけでは使いやすさではありません。本質的に主観的なものを測定するのが理想的ですが、実験と一連の客観的な測定が必要になります。
最後に、ユーザビリティの側面としての喜びと満足をお見逃しなく。魅力的で「高忠実度」と「物理的」の比喩はより楽しく、明確なフィードバック（特に明示的な相互作用を必要としない場合）はユーザーの達成感を高めます。
開発者は、純粋な開発の他に、プラットフォームの「メタ」目標をいくつか持っています。そのプラットフォームでのアプリの移植、アップグレード、計測、国際化などのシステムタスクをどれほど簡単に実行できるか。繰り返しになりますが、機能チェックと経験的フィードバックの組み合わせは、一貫した測定に役立ちます。
これらの各プラットフォームのラフなドラフトまたはスケッチをラピッドプロトタイプとして作成し、それぞれの技術的な制限と課題を理解した後、技術ノウハウを使ってブレーンストーミングしてみてください。これらは、それぞれのプラットフォームで何が良い解決策となり得るかを理解するような方法を導き出します。
次に、ポインターをグループ化し、マトリックスまたはリッカートスケールの配置を考案して、比較する必要のあるすべての必須項目をマップします。以前に作成したラピッドプロトタイプを使用すると、比較のための視覚的なイメージになります。人を引き寄せて、デザインでうまく機能しているものを知らせます。これは声に出してプロトコルを考えるのと同じです。これで、マトリックスに意見が記載され、書き留められます。
メリットとデメリットのそれぞれについて調査結果を推測すれば、最適なプラットフォームを選択したり、プラットフォームを実際に比較したりできます。私はあなたにあなた自身の測定可能な目的を選ばせます。
プラットフォームをそのまま正確に扱います-タスクoを達成するためにいくつかの作業を行うアプリケーション。この場合、タスクはシステムの構築ですが、それでもユーザーアプリケーションです。
あなたの開発チームはユーザーです。必要なタスクは、優れた使用可能なアプリケーションを作成することです。プラットフォーム上で評価を行い、この一連のユーザーが必要なタスクをスムーズかつ明確な方法で達成できるかどうかを確認します。
これの一部は-完成度の高い製品を使いやすさの基準を処理するのに十分柔軟にすることができますか？プラットフォームのパフォーマンスは十分/適切ですか？開発チームは、特定のプラットフォームを使用するために多少のトレーニングが必要ですか？
フロントエンドのユーザビリティチェックほど簡単ではありませんが、同じ原則を適用できるはずです。プラットフォームが使用可能なシステムの構築に使用できない場合、エンドシステムは使用できません。