UXの範囲をどのように定義しますか
したがって、私の仕事の一部には、UXの観点から既存のアプリケーションを確認し、その後、コンサルティング的なアプローチを取り、改善を提案することが含まれます。ただし、このタスクは、アプリケーションもレビューする他のチームと並行して実行されますが、機能、パフォーマンス、セキュリティなどの他の観点からも実行されます。すべてのチームは、サイロでほとんど作業します。
最近、ユーザーが複数のソースから一部のデータを受け取るアプリケーションに出くわしました（すべてが独自仕様であるため、特定のデータを提供できません）。このデータはアプリケーションを使用して調整され、最終的なレポートが生成されます。基本的に、ユーザーが調整されたデータに満足したら、ボタンをクリックする必要があり、PDFレポートが自動的に生成されます。
アプリケーションを確認していると、レポートに一部のデータが適切に表示されていないことに気付きました。基本的に、データの一部が「x」であり、ユーザーが「y」に変更した場合でも、レポートには「x」が反映されます。
私はこれをUXの問題として文書化しましたが、上司は、これはユーザーエクスペリエンスに影響する一方で、アプリケーションが適切に機能していないことを意味するだけなので、UXの問題ではなく機能の問題として分類する必要があると述べました。
私は彼の意見に同意しますが、ユーザーが特定の目標（この場合はレポートを生成する）を達成するために一連のタスクを実行するため、UXの問題としても分類できると感じました。ただし、レポートがユーザーの予想と異なる場合は、フラストレーションが発生します。
このことを考えると、機能、パフォーマンス、セキュリティ、互換性など、すべての問題が直接または場合によっては間接的にユーザーエクスペリエンスに影響を与えることを考えました。したがって、アプリケーションのありとあらゆる問題は、UXの角度を持つ可能性があります。
したがって、そのような場合、セキュリティや機能などのアプリケーションの他の側面と比較して、UXのスコープをどのように定義するのでしょうか。
これは少し広範で主観的なものになる可能性があることを理解しているため、少し客観的にするために、以下で言い換えて少し具体的にしました
UXと非UXの問題を区別するための標準的なパラメータ/原則/経験則はありますか
この地域について書かれた研究/論文/記事はありますか
すべてのコンテキストに対する回答を歓迎しますが、この質問は、レビューや評価などのタスクに関しては、範囲にのみ焦点を当てています。
私が言うことに飽き飽きしないように、すべてはスペクトルに存在します。現実の世界には白黒のシナリオはありません。すべてがエンドユーザーエクスペリエンスに影響しますが、すべてがUXロールの責任の範囲に該当するわけではありません。組織のトップからボトムまで、製品、その機能、ユーザーエクスペリエンスに関して、人によって責任、見解、理由、関心、解釈が異なります。
したがって、UXの役割では、ユーザーエクスペリエンスをデザインすることは不可能です。これは、すべての影響を受け、さらに重要なのは、あらゆるレベルでeveryoneの影響を受けるためです。これには、各ユーザーとその環境の違いも含まれます。ユーザーを設計することはできませんし、状況を設計することもできません。私たちにできる最善のことは、意図された体験のためのデザインです。
したがって、UXデザイナーの役割にはすでにユーザー側でかなり大きな制約があるため、製品側（組織内）での責任を制限することも不合理ではありません。 UXデザイナーが仕事に優れていることは重要ですが、きちんとしたマネージャーは、自分より多くのことを知っている人、つまり適切な仕事に適した人を雇うことが最善の策だと教えてくれます。したがって、セキュリティ、パフォーマンス、互換性などはすべて「脈拍のUXフィンガー」を使用するのに役立つ領域ですが、これらはユーザータッチポイントガイダンスを提供しながら、エキスパートに任せるのが最適な領域です。必要な場合。
その逆は、UXデザイナーとして、あなたがエキスパートと見なされる領域があるということです。他の人は独自の「指先を振る」を望んでいますが、これらの領域はあなたに任せるのが最善ですが、they自分の興味に関連するタッチポイントガイダンスを提供します。
時々、知識の分布と専門分野（または欠如）によっては、誰がエキスパートであるか不明であり、それは共同での発見と開発の問題です。
つまり、重要なことは、連携、コミュニケーション、共有です。時々asエキスパート、時々withエキスパート、そしてその間のあらゆるレベルで。
「すべてのチームはサイロでほとんど機能します」あなたは言った。 そうです、問題があります。
サイロはこれを殺します。彼らはコミュニケーションを殺します。それらはその中間のスペクトルを遮断します。彼らは、「ほとんどの場合それはそれほど単純ではない」という二分決定を「私の領域かどうか」を強制します。
不確実性を受け入れる。スペクトルを受け入れます。
一般的には、組織内/クライアントとの運用状況によって異なります。組織内にいて、他のチームと並行して作業している場合、その作業はより大きなシステムの一部であり、これらの用語でのみ測定できます。したがって、あなたと上司はどちらも正しいでしょう：開発の失敗のためにUXに問題がありますが、その失敗が修正されると、UXの問題も修正されます（理論的には、これは実際にはめったに修正されません）。
繰り返しになりますが、クライアントと協力していて、開発プロセスの他の部分をほとんどまたはまったく制御できない場合は、仕様と設計ドキュメントを提供すれば完了です。あなたの仕事をフォローするのはクライアント次第です。彼らがあなたが仕事を監督するつもりで給与を支払っているなら、理論的にはそれはあなたの役割の範囲にのみ依存します。
私は昨年（8か月前のように）これを経験し、Slackボットに取り組んでいる会社のUXコンサルタントとして採用されました。登録と通信のフローを設計する通常のプロセスを実行しただけで、それが完了すると理論的には完了です。しかし、クライアントはまた、誰かが日々処理し、開発作業が私の仕様に従って行われたことを確認することも望んでいました。これは、私がUX作業を完了している間、その作業の開発も監督したことを意味します。
実際には、それはUXの仕事ではありませんでした。私の監督は、プロジェクト管理とQAから基本的なベビーシッターまですべてでした。そして、私はそれに対して支払われました、そして、それはしばしば私からほとんど見落としを必要としなかったので気にしませんでした。
請負業者/フリーランサーにとって、これは契約で非常に明確にリストされなければならないものです。それが組織内にあり、仕事の説明に含まれていない追加のタスクを引き受けることに不安がある場合は、上司や人事部に持ち込む必要があります。
私の意見では、ユーザーエクスペリエンスは、それをサポートするエンジニアリングのあらゆる側面と絡み合っています。それは、形、機能、美学が絡み合っているからです。ユーザーエクスペリエンスを分離しないでください。これは、アプリケーションを開発するためのエンジニアリング作業の側面です。
あなたの特定のケースでは、あなたの上司は絶対に正しいです。これはバグです。非常に悪いです。あなたの説明は少し曖昧ですが、機能の主な使用（変更してから印刷）で完全に失敗したようです。これは私には受け入れられません。バグは生活の一部ですが、機能しない主な機能は、不適切なテスト手順の兆候です。