この記事は、 SQA Daysカンファレンスで行われたプレゼンテーションに基づいて作成されました。 この記事は最初にGUI.ruで公開されましたが 、今度はユーザビリティガイドラインについて議論したいと思います。

製品の使いやすさ、高いユーザー品質は、ほとんどのメーカーがほぼ同じ機能を提供する市場で重要な競争上の優位性です。 最も関連性の高い例として、便利で使いやすい携帯電話が最も需要があり、よく売られている携帯電話市場を挙げることができます（これはiPhoneの成功とタッチスクリーンへの移行によるものです）。

ユーザビリティによって何が理解されるべきですか？ 使いやすさの定義は、特定のコンテキストで特定のタスクを達成するために特定のユーザーが製品を使用できる効率、生産性、満足度としてISO 9241-11規格で定義されています。



私たちの生産性と満足度に悪影響を与えるエラーにより、私たちは現実のあらゆる場所で遭遇します。 申請書および問い合わせの不要なフィールドに記入する義務があるかどうか。 いくつかのドキュメントと証明書を提供する必須要件。客観的には必要ありませんが、手順には必要です。 キューや交通渋滞などでアイドル


そのような慣行が、ソフトウェアやWebサイトなど、人が作成するすべてのものに引き継がれるという事実には驚くべきことはありません。 故意に不良システムを作成する人はいないことを理解する必要があります。 最も経験豊富な専門家や大手メーカーでも間違いを犯します。

開発パラダイムの変更

アルバート・アインシュタインは、問題を解決したのは不可能であり、それを生成したシステム内にいると言った。 高いユーザー品質の要求とユーザビリティの実践の使用がソフトウェア生産プロセスの不可欠な部分になるまで、使用することが困難または不可能でさえある製品とウェブサイトが現れるでしょう。

例として、厳密に指定された形式でのみフィールドに入力できるフォームを考えます。 テスト中、このフォームは、最も機密性の高いQAでも疑いを引き起こさない場合があります。 正式には、テストに合格します。形式以外のデータを入力するとエラーが表示され、正しいデータを入力すると合格します。

しかし、このフォームを使用して作業する人にとって、将来はどうでしょうか？ 各フィールドには試行錯誤が繰り返されますが、これはユーザーにとって本当の悪夢です。 これは、非効率的な操作につながります。 プログラム内の残りの画面フォームのこのような実装は、必然的に作業の不便さと自動化の拒否の不満につながります。 そして、これにより、プロジェクト全体が新しいソフトウェアを導入できなくなる可能性があります。 状況を変えるには、開発中に思考のパラダイムを変更する必要があります。エラーの発生を防ぐ方が、エラーを排除する手段に制限するよりも優れています。

UCD（ユーザー中心設計またはユーザー指向設計）アプローチを開発に導入することにより、製品の高いユーザビリティが実現します。 このアプローチは、ユーザー要件の理解とユーザーとテクノロジー間の機能の適切な分散を達成するための開発プロセスへのユーザーの積極的な関与、およびアプローチの反復性とその学際性（ISO 13407）によって特徴付けられます。 ユーザー中心設計の実践により、ビジネス用語（追加利益）とユーザー満足度（製品と開発会社への忠誠心の向上）の両方で、開発コストを削減し、製品の有効性を高めることができます。 このアプローチは、ソフトウェア作成のライフサイクル全体に適用され、要件の定義、分析、設計、テスト、評価、およびその後のインターフェイスの改良が含まれます。 現時点では、欧米（Microsoft、Google）とロシア（ビーライン、RTS、1C）の両方の大企業がUCDプラクティスをプロセスに導入しています。 このアプローチでは、会社に一定レベルの成熟度、明確に定義されたプロセス、およびいくつかの投資（トレーニング、組織経費、スタッフの雇用など）が必要です。

ユーザビリティガイドライン

現実主義者である私は、ロシアのWeb開発者やWebスタジオ、特にベラルーシのほとんどの中小企業にとって、これらの要件が依然として高すぎることを理解しています。 この分野での主なニーズは、プロジェクトと製品に必要なユーザビリティレベルを迅速に（低コストで）決定（設定）し、要件と推奨事項を作成し、その後の評価と分析の基準（メトリック）を設定することです。

