ボックス版CMSのベンダー（シャベル）が製品のユーザビリティテストを注文したと聞いたことはありません。 主に2つの結論があります。
- これらのシステムの使いやすさなど！ 各企業には、製品開発のすべての段階で開発に参加する独自のユーザビリティスペシャリストがいます-テストの編成、推奨事項の提示、専門家の評価など。 この場合、UDD-ユーザー主導開発です。
- これらのシステムの成人向けの使いやすさは最悪です。 プログラマーは機能を作ります。 設計者が設計を行います。 マーケティングは販売をします。 プログラマーは日食について考えています。 デザイナーはPhotoshopについて考えています。 マーケティング担当者はパワーポイントについて考えています。 まあ、エンドユーザーは定期的に3つすべてを一度に考えます-彼らの知性、性的指向、前肢の成長の場所について。 これがAUDD方法論-アンチユーザー駆動型開発または怒ったユーザー駆動型開発です。
最初のスキームに従って働く会社を知っているなら、私に知らせてください。 私は、2番目のスキームに従ってすべてのことをやる人を十分に見たので、ジェームス・ロバートソンによる「
CMS製品の11のユーザビリティ原則 」の出版物をすべての人に知っておくと便利です。 次に、Jamesが私のコメントで強調している11のCMSユーザビリティ原則のリストを無料でお伝えします。
- 表示されるオプションの最小必要数。 画面には、タスクを完了するためにユーザーがここで必要とする可能性のある要素のみが含まれている必要があります。 システムのインターフェイス全体に共通する要素の数は最小限に抑える必要があります。
- 信頼性とエラー処理。 システムは、ユーザーが使用するデータの安全性を常に確保する必要があります。 例は、自動保存機能です。 「エラー処理」とは、エラーメッセージの明確さとその修正方法だけでなく、ユーザーエラーに対するシステムの一般的な許容範囲も意味します（エラーを修正する方法がわかっている場合は、ユーザーを引っ張らずに自動的に修正する必要があります）。
- タスク指向のインターフェース。 インターフェースのロジックは、システムの仕組みや内部での配置方法からではなく、ユーザーの日常のタスクからの操作方法に基づいている必要があります。 多くのタスクが同じツールセットで解決される場合、開発者は多くの場合、「優雅に」すべてを実行しようとします。 問題は、電子出版のジャーナリストが、独創的に設計されたCMSのビジネスロジックに完全に賛成であることです。 彼は「モジュール」、「情報ブロック」、「オブジェクト」について気にしませんでした-彼は記事を12までに提出する必要があります。
- 実装の詳細の隠蔽。 前の段落3では、システムアーキテクチャからの隠metaを放棄しました。 HTML、JPEG、XML、およびその他の技術的な微妙さと広さはありません-実装の詳細を取り除くために残っています。 ページとフォルダがあります-ファイル、ディレクトリ、インデックス付きのデータベースはありません。
- 直感的なインターフェース。 ユーザーは、自分が今何をしているのか、何をしたのか、それで何ができるのかを理解しなければなりません。 システムインターフェイスは全体的であり、論理的に考えられる必要があります。 ハイデガーの作品を8ポイントで配置することもお勧めしません。 テキストと署名は明確で明確でなければなりません。
- ユーザーのメンタルモデルへの準拠。 ほとんどの場合、精神活動はエネルギーを消費するものであるため、人々は固定観念的に考えます。 すでに実証済みの「フォルダ」、「ページ」、および「バスケット」があるのに、なぜ新しい概念、スキーム、および作業シナリオを課すのか。 ある文で、この原則はスティーブン・クルーグによって根本的に定式化されました：「私に考えさせないでください」。
- 初心者と経験豊富なユーザーの両方にとって便利。 初心者向け-ヒントと視覚化、経験豊富なユーザー向け-ホットキー、ショートカット、および特殊なインターフェイスまで作業効率を向上させるその他の手段。
- インターフェイス設計の効率。 Webインターフェースは、その速度が遅く非同期であるため、伝統的に効率が低下していました。 現在、web-two-zero-yoスタイルのインターフェースは、従来のアプリケーションの効率にすでに近づいています。 効率は、結果を達成するための「画面」間の最小の移動、クリック、および遷移で構成されます。 フォームとコントロールは論理的にグループ化され、ページやタブに散らばってはなりません。 もう1つの重要なポイントは、システムの実際の速度です。 サーバーアプリケーションが長い間考えられていたとしても、これはクライアントインターフェイスが同じようにフリーズする必要があるという意味ではありません。
- インターフェイスのヘルプとヒント。 もちろん、ドキュメント（全文検索！）とトレーニング資料（ビデオ！）が必要です。 状況依存ヘルプを追加することにより、非常に複雑なインターフェースでも理解しやすくなります。 ワンクリックで目的のインターフェイス要素についてすべてを同時に学習できるため、他のすべての参考資料が不要になります。
- システムを操作するための最小トレーニング期間。 上記のすべての原則に従うと、CMSのエントリしきい値を大幅に削減できます。 エンドユーザーが再び座ることを夢見ることはめったにありません。 さらに、ボックス版CMSの開発者はインテグレーターではありません。 彼はトレーニングエンドユーザーではなく、開発者のトレーニングで稼いでいます。
- システムの自給自足。 標準のタスクは、外部のアプリケーションやサービスを使用せずに実行する必要があります。 一般的な例は、写真のプレビューの生成です。 一部のCMSには、公開前に画像を調整および最適化するための組み込みの「グラフィックエディター」が既にあります。 本当に便利です。