他に質問があります。 ユーザビリティとは何ですか？ ユーザビリティを測定するには？ 回答者の結果をテストするだけでなく、価値の判断を「使用可能-使用不可」と検証する方法は？ 開発プロセスのどの時点でユーザビリティフェーズが行われますか？ なぜ私が読んだ最高のユーザビリティの本がこの用語を使用せず、 Webデザインと呼ばれますか？ ここでそれらに答えようとすると同時に、すべてを逆さまにします。 またはその逆。
用語について
ロシア語は概念が豊富です。 それにもかかわらず、私たちは英語の用語を持ち、トレーシングペーパーを作成し、それに苦しんでいます。 たとえば、 デザインとは何ですか？ これは、開発、設計、建設、図面、モデリング、さらには計画およびサンプル製品の開発です。 地球の英語圏の人口は後悔することができます。 しかし、ロシア語で「デザイン」トレーシングペーパーを使用して、この多数の名前をすべて無視する人には、すみません。 使いやすさ、同じ用語のtrap。
この用語をロシア語に翻訳しようとして、「ユーザビリティ」や「ユーザビリティ」など、多くのフリークが生まれました。 これらの用語は、客観的な意味がなく、何も測定されておらず、したがってファッショナブルな用語の周りのミステリーのハローに影響を与えないため、優れています。 ロシア語に長い間、そしてしっかりといる間、「運用上の適合性」や「 運用特性 」などの概念があります。
失望とresみが私の答えになります。 神秘はどこにあり、魔法はどこにありますか？ それについてではありませんか？ 違います。 ユーザビリティとは異なり、製品の動作特性を定量的および定性的に操作することができます。 それを気に、誰もがそれが何であるかを理解しています。 クエリ「運用プロパティ」とクエリ「ユーザビリティ」を発行した結果を比較して、これらの資料を分離する詳細の深ofを理解するだけで十分です。
もちろん、ここでの最大の問題は商業的な性質です。 神秘的な知識は高価です。 はい、正気の大多数は超能力者のサービスを使用していませんが、彼らのサービスはまだ需要があり、市場があります。 だから、ユーザビリティの謎は誰に売るべきかということです。 また、パフォーマンスを改善するための作業は結果によって確認する必要があります。 サイキックサービスとは異なり、顧客が悪いカルマを持っていると誤解される可能性があります。 私はここで何も手伝うことができません、私のサービスの販売に関係する人として、 私は技術ではなく道徳的な選択をします。
アプローチの違い
では、パフォーマンスに基づく開発とはどういう意味ですか？ 私にとって、この意味でのユーザビリティが開発プロセスのイデオロギーであることは明らかです。 これは、品質ベースの開発や知識ベースの開発のように、外部の専門家が着手できる段階ではありません。 開発の各段階で、これは方法やプラクティスでさえなく、特定の目標に合わせて修正されます。
1. 要件を収集する段階で、ユーザーの期待に最大限の注意を払うことを意味します。 アプリケーションの機能飽和度は、ユーザーの目標や目的、それらを達成する方法よりも興味がありません。 関数を追加するというアイデアは、「誰のために」「なぜ」というプロクラスの質問の層を通過します。 必要かつ十分な機能のリストは、システムの運用特性によってのみ決定されます。 可能な限り有用なチェックマークに関するアイデアを顧客に押し付け、製品の対象読者とビジネスの目標の定義を残します。
2.システム設計の段階で、システムとのユーザーインタラクションに焦点を当てます。 良いツールにはボタンが1つあることが知られていますが、理想的なツールにはボタンがありません。 優れたツールは多機能ではありません。 スイスのナイフはナイフのように悪いです。 しかし、本当にスイスのナイフが必要な場合は、爪やすりがマチェーテに合わないことを確認しましょう。 設計されたアプリケーションアーキテクチャの観点からこれが不可能な場合でも、アーキテクチャにとってはさらに悪いことです。
3.システムのグラフィックデザインの開発では、芸術的なインスピレーションの創造的な飛行を、運用プロパティの厳格なフレームワークに制限します。 非常にタイトなフレーム。 車の外観のデザイナーは、自由に創造することを考えないでしょう。 私たちのデザイナーも今やヒットしています。
4. 開発段階では、「このチェックマークはここで要求されましたが、書く時間でした」というカテゴリの開発者のすべての創造的な衝動を抑えます。 「書くのに1か月かかりましたが、ウィンドウを追加することで5分で簡単になりました。」 しかし、可能な限りあらゆる方法で、「聞いてください、私は不快だったでしょう。週末にかけて、このようにすべてをここでやり直しましょう」というカテゴリのアイデアの議論を奨励します。
5. テスト段階では、機能テスト、負荷テスト、その他のテストとともに、パフォーマンステストを実施します。 ユーザーインタラクションに関してシステムが準拠しなければならないメトリックがあります。テストケースはユーザーの目標に基づいています。 「これはバグではなく機能である」という結論のエラーはエラーのままであり、優先度が高くなります。 テスターは、「システムがどのように機能するかを理解していないバカ」になる完全な権利、さらには義務を取得します。
そして、ユーザビリティの場所はどこですか？ この状況で彼は誰ですか？ 製品がインターフェースワイヤフレームである専門家を引き付けるのに必要な運用特性を製品に与えるだけでは十分でないように思われませんか？ チーム内のすべての人が、機能的な役割に関係なく、 使いやすさの精神に満ちていることは否定されます 。
いくつかの結論
ユーザビリティの分かりやすい説明と脱神殿化は時間の問題です。 短い時間。 非常に短い時間。 あなたが「ユーザビリティ」になろうとしているのなら、やらないほうがいい。 特定の仕事を製品指向にする方法に関する知識を得る。 優れたアナリスト、デザイナー、プログラマー、テスター、またはマネージャーになるよう努力してください。 ユーザビリティアーティストではありません。 そのような専門性はなく、そのような考え方や仕事のイデオロギーがあります。 しかし、良い人は職業ではありません。