ソフトウェア製品のUX要件の分類法はありますか？
私はUXの研究者です。私の研究の目的は、UXとIDに関する知識が不十分な場合でも、UX要件に対処するために、ソフトウェアエンジニアリング実践者（要件エンジニアリング）の初期段階を支援することです。すべての開発会社がUXとユーザビリティのエキスパートにアクセスできるわけではありません。
これまでのところ、開業医にとっての課題の1つは、さまざまなソフトウェアに関連すると考えられるUX要件のタイプがわからないことです。そのため、私は私の研究でUX要件のオントロジーまたは分類法を開発する（またはすでにそこにある場合は再利用する）ことを目指しています。次のステップは、それらの要件を引き出す方法とそれらを文書化/表現する方法に関するツール/方法を提供することです。
関連する情報源を知っていますか？有形のUX要件のリストまたはカテゴリはどこにありますか？
私の研究の結果は、やがてすべての人に無料で公開されます。
ユーザーインターフェイスの設計に関するWikipediaのページの 要件セクション から始めるのがよいでしょう。 ISO 9241、特に撤回されて ISO 9241-110：2006 に置き換えられたパート10を指します†
UXの原則 mozillaが キーワードとして使用して、bugzillaのバグにタグを付ける は、Jakob Nielsenの Ten Usability Heuristics に基づいています。
私は最近、mozillaのキーワードをISO 9241のDialogue/Feelの原則にマッピングして、それらがどのように一致するかを確認しようとしています。
- タスクへの適合性
- uX効率
- ux-implementation-level
- ux-jargon
- 自己記述性
- ux-affordance
- ux-discovery
- ux-visual-hierarchy
- ux-minimalism
- ux-userfeedback
- ux-tone
- 制御性
- ux-control
- ux-undo
- ux-interruption
- ux-control
- ユーザーの期待に準拠
- ux-consistency
- ux-mode-error（ux-error-preventionの特殊なケース）
- ux-natural-mapping
- エラー許容値
- ux-error-prevention
- ux-error-recovery
- 個別化への適合性
- 学習への適合性
いつか定義で更新します。
更新：参照 Psychological Usability Heuristics
†ISO 9241-110：2006は22ページですPDFコスト108スイスフラン、約110米ドルまたは70ポンド。それを読んだ人から、購入する価値があります。
私は職業別の開発者でもあります（有名なハードユニからソフトウェアエンジニアリングの修士号を取得しています）が、最近はUXを使用しています。以下は、UXのHCIの観点からの説明です。これは私に教えられたものです。これは私が所属していると私が考える学校です。
一般に、UXはITからそれほど遠くありません。開発者がソフトウェアエンジニアリングで教えているのは「ソフトウェア設計」であり、UMLについては、基本的にUXが今日行っていることです。ソフトウェアの設計は、2000年代の初め、アジャイルブームの影響で90年代の終わりに主流から外れたため、実際にpracticeである人を見つけるのは困難ですが、それらのほとんどそれを聞いた大学で。
UXはソフトウェアエンジニアリングと心理学の恋人です
これを透視してみましょう。簡単な図を描きます。
まだまだたくさんあると思いますが、簡単な説明にはこれで十分です。
「マイクロIT」四半期は空ではありません。それは、世界中のフロントエンド開発者に説明する必要のないものです。
信じられないかもしれませんが、たとえば、分類法はすべてのIT大学で必須の研究であり、オブジェクト指向プログラミングで毎日使用されています。だから、そこには何も新しいものはありません。
開発者を理解する：共通言語
開発者にとっては、フローダイアグラムのような使い慣れたものから始めます。別の Programmers.SEでの回答 で、フロー図といわゆる有限状態機械（これも必要な研究）の関係を説明しました
開発者に何が教えられたかを理解するために、UMLの本 this like 、（吹き替えthe "iconix book"）を読むことを検討してください。
ユースケース分析に関しては、システムがどのように最良の本を振る舞うべきかを一般的に扱っていますが、それでもCockburnの Writing Effective Use Cases です。
プログラマーは分類することを好み、そのほとんどは「レゴ」を好む設計パターンは、開始に適した場所です。設計パターンはアーキテクチャから始まり、ITに移行し、ITからUXに移行しました。現在、デザインパターンはまだITで広く使用されていますが、10年前ほど普及していません。
オリエンテーション：目標と理由
各当事者にとって、目標指向性を理解することが重要です。通常、プログラマは、ユーザーが望む目標を理解していると、より効果的に作業できます。私たちは、「このボタンとその影とその遷移が必要です」と、開発者にとって意味のないものであると説明しています。
これはUXの問題でもあると思います。多くの「パターンライブラリ」は、目標や問題ではなく、輝度係数に集中しています。パターンは常に問題のパターンである必要があり、推奨されるソリューションがその問題に対して機能する理由の説明を常に含める必要があります。
ユーザーの調査や科学論文を使用して、指定された目標をサポートします。おそらく、プロジェクト自体の研究からのライブのデモや統計を彼らに与えるでしょう。そうしないと、目標が本物でなくなり、開発者から尊敬されなくなります。
目標と問題、パターンの観点からUXを実行しようとしました。各ステップには、解決すべき問題があります。
これは、プログラミング教育の教育も次のようになります。彼らはあなたに問題を提示し、数分待ってから、大規模なソリューションを開始し、「それは問題ありませんbut " 、そして完全な解決策が見つかるまで詳細を調べます。
数量化、数量化、数量化
プログラマーは数値を理解します。フィードバックが1000ミリ秒以内に来ることが非常に重要であると彼らに伝えた場合、彼らはそれがそうであるかどうかをチェックする自動テストを作成できます。自動テストは最近本格的に進んでおり、これはコンピューターにテストを依頼できるものです。
1000ミリ秒以内に回答することが重要であると彼らに伝えた場合、彼らはその目標に向かって取り組みます。画面上で少なくとも1 cmの長さが必要な場合は、その目標に向かって取り組みます。
しかし、彼らに理由を与えることは常に重要です。開発者は馬鹿ではなく、特にUXコミュニティによってそのように扱われることを嫌います。
ヒューマンファクターの場合、クックブックを提供します
ステレオタイプのプログラマーが人を理解するのが得意ではないのは事実です。それは、他の人の代わりにコンピュータを扱う親和性と、開発者として働くためにサインアップすることの間の相関関係から来ています。
たとえば、ほとんどの人は本当に上手なので（人間の仕事に必要なため）、人間は物事を覚えるのが苦手であることを思い出しません（リコールと記憶）。
しかし、良いクックブック（10の戒め、箇条書きのチェックリスト）がある場合、それらは1日の終わりに説明付きで説明があり、うまくいくかもしれません。
これは、bugzillaが頻繁に引用するタグがここで行うことであり、開発者に経験則を提供します。 「ux-undo」のバグがあると開発者は言います、「ああ、そうです、簡単に元に戻せるはずの経験則があります」。
そのような良い本は、Weinschenkの 100 things です。
受け入れ、プログラマーはテクノロジーに占有され、魅了されている
プログラマーの炎上戦争はテクノロジーに関するものです。あなたは驚かれるかもしれませんが、最後にそれがどれほど重要ではないか、どのテクノロジーを使用しているか、それでも彼らの自由時間（そして、ええと、実際には）最高です。彼らはリンゴとオレンジの間でさえ議論します、そして、彼らはそれが2つのリンゴであるか、またはAppleとオレンジであるかどうかにかかわらずです。
彼らはまた、それが「人間工学的」であると考えて、彼らが見つけたすべての光沢のあるものをウェブサイトに載せました。これは特に光沢のある相互作用に当てはまります。
現在のテクノロジーでサポートされていないものがある場合（システムのウィジェットライブラリに特定のウィジェットが見つからない場合など）、UXデザイナーは、技術的な障壁が本当であるかどうかを理解するために時間と労力を費やす必要があります。ない。
まとめると
このテキストには3つの目的がありました。
- ほとんどの開発者がすでに知っていることの一般的な概要を提供する
- 大きな分類法をどのように分類できるかに関する一般的な出発点を提供する
よく知られているBugzillaタグだけでなく、UX-vs-Devsディスカッションで誰かが後でリンクできる参照を持つため
-
ウェブサイトと同じ基本ルールが適用されます。
これは、オペレーティングシステム用に公開されている「インターフェイスガイドライン」に適用される基本的なルールと同じです（Microsoft＆Appleインターフェイスガイドラインなど）。
基本的に、インターフェースは「ヒューマン」要素を中心に構築する必要があります。もちろん、これは実際のインターフェースが何であっても同じです。
基本的な概念は、 Appleヒューマンインターフェイスガイドライン の最初の3つの章で説明されています。 （読み込みに時間がかかります）
難しいのは、この種のことを簡単に参照するための良い方法がないということです。支援する最善の方法は、自分で要件を収集するように彼らに教えることかもしれません（それらの1つは、誰かに釣りをして、彼らに永遠の瞬間を与えるように教えます）。 Jakob Nielsenにはすばらしい インタビューユーザーに関する記事 があります。それをいくつかの類似した/競争力のあるサイト/アプリの簡単なレビューと組み合わせると、UI/ID作業を開始するための優れた基盤が得られるはずです。これは、あなた（UIの専門家）が存在することで付加価値を得るプロセスですが、去った後も使用するためのいくつかの基本を教えます。
非常に興味深い質問です。
私はあなたがそれ以上の答えを探していると思います：
- ユーザーの人口統計を尋ねます。
- ユーザーのコンテキストについて学びます。 （場所、環境、社会経済的要因など：HoltzblattとBeyerによるコンテキストデザインの作業モデルを見てください。）
最初のユーザー調査の要点は、ドメインを理解し、システムの問題/故障を見つけることです。これが行われた後にのみ、より具体的な要件関連の質問を行うことができます。要件に関してソフトウェアエンジニアが通常取得する（または取得することになっている）ものは、実際には、顧客/ユーザーからの要件として入ってくるデータから（ある種のデータ分析を使用して）抽出された機能要件です。
上記のAndrewが述べたように、これについて言及する良い方法はありません。その理由の一部は、プロジェクトごとに異なることに焦点を当てているためです。たとえば、完全な再設計が必要ですか？次に、より基本的な体系的な質問をします。ルックアンドフィールを変更し、ビジネスロジックのみを残したい場合は、尋ねる質問は表面的です。
これに関するリファレンスをコンパイルするのが難しいもう1つの理由は、さまざまなソフトウェアプロジェクトが異なるドメインに存在し、ドメインに基づいて質問がかなり異なるためです。
ソフトウェアプロジェクトをグループ化する方法は他にもあると思います。
そうは言っても、さまざまなタイプのプロジェクトをグループ化し、関連する基本的な質問をするのは興味深いプロジェクトかもしれません。