製品のユーザー品質を向上させ、従業員の専門レベルを向上させる方法の1つは、ユーザビリティガイドライン（「ユーザビリティガイドライン」、スタイルガイドライン、インターフェイス仕様、ルールなど）を使用することです。

ユーザビリティガイドライン -一般的および個別の両方の特定のインターフェイス要素を適用するためのルールを説明するドキュメント。 ユーザビリティガイドラインへの準拠の形成と検証は、サイトまたはソフトウェアのユーザビリティを向上させる手法であり、そのタスクは典型的であるか、典型的なものに削減できます。 ガイドラインは、一般的な許容レベルの品質を標準化し、提供するためにも使用されます。 ガイドラインには、サイトを開発するときに従うルール（「経験則」、多くの場合経験的に解決されます）が含まれています。 これらのルールは、非常に小さい個々のインターフェース要素と、相互作用の大部分の両方に適用できます。

原則として、ヒューリスティックが定式化されているため、各ルールについて、インターフェイスで「サポートされている」か「壊れている」（チェックリスト）かを判断でき、主観的な評価を回避できます。

長所

この方法には多くの利点があります。

1. 追加費用は必要ありません。
   チェックリストを使用した実装とテストでは、実際のユーザーやUCDメソッドを使用したその他の作業を含むユーザビリティテストのように、追加費用は必要ありません。
2. 実装が簡単。
   ユーザビリティガイドラインを適用するために、既存の開発プロセスを変更したり、高いトレーニングと実装コストを必要としない。
3. すぐに「ワクチン接種」。
   いくつかのプロジェクトの後、ユーザビリティガイドラインが企業標準として採用されると、ガイドラインに記載されているルールが無意識に実行されます（ドキュメントを見ずに）。 これは、いくつかのプロジェクトの後、プログラマーがハンガリーの表記法 （変数の命名規則）について考えるのをやめる方法に似ています。
4. 特定のインターフェイスの問題を示し、解決策を説明します。
   ガイドラインのおかげで、インターフェイスにどのような問題があるかについての具体的な説明と、それらを解決するための明確な指示が得られます。
5. 品質の全体的な「水準」を引き上げます。
   インターフェイスの品質と製品の使いやすさの特定の従業員の仕事の品質への依存が軽減されます。 より早い段階では、誰かがより正確に、間違いを少なくして、誰かが悪い状態にあると言えます。 現在、すべての人がある程度の許容レベルの品質を達成しています。 さらに、このガイドラインは、新入社員のこのレベルの急速な達成に貢献しています。
6. テストに特別な知識は必要ありません。
   チェックリストでのテストには、特別なトレーニングは必要ありません。 リストのテストプロセスはコンプライアンスチェックです。

短所

客観的になるには、いくつかの欠点に言及する価値がありますが、条件付きで欠点と呼ぶことができます。

1. 不完全なコンテンツ。
   各製品には独自の特性があり、多くの場合、独自のインターフェイス要素があります。 ユニバーサルガイドラインの作成は失敗します。
2. ガイドラインは相互作用の問題を解決しません。
   ルールでは、使用のコンテキスト、ユーザーの機能、およびタスクを考慮することはほとんど不可能です。 これらの問題は、それぞれ独自の方法で解決されます。 リストは、重大なエラーがないことのみを保証します。
3. チェックリストを編集するには、ある程度の時間と忍耐、経験、ベストプラクティスの研究、そして使いやすさの知識が必要です。
   このような作業に専門家を参加させることができます。 専門家によるガイドラインの監査は不要ではありません。

内容

私のガイドラインの基礎として、私はVlad Golovachのチェックリストと、研究に基づいたWebデザインとユーザビリティのガイドラインを使用しました。 ガイドラインを作成する際に、私が言及したリストと私のリストの両方を使用できます。 現在、次の要素でグループ化されたルール（ヒューリスティック）が含まれています。

• フォーム
• ボタン
• 入力欄
• リスト
• システムメッセージとエラー処理
• チェックボックスとスイッチ
• テキスト
• 段階的なアクション（マスター）
• キャプチャ

リストには、相互作用の要素全体のルールを追加できます。 たとえば、ステップバイステップアクション（ウィザード）およびキャプチャのルールを追加しました。

いくつかのルールを考慮してください。 例：「1.1必須フィールドは、名前の前にアスタリスクが付いています。 フォームには、必須フィールドの指定に関する説明があります。


このルールが追加されたのは、左から右に読むと、ユーザーが必要なフィールドをすばやく表示してすぐに入力するという仮説のためです。 ただし、ルールには例外があります。 このため、承認フォームの場合、フィールドにはアスタリスクが付いていません。 すべてのフィールドが必須のフォームの場合、それぞれを指定することはできませんが、すべてのフィールドが必須であることを記述する必要があります。 これは、すべてのフィールドの上のフォームの上で行うのが最適です。

または、別のルール：「1.2フィールドの名前は右側に揃えられます。 名前からフィールドまでの距離は、すべてのフィールドで同じです。 この規則は、右揃えがテキストの山を回避することに基づいて推測されます。 また、長距離（配置が左側にある場合）は、フィールド名とフィールド自体の関連付けを大幅に複雑にします。 多くの場合、充填の正確さを数回確認する必要があります


もう1つのルール：「3.3量的特性（長さ、重量、高さ、速度、距離、サイズなど）の入力フィールドでは、測定単位を指定する必要があります。」 ご理解のとおり、この規則により、測定単位が署名されていない場合に生じる混乱を取り除くことができます。

ガイドラインのヒント

1. いずれの場合も、開発中のソフトウェアの詳細と開発ツールの機能を考慮する必要があるため、独自のチェックリストを作成する必要があります。
2. 絶対ルールを作ります。 つまり、ルールに主観的な要件を含めるべきではありません（「ナビゲーションを適切に行う必要がある」など）。 絶対ルールにより、インターフェイスが統一されます。
3. 不一致と不一致のルールを作成します。 インターフェイスソリューションに2つの同等のオプションがある場合、それらのいずれかをルールにします。 これにより、少なくともインターフェースの一貫性が保証されます。
   ユーザビリティテストは世界中で実施されており、その結果、最も人間工学的なソリューションが決定されています。 これらのテストの結果に基づいて、さまざまなオペレーティングシステムでの[OK]ボタンと[キャンセル]ボタンの配置など、意見の相違を解決するための推奨事項が作成されます。 Windows OSのダイアログボックスで「キャンセル」ボタンが右端にある場合（キャンセルアクション）、MacOSでは「OK」ボタンの反対側にあります（アクションを確認します）。 リンクをたどると、これらの研究の 詳細を読むことができます 。 私の意見では、最も重要なことは、2つのボタンを配置する方法の証拠を検索することではなく、この場所がインターフェイスの異なる場所で同じになることを保証することです。
4. 実績のある最高のソリューションをルールとして保管してください。
   その過程で、ユーザーや顧客からフィードバックを得たり、サポートチームがチケットを受け取ったり、競合他社の製品を研究したりすることができます。 そのようなソリューションを実装するには、ガイドラインで説明します。
   記事「 フォームに進むボタンと戻るボタンを配置する 」を読むことをお勧めします

実装

私たちは非常に重要な問題-ワークフローへのガイドラインの導入に注目します。 最初に行うことは、品質とユーザビリティの管理を「感染させる」ことです。 指導者の支持がなければ、最高のアイデアさえ凍結され、終わりには至りません。 ユーザビリティのプラスの貢献について教えてください。 たとえば、ソフトウェア開発の場合、これらは次のとおりです。

• 開発コストを削減
• 開発時間を短縮
• 製品サポートコストの削減
• 製品変換コストを削減

ユーザビリティガイドラインに取り組みます。 プレゼンテーションからのリンクを使用して、おそらく、ガイドラインの最大のコレクションを受け取ります。 それらを学ぶ。 あなたに合ったものを選んでください。

部門長や同僚とルールのリストについて話し合います。 ドキュメントをパブリックドメイン（たとえば、ローカルWiki）に配置します。 誰もが自分に慣れ、議論し、自分の考えを共有する機会を与えましょう。 ガイドラインをひねりましょう。 コミュニケーションの結果に基づいて、調整を行います。 急いで絶対にすべての願いや提案された規則を作らないでください。

次に行うべき最も重要で難しいことは、作成されたドキュメントが内部標準になるようにすることです。 この場合にのみ、体系的な品質改善について話すことができます。 この規格は、会社の顧客価値の創造に関与するすべての従業員を読​​み、順守するために必要です。

バグ追跡システムにユーザビリティカテゴリを作成します。 イノベーションについて同僚に知らせてください。 ユーザビリティのバグは他の皆と同じくらい重要であることを説明します。 たとえば、1C企業では、ユーザビリティバグのみを修正すると、ビルド全体が出てきます。

既存のルールを定期的に確認し、新しいルール（カイゼン）を追加します。 インターフェースの変更とソフトウェアの新しい修正とともに、ガイドラインを変更します。

ソフトウェア開発市場のリーダー向けのガイドライン

ユーザビリティガイドラインを作成および管理している企業には、SAP、Microsoft、Apple、Sun、Oracle、Nokiaなどの有名で大企業があります。

私は、 アラン・クーパーの著書「患者の手の精神科病院」でスタイルガイドに関する最初の視点を取りました。これは、大企業が開発者にスタイルガイドを使用することを意味します。 マイクロソフトとアップルは、インターフェイススタイルのガイドを推進し、その力と利点を称賛しています。一見すると、これらの企業がそのような情報の最も有能なソースであるように思えるかもしれません。 どちらのプラットフォームクリエーターも、製造業者に標準への準拠を強制するために、秘密の形式の強制を使用しています。 スタイルガイドの推奨事項に従わない独立したソフトウェア開発者は、「プラットフォームとの互換性」を宣言できず、マーケティングの観点から重要なプラスを自分の製品から奪います。 したがって、カスタムアプリケーションを作成するほとんどの企業は、プラットフォーム開発者の推奨事項をすぐに使用できます。 それまでの間、プラットフォーム開発者自身が自由に実験し、希望に応じてイノベーションに道を譲ります。 彼らは、後悔することなく、独自のスタイルガイドを無視することができます。

別の観点では、ガイドラインを使用すると、メーカーの製品およびサービスと理想的に互換性のあるインターフェイスを作成し、サードパーティ開発者向けに作成されたPIのエラー数を減らすことができます。

製造元のガイドラインに従うことで、インターフェースの一貫性が保たれます。 たとえば、1C企業がディスクガイドラインを1Cアカウンティングパートナーに転送します。


マイクロソフトは、 ガイドラインで両方の観点を示し、推奨事項に従わなかった場合に何が起こる可能性があるかの例を示しました。

このガイドラインは、 リボンバー （Office 2007ソフトウェアインターフェイスの新しい概念）を作成するための一連のルールとガイドラインを提供します。 たとえば、最も一般的な機能はバーの中央に配置され、周波​​数は左から右に移動します。

テスト中

実例でガイドラインを使用してテストを実演します。



見たインターフェイスには、1つの画面と1つのメッセージウィンドウがあります。 ガイドラインのガイドラインを使用して分析します。


フォームのルールは次のとおりです。「1.2フィールドの名前は右側に揃えられています。 名前からフィールドまでの距離は、観察されるすべてのフィールドで同じです。 原則として、「2.2ボタンのラベルは大文字で始まります。 碑文が複数の単語で構成されている場合、各単語は前置詞を除き大文字で始まります。 しかし、「インターフェイス要素への署名は大文字で始まり、コロンで終わる」は尊重されません。 「パスワードの入力：」および「パスワードの確認：」の署名は小文字で始まり、大文字である必要があります。 ユーザビリティカテゴリのバグ追跡システムにバグを書き込みます。


このメッセージボックスの何が問題になっていますか？ たとえば、「2.8ネガティブアクションのボタン「削除」、「消去」、「キャンセル」）は常に右端にあります」というルールが遵守されています。 ルールについても同じことは言えません。「2.2ボタンのラベルは大文字で始まります。 碑文が複数の単語で構成されている場合、各単語は前置詞を除き大文字で始まります。 [キャンセル]ボタンは小さな文字で書かれていますが、[OK]ボタンの規則が守られています。

オプショナル

• マシュー・リンダーマン著、ジェイソン・フライド（37の信号会社から）「訪問したサイトを作成し、よくある間違いを避ける方法」
• Jeff Johnson のGUI Bloopers 2.0 （on ozon.ru ）
• 記事の著者のユーザビリティガイドライン
• マイクロソフトリボンのガイドライン
• Appleユーザーエクスペリエンス
• インターフェイスチェックリスト（Vladislav Golovach、Alexander Belyshkin、Usethics）