ユーザーによるカスタマイズの自由の制限
コンテキスト：
現在、さまざまな企業で使用されている従業員出勤アプリの再設計に取り組んでいます。現時点では、アプリを使用している企業は、自分のニーズに合わせて自分の出席ステータスを設定できます。
たとえば、Company Xが作成し、出席ステータスを使用します：現在、後期、欠席。 Y社が使用している間：現在、不在、不在不在
私たちは、クライアント会社が使用したい出席のオプションの数とオプションを完全に制御できるようにするため、会社ごとに異なります。
これは、ユーザーインターフェースを見るまではすべて問題なくうまくいきます（再設計が進行中なので、表示する義務はなく、いずれにしても関連性がありません）。多くの可能なオプションとそれは全体のワークフローを不必要に遅くします。
問題点をさらに説明するコメントのための編集：クライアントが本当に必要なのは、基本的に、クライアントが存在していたか、不在だったか（通知あり）、通知なしであるか、または遅い。一部のクライアントは、その目的のためにのために13の異なるステータスを持っています。それらはどちらかと言えば似ているため、どのステータスをチェックするか。また、これらすべてのオプションにより、UIが不必要に乱雑になります。
そのため、私たちがしたいのは...
...すべてのクライアント企業の出席オプションを標準化して、本質的に同じ意味を持つ、何百もの異なるステータスのバリエーションに対応する現在の状況を回避します。少数ながら十分な数の使用可能なステータスを設定し、クライアントが独自のステータスを作成するためのオプションを削除する予定です。
私たちの懸念は...
...既存の顧客から、システムに対する現在のカスタマイズと制御のレベルの制限と削減についての抗議、および作業を完了できたとしても、システムの使用を単に停止すること重要なものを見逃すことなく、はるかに簡単かつ高速に流れます。
手元の質問：
ユーザーがカスタマイズする能力を制限し、それらを標準化されたプラクティスに強制することは、危険な道のりであり、なぜですか？
さらに、カスタマイズの自由を放棄することにユーザーをどのように説得できるでしょうか。
私は現在、これをかなり大規模に処理しています（評価され更新されている古い複雑なシステムの大きな領域）。それに関連して、私は最近、アトラシアンデザイントーク/パネルにも参加しました（言い換え）...
「アプリケーションに導入する各機能については、十分に慎重に検討してください。いったん導入すると、その機能を利用するのは非常に困難です。」.
機能セットの削減
現時点でのUIは「完全な混乱」であり、主観的であると言いますが、主観的でないものは次のとおりです。
- アプリケーションのすべての追加機能には、ビルドまたは更新する作業と、チームまたは他の人によるメンテナンス作業が必要です。
- 重要ではない情報のすべてのビットは、本質を損なう。
- 豊富な選択肢を提供すると、ユーザーの認知負荷が増加します
私の見解では、価値のないコンテンツ/機能をアプリケーションから削除する機会がある場合、それらを削除すること自体に価値があります。
... [私たちの懸念は]重要なものを見落とすことなくワークフローをはるかに簡単かつ迅速に完了することができたとしても、彼らは単にシステムの使用をやめることです。
ここであなたは自分の質問に部分的に答えたと思います、ニース！
解は2つの部分から成ります：
計画されたオプションの統合はユーザーにとって全体的に有益であるという仮説を確認するための調査を実施します。個人的には、これを再構成し、「ユーザーが実際に何を必要としているのか、最終的な目標は何か」と質問することを好みます。
変更を伝達し、更新が可能な限りスムーズに適用されるようにします。
調査-機能は価値を提供していますか？
理想的には、最初のステップは、ユーザーが現在アプリケーションをどのように使用しているか、および利用可能なオプションをどのように使用しているかを調査することです。
- 人々が長期間にわたって（たとえば、1日の間に）ステータスを変更している場合、直接観察することは困難ですが、ある種の分析データやデータベースのデータ（人々の現在のステータス）にアクセスできる場合があります。頻繁に使用するものと使用頻度の低いものを決定します。
- ウォーレン は、カードの並べ替えを行うことを提案しました。これを行う方法について詳しく説明しています...
- あなたは現在利用可能なすべてのオプションを取り、個々のカードに書き留めます。
- 個々のセッションで実際のユーザーを獲得し、カードを論理的に類似したグループに分類します。
- 作成した新しいグループに名前を付けてもらいます。
- これには2つの利点があります。最終結果（ユーザーがカードをグループ化した方法の分析に基づく新しい小さなオプションのサブセット）と、ユーザーがタスクを実行するときにユーザーと交わすことができる会話（ユーザーに質問することを忘れないでください）彼らが躊躇しているかどうかを考え、チャットした後、彼らが現在アプリをどのように使用しているかについてチャットし、ステータスを変更したときに最終的に達成しようとしていることを詳しく調べます）。
コミュニケーション-変化が来ています
ユーザーが他のオプションから価値を得ないことを確認した場合は、変更をユーザーに通知するだけで済みます。
- 「アップデートが来ています...」と変更の詳細を説明する事前のコミュニケーションを送信します。そのため、UIが1日変更されてもショックではありません。
- これはポジティブな変化なので、1のようにスピンします。 「私たちはあなたのやり方を簡略化しています...これにより...が簡単になるはずです。」
- 機能のUIが大幅に変更される場合は、変更と新しい機能の仕組みを説明する簡単なオンボーディングを追加することを検討してください。これは、新しいユーザーではなく、変更前に存在していたユーザーだけが見る必要があります。
これは大規模なアップデートの一部であり、ユーザーリサーチの結果に基づいた情報に基づく変更であったため、他の領域でユーザーにメリットがもたらされ、1つの変更が覆い隠される可能性があります。
私の考えは、あなたがそれを制限すると、あなたは既存の顧客からの抗議に直面します。彼らがニーズに合うようにこれらのステータスを作成したことを覚えておいてください。さらに、少なくとも将来のデータと比較できるようにしておく必要がある過去のデータもあります。そして最後に、人々は結局それらを使うことに慣れました。
一方、データをカスタマイズする自由を与えすぎると、特にユーザーが入力した情報の整理方法について誤解を招きやすくなるため、場合によっては混乱を招く可能性があります。
これを念頭に置いて、私は現在のステータスをシフトするの解決策をより低いレベルに検索し、作成する新しいステータスについてさらに詳細な情報にします。それはまだアイデアであり、そこにある実際のデータ（つまり、あなたの特定のクライアントが作成したステータス）に対して置く必要がありますが、これは次のようになります。
新しい、標準化されたステータス1
- サブステータス1.1。 （ステータス1の基準を満たす既存のステータス=詳細な説明）
- サブステータス1.2
等。
同時に、ユーザーは最上位のステータスのみを選択でき、下位のステータスを選択する必要はありません。
あなたの場合、トップレベルのステータスはおそらく、プレゼンス、通知のある欠席、通知のない欠席、遅れているでしょう。次に、たとえば、会社の場合、オフィスまたはリモートでの作業を許可します。または、人々は出張中（ただし勤務中）これらは、「現在」のさらなる内訳である可能性がありますトップステータス–たとえば、さまざまな緑の色合いを使用して、グラフ上にうまく表示するための余地を与えます。
しかし、私は、ユーザーがステータスをカスタマイズする方法を深く分析し、理由を尋ねるところから始め、次に、ユーザーが思いついた概念をテストします。
これは基本的な問題であり、柔軟性と剛性、自由と秩序など、設計のあらゆる側面に触れています。デザイナーとして、ユーザーを満足させ、必要なツールを提供したいと考えています。ただし、自由になりすぎて妥協すると、「委員会の設計」が行われ、最終的には非常に平凡な製品になります。
ユーザーはさまざまなサイズと形で登場します。主にキーボードを使用するユーザーもいれば、すべてマウスで操作するユーザーもいますが、結局のところ、役に立たないオプションを追加するよりも、すべてを行う方が優れています。
あなたの場合、私が思いついた出席のベストプラクティスオプション（3-5オプション）を提供し、一般設定のどこかに「ステータスの追加」機能を非表示にして、ユーザーがアクセスしにくくし、したがって、不必要なステータスを追加しないようにしてください。既存のクライアントはhate変更を行いませんが、新しいユーザーは恐ろしい機能に到達せず、デフォルトに固執することはないでしょう。また、デフォルトを変更する傾向があるユーザーの数は誰でも知っています。
私はあなたの最初の焦点はオプションを制限することにある必要があると思いますIに表示されます、設定で利用可能なものではありません。すべての顧客のカスタマイズのすべての出席状況を表示すると、事態が混乱するのも不思議ではありません。この場合、カスタマイズ性は混乱の主な原因ではありませんが、他の要因があります。現在、ある顧客が、似た名前の30の出席オプションをすべて画面に表示したい場合、別の会話が必要になります。
言及されていないその他の理由で選択肢を制限する必要がある場合は、クライアントの評議会を集め（クライアントが多すぎる場合は、慎重に選択したサブセットにすることができます）、問題を説明し、どのオプションが受け入れられるかを尋ねます。 （最も一般的なカスタムオプションを選択してそれらに限定し、組織ごとに1つのカスタムステータスのみを許可するなど）。
最も一般的な出席ステータス値を特定するために、ユーザー/顧客と（カードのソートなどを介して）必要な分類法の調査を行ったと思います。このプロセスにユーザーを含めること、および/または事前に変更を加える理由を伝えることは、ユーザーをそのプロセスに参加させるための鍵となります。
これは実際には、厳密にUXの質問というよりは、ビジネス/製品の方向付けの質問のように聞こえます。特にユーザーの選択に関しては、製品内の変更には固有の「危険」があります。問題は、組織が不満を抱いている（そして離脱する可能性のある）ユーザーのリスクを受け入れるか、製品のビジョンに対する制御を維持するかどうかです。
製品がユーザーによって価値があると見なされている場合、変更に対するユーザーへの「コスト」は、製品の全体的な価値を上回る可能性があります。
あなたが言及したこの特定のケースに関係なく、それはソフトウェアおよび製品開発の世界で一般的で私の信念の非常に重要な質問です：ユーザーの要求を盲目的に適用することを停止し、あなたが真実であると考えているものを構築し始めるための真の限界点はどこにありますかユーザーが望むよりも良いですか。私はこの問題を数年間扱っていましたが、私の意見と結論を共有します。一般に、3つの異なる考え方を持つ3つのグループの人々がいます。
- ユーザーは神であると考える人々、そしてユーザーは私たちの仕事、私たちのビジョンの指標であり、ユーザーだけが彼の欲しいものを知っています。即時のユーザーの満足は、ジョブの他のどの側面よりも重要です。この考え方はビジネスマンの考え方に近いものです。今日に集中し、明日の建築を考えない人々。
- ユーザーの意見を気にせず、問題を哲学的に検討して問題を解決しようとし、自分の考えを神の役割として口述して公開しようとする人々。この考え方は理論家に近いものであり、私は最も芸術的です。
- これらの2つのグループのほかに、ユーザーは自分が何を望んでいるのか正確にはわからない、と信じる人々の別のグループがあります。ユーザーは以前の経験に基づいて行動し、将来の可能性について考えることはほとんどありません。この考え方では、問題を哲学的に検討し、ユーザーのニーズとユーザーの要望を検討し、最終的には哲学的に真でありながら許容可能なソリューションをユーザーに提供する必要があります。この考え方はデザイナーのものです。
あなたはデザイナーのように振る舞うべきです。開発者のようなスペシャリストとは対照的に、デザイナーは1つの側面に焦点を合わせず、問題の多くの側面を見て、それらを組み合わせて可能な限り最高の結果を構築します。
問題が発生した場合、すべてのユーザーを満足させようとすると、必ず他の問題が発生し、最終的には満足していないユーザーになってしまいます。従業員の出席問題を哲学的に検討し、考えられるすべての種類のケースをグループ化してから、ユーザーの会社の文化を考慮して、重要なケースを抽出する必要があります。次に、取得した情報に基づいて、ポリシーとユーザーの自由のしきい値を選択することを決定する必要があります。インタラクティブで時間を浪費するプロセスです。しかしそれは費用がかかります。