私はユーザビリティの専門家ではありませんし、そうなりたいとも思っていません。
製品が適切なユーザビリティを持つように、ユーザー インターフェイスをコーディングするときに従うことができる一連の小さな経験則が欲しいだけです。
最初は、この質問に「常識を働かせてください」と答えるのは簡単だと思っていましたが、私たち開発者の間であまりにも一般的であるとしたら、私たちのグループとして、私たちのひどいインターフェースで評判を得ることはできません.
助言がありますか?
私はユーザビリティの専門家ではありませんし、そうなりたいとも思っていません。
製品が適切なユーザビリティを持つように、ユーザー インターフェイスをコーディングするときに従うことができる一連の小さな経験則が欲しいだけです。
最初は、この質問に「常識を働かせてください」と答えるのは簡単だと思っていましたが、私たち開発者の間であまりにも一般的であるとしたら、私たちのグループとして、私たちのひどいインターフェースで評判を得ることはできません.
助言がありますか?
Steve Krug 著 Don't Make Me Think を読んでください。これは素晴らしい出発点であり、簡単に読むことができます。
編集: これは主に Web の使いやすさのためですが、リッチ クライアントを使用している場合でも読みやすいでしょう。
たった2つのこと、本当に:
If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.
Hope this helps.
実際、誰かが投稿するルールはすべて、 ユーザーに考えさせないでくださいというテーマのバリエーションになります。
"Don't Make Me Think" は既に投稿されています。 日常的なものの設計と Web 標準を使用した設計も参照してください。軽いユーザビリティの読み物としても最適です。
ここにいくつかの簡単なルールがあります:
ユーザーが何かにたどり着くまでにかかるマウス/キーボードのクリック数を考えてみてください。
PS-これについてMicrosoftOffice2008の人々に話さないでください。かわいそうな男たちは今夜寝るために泣きます!:)
私が誰かに与える最も重要なアドバイスは、最初に UI に取り組むことです。ペンと紙とすべて。そうすれば、無意識のうちにボタンを関数に関連付けたり、入力フィールドを変数に関連付けたりすることはありません。
最適な UI をコーディングするのは面倒かもしれません。バックエンド コードの大部分が記述されていると、思考が妨害されます。
それ以外は、Apple の Human Interface Guidelinesを参照してください。もちろん、お使いのプラットフォームが OS X でない場合は、OS X のセクションを多用してください。OS X で動作するものは、Windows では動作しない可能性があります。プラットフォームのイディオムを受け入れる必要があります。
OS X のことはさておき、そのドキュメントには基礎に関するかなり良い出発点がいくつかあります。
モードを避けてください。入力が機能する場合と機能しない場合がある場合や、異なるタイミングで異なることを行う場合、ユーザーはイライラします。
アプリを使用するユーザーについて考えてください。なぜ彼らはそれをどのような文脈で使用しているのですか?
それが始まりです。
Ensoの作成者によるこれらのブログ投稿を読むことをお勧めします。
もちろん、彼らは
The Design of Everyday Things やAbout Faceなどの本からのガイド/アイデア/アドバイスを繰り返しますが、それにもかかわらず、投稿にはかなりの洞察が含まれており、(IMO) 良い読み物です.
(1) 一般的なアクションは、可能な限り少ない労力で済み、明白である必要があります。一方、めったに必要とされないアクションは、多くのステップを必要とし、メニューやダイアログの後ろに隠れることがあります。これを可能にするには、ユースケースをリストして、ユーザーがアプリケーションで何をしたいのかを常に説明する必要があります。
(2) UIは自己文書化する必要があります。ユーザーは個別のマニュアルを読まないため、マニュアルはアプリケーションのダイアログとメニューに統合する必要があります。たとえば、キーボードショートカットは、関連付けられているアクションを表すメニュー項目に表示される必要があります。
パワー ユーザーにキーボード ショートカットを提供する (「Enter キーを押して検索する」という単純なものであっても)
一度に画面に多くのものを表示しないでください。
メッセージボックスをポップアップしても、通常、ユーザーはそれを読むことはありません。
アプリケーションは、ユーザーが対処しなければならない多くのアプリケーションの 1 つになることを忘れないでください。単に違うことをしたり、けいれんしたりするために物事をしないでください。異常なグラフィック、動作、用語、または相互作用を考え出さないでください。標準の OS コントロール、規則、ユーティリティ、および動作を使用します。
アプリを他のアプリと相互運用できるようにします。データの切り取りと貼り付けを許可し、他のアプリが読み取れる形式でデータを保存し、UI を使用する代わりに他のアプリからデータをインポートできるようにします。
デスクトップ アプリを作成している場合は、ユーザーのコンピューターを乗っ取ろうとしないでください。ユーザーのドキュメント フォルダ、タスク バー、およびアプリケーションの設定はそのままにしておきます。コンピューターに既にインストールされているものは変更しないでください。スクリプトまたはコマンド ラインの対話を許可します。
Web アプリを作成している場合は、ブラウザーを乗っ取ろうとしないでください。標準のメニュー バー、履歴、レイアウト、またはフォントを覆そうとしないでください。ユーザーが Javascript を使用してページを変更できるようにします。
ここにあるその他の推奨事項に加えて、UI 規則に慣れるための良い方法として、Jenifer Tidwell による Designing Interfaces をお勧めします。
また、The inmates are running the asylum by Alan Cooperは、インタラクション デザインへのアプローチ方法についての洞察を提供するのに優れています。
Don't Make Me Think の良い続きは、Robert HoekmanのDesigning the Obviousです。Krug のような Web サイトとは対照的に、Web アプリケーションに重点を置いています。