適合性と複雑性（ゲームパッド/コントローラーレイアウト）
VRアプリを非VRに移植しています。 VRでは、頭を動かして見回すことができますが、これはもちろんWindowsアプリではできません。つまり、コントローラーのレイアウトも変更する必要があります。ユーザーは両方のバージョンのアプリを使用することもあれば、どちらか一方のみを使用することもあります。
古いレイアウト：
- 左アナログスティック：移動
- 左アナログスティックを押す：トグルラン
- 右アナログスティック：フライアップ/ダウン
- 左/右ボタン：3Dモデルを切り替える（前のモデル、次のモデル）
- 左/右トリガー：追加の3Dモデルを切り替えます（他のモデルに追加で表示されます）
- 方向パッドとA、B、X、Yはすべて特殊機能に使用されます（例：「Y」で位置がリセットされます）
新しいレイアウト：
- 左アナログスティック：移動
- 左アナログスティックを押す：トグルラン
- 右アナログスティック：見回す
バージョン1（青：オリジナルとは異なります）：
- 右ボタン/右トリガー：次のモデルに切り替え
- 左ボタン/左トリガー：フライアップ/ダウン
- 利点：それほど複雑ではなく、方向パッドと他のボタンは同じ特殊機能を維持します
- 欠点：以前のモデルに戻る方法がないため、古いアプリに準拠していません。誰かが左ボタン/トリガーを使ってジャンプ/しゃがんだ/飛ぶのを見たことがないので、直感的ではないかもしれません
バージョン2（青：オリジナルとは異なります）：
- 左/右ボタンと左/右トリガー：モデルを切り替える（前と次）
- AとB：上昇/下降
- 右アナログスティックを押す（画面上のインジケーター付き）：動きと特殊機能を切り替えます（A、B、X、Yはそれぞれ2回マッピングされます）
- 利点：以前のモデルに戻ることができるため、古いアプリとの適合性が高くなります。より多くの利用可能なボタン。また、一般的に使用されるキーバインディングにさらに準拠します（A：ジャンプ、B：クラウチ）
- 短所：すべての機能にアクセスするために切り替える必要があるため、より複雑
ご覧のとおり、両方のバージョンには長所と短所があり、ここで何をすればよいかわかりません。以前のバージョンとの整合性が低く、適合性の低いものか、適合性の高いものを使用する方が良いですか。繁雑？
ゲームで車を運転してキャラクターを制御する場合、通常は同じコントロールまたは少なくとも非常によく似たコントロールを使用しますが、これは「モード」が異なります。そのため、ボタンを2度マップして、何らかの「モードスイッチ」ボタンを追加するのが一般的です。まだ同じゲームの「モード」ですか？
新しい機能のコントロールを提供しながら、古いものに準拠しながらも学習しやすいゲームパッドレイアウトを見つけることができなかったため、次のようにしました。
レイアウト1（それほど複雑ではないが適合ではない）がデフォルトのレイアウトになるので、古いユーザーは私のアプリの新しいバージョンに慣れるのが簡単になります。
また、オプション（この選択は起動時に保存および復元されます）でレイアウト2（より複雑ですが、以前のレイアウト/ゲーム標準に準拠しています）に切り替える方法もあります。若いユーザー（/ gamers）の問題。
それはユーザーの学習コストにもっと依存すると思います。ユーザーはすでに行動習慣を形成し、アプリの機能システムを認識しています。
だからあなたの質問のために：
それほど複雑ではないが以前のバージョンとの適合性が低いもの、またはより適合性が高いがより複雑なものを使用する方が良いでしょうか？
私は後者のほうが好きです。ユーザーが新しいバージョンに適応するのが簡単だからです。ただし、前者は次の目標です。すべての最新の古いバージョンに基づいて、新しいバージョンで関数のレイアウトを徐々に反復できることをお勧めします。
ところで、いくつかのプロトタイプを添付すると、答えが視覚的になります:)
短いバージョン：「決定に役立つ質問」にスキップします。
ロングバージョン：
UXのほとんどのことと同様に、このような質問はコンテキストとユーザーグループに大きく依存します。
この場合、最も重要な質問はさまざまなアクションがどのくらいの頻度で使用されるかです
これにより、最終的にはユーザーのアプリでのワークフローがどのようになるかが決まります。
異なるモードのバージョン3を選択したが、ユーザーがモードを常に切り替えなければならない場合を想像してみてください。それは彼らを狂わせるでしょう。一方、切り替えがめったに起こらない場合は、より多くのアクションを実行する余地があれば喜んでいます。したがって、設計を選択するときは、常にユーザーのワークフローを念頭に置いてください。
Danlin Chenは既に学習コストについて言及していますが、これはこのNNグループの記事でもサポートされています。
期待よりも効率を優先しない
概要：手順を減らすことでユーザーの効率を高めることを目的とした機能は、既存のメンタルモデルや過去の経験に基づく期待に準拠していない場合、ユーザーを傷つける可能性があります。
しかし、同じ記事で彼らは 設計標準は創造性を阻害することを意図していない を指摘しています：
標準は一貫した語彙を保証しますが、より深い設計問題における設計者の自由（および責任）を制限しません。
（また、彼らはすでに新しいバージョンの飛行制御を再学習する必要があると主張することもでき、途中で他の何かを再学習させることもできます。）
結局、それは学習コストとおそらくより簡単な制御との間のトレードオフです。 そして、ユーザーについての知識に基づいて決定する必要があります。結局のところ、あなたの最優先事項は、ユーザーの生活をできるだけ簡単にすることですあなたのアプリ。
決定に役立つ質問：
自分自身（またはさらに良いことに、ユーザー！）に、彼らが上空または下空に飛ぶ必要がある頻度と、特別な機能を使用する必要がある頻度を尋ねます。これらのモードを切り替える必要があるのは煩わしいでしょうか？
次に、バージョン1を選択します。
一方、モデル間の切り替えはどのくらい重要ですか？モデルがたくさんあるので、ユーザーがターゲットを逃した場合、リスト全体をもう一度調べなければならないことにユーザーは非常に苛立ちますか？
バージョン2を選択します。
または、ユーザーに質問して、デザインをさらに適応させることもできます。