サイトの目的とビジネス要件の違いは何ですか？
一般的なuxプロセスの多くは、通常、「顧客からの問い合わせを5％減らす」または「新規顧客を10％引き付ける」などのサイトの目標と目的を定義することから始まります。次に、目的の影響を受ける内部関係者にインタビューすることをお勧めしますそして、それらを達成するために何が必要かについて質問します。より良いFAQが必要である、またはseoに投資する必要があるなどの回答を収集します。
私にとって、要件と目的は同じです。誰かが違いを説明でき、ビジネス要件をプロセスに含めることが重要である理由を説明できますか？.
目標がターゲットです。要件は、それらへの認識されたパスへの基礎です。
目標は、対戦相手よりも少なくとも1つ多くのゴールを撃ち、サッカーの試合に勝つことです。ゴールキーパーとして入ってくるボールのほとんどをキャッチすることが要件です。
これは理論であり、アドリアンの答えによってよく表現されます。
practiceでは、要件はビジネスが必要とするものまたはwants（2つは必ずしも会う必要はありません！）一方、目的は無意味なbullsh.tですが、なぜ彼らが欲しいのかという理由付けとして彼らに与えるように要求されましたそれら。
要するに、平均的なケースでは、目的を達成しても誰も気にしませんが、要件の1つでも提供できず、解雇されます。ほとんどの組織は、実際に目的を追跡するのに十分な意識はありませんが、要件は厳密に追跡されるはずです。
マーケティングやUXのプレゼンテーションを見ていると、目的が完全に成り立っているように感じることがあります。そして私は自分自身に尋ねます：ユーザー（消費者）のニーズは満たされましたか？
売上高を10％増やすことが目標で、5％しか増やすことができない場合もありますが、その間、すべてのお客様や管理者にとっても快適なユーザーエクスペリエンスを実現しました。 10％に達しなかったことが本当に重要ですか？依存します。
目的を達成しなくても、すべての要件を十分に達成できます
一方で、要件を満たしていても、目的を満たさなければ意味がない場合もあります。目的がオリンピックの金メダルを獲得することである場合、目的が達成されなかった場合、設計したドレスが演壇に立っているときにも見栄えがよくなることは問題ではありません。
すべての要件が満たされていても、ケイラは彼女の主な目的が達成されなかったことに感銘を受けませんでした
目的が真のビジネスニーズであるか、真面目なビジネスマンのように見えるように構成されたものだけであるかを判断するには、経験と優れた「臭い」が必要です。 。
それが定義されていると私が見た1つの方法は、大まかにです。
目的：ビジネスで実現したいこと。
要件：目標を実現するための計画。
（誰もがこのように正確に定義しているわけではありません-しかし、ラベルが異なっていても、通常は2つの異なるカテゴリを見つけるでしょう）
例えば。
私は「顧客の生涯価値を10％増やす」ことを目標としています。
調査の結果、顧客がサービスを離れ、Fooの主要機能を使用したことがないことがわかりました。
したがって、1か月後にまだFooを使用していない顧客にニースドリップフィードのリマインダーメールを追加すると、Fooの素晴らしさを思い出させることができ、顧客を存続させて顧客の生涯価値を高めることができると考えています。それが要件になります。
それがうまくいくなら-イェイ。要件と目的の両方がチェックされました。
それが機能しない場合でも目的は維持されますが、今はその目的を満たすための要件を調整する必要があります。
目的-私たちが望むもの-はかなり静的です。要件-私たちが望むものをどのように達成するか-は変わる可能性があります。
目的
ビジネス目標とユーザー目標があります。
ビジネスの目標は、アドリアンの例のように、マネージャーまたは利害関係者から来ています。「顧客の生涯価値を10％増やす」。それらは、サイトの背後にあるビジネスの目的に関連しています。 「商品をオンラインで売ろう」のような根本的な目的があります。これはビジネスの中心的な目的であり、誰もが当たり前のことです。
私たちのサイトに対するユーザーの目的は、「ワイヤレスマウスを手に入れる」ことに似ています。
これらは（エンド）ユーザーから、またはエンドユーザーが簡単に利用できない場合はpersonasからのものです。
アランクーパーは、ユーザーの目的を「 被収容者が亡命している 」やその他の本で明確に説明しています。
エンドユーザーの要望（一般に「購入品」）は、「Bluetoothマウスはトレンディ」などのマーケティング調査結果によって補完されます。
Eコマースサイト（それがそうだと仮定しましょう）の成功は、多くの中でも、両方の目的がどのように調整されるかにかかっています。しかし、それはユーザーの目的により大きく依存するため、ビジネスの転用は常にオプションである必要があります。
これはすべて、高レベルのビジネス戦略に関係しています。
必要条件
サイトレベルに到達すると、ここにrequirementsが表示されます。
顧客価値を高めるという戦略的目標は、1つ以上の方法で追求できます。
特徴（アドリアンの例）を思い出させるように、また流行の商品を提供し、送料や時間を削減することで、名前を付けます...
UX実践者として、会社の目的をサポートするための最も強力なツールは、サイトのユーザビリティを強化することです。
簡単に購入したユーザーが次回サイトに戻ってくるなどのように、10％の顧客価値の増加をサポートすると推測できます。
それで、私たちは分析して考え（これは多くの競合サイトの閲覧を意味します）、UIに加えるいくつかのアイデア、変更を思い付きます。これは分析フェーズであり、すぐに要件の記述が続きます。
関連するサクセスストーリーは Jared Spoolの3億のボタン です。
会社の組織レベルに応じて、ナプキンで開発者に変更を通知したり、ユースケースの作成やワイヤーフレームの描画など、より正式なことを行うことができます。
これらは要件です。 IT用語では（アクションをビジネス分析からソフトウェア開発に移動したため）要件は、コードを書く人に処理されるドキュメントです。それらから期待される結果の明確な仕様を含む。
ナプキンも要件としてカウントされますが、UCよりも非公式でリスクが高いだけです。
ユースケースについての一言
または2つ...
まず、ユースケースは、UMLやSEIのCMMIなどを使用する大企業でのみ実行する必要がある、非常に正式なドキュメントと見なされる場合があります。
そうではありません。 UCはシンプルで非公式であり、UIを使用する実際のユーザーに基づいています。 UCの記述では、少ないほど良いです。 UCセットが重すぎると、誰もそれを読むことができないため、役に立たないと言われています。
また、UCを作成するためにITプロペラヘッドである必要はありません。実際には、あなたのほうがいいです。
第2に、UCの優れている点は、UCが一般の人々の悩みとソフトウェア開発者の世界を明確に表現するヒンジであるということです。
UCはエンドユーザーが理解でき、ITタイプの明確な仕様でもあります。
適切に記述された開発者向けのUCを処理すると、望んだような結果が得られる可能性が大幅に高まります。また、開発期間が短くなり、開発コストが低くなることを意味します（これは測定されたもので、数値は30％のように重要です）。
これは、優れたUCを作成すると、開発者がつまずくすべての質問を自分自身に尋ね、それを先取りすることを強制するためです。
また、UCはエンドユーザーが監視できる（またはpersonasに対してチェックできる）ため、結果のUIが確実に完成すれば使えます。