ラジオボタンと用語の混乱
私はモバイルアプリケーションを設計していて、在庫管理セクションの構成方法に関するガイダンスを探していました。このアプリでは、ユーザーが製品をスキャンして、現在の手持ち在庫（SOH）を更新できます。いくつかの初期テストから、2つのラジオボタンの間でユーザーが混乱していることがわかりました。例については、こちらをご覧ください。
在庫の更新とは、データベースがユーザーが入力した値に更新されることを意味します。在庫に追加すると、現在のデータベースの値がユーザーが入力した量だけ増加します（SOH 30 +入力値5 = SOH 35）。
ユーザーは2つの違いを本当に理解していません。このために、UXをここで助けるための提案はありましたか？
おかげで、
同様の質問 ここで回答 がありました。それをモバイルに適応させると、次のようになります。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
ここで重要なのは、ユーザーが手持ちの在庫またはのいずれかを編集できることですが、両方を編集することはできません。これらのフィールドの1つが編集されるとすぐに、[保存]ボタンが有効になり、他のフィールドは無効になります。キャンセルボタンを使用して以前の番号にリセットできるようにすることもできますが、テストが必要になります。
検索バーには追加しなかったため、レイアウトは元のスクリーンショットとは少し異なります。
- 製品の詳細と在庫を別々のセクションに分割（スキャンが簡単）
- 編集可能フィールドと編集不可フィールドの違いを明確にし（下線が引かれたフィールドが編集可能かどうかは元のフィールドでは明確ではありませんでした）、製品の詳細を右揃えにしました
- 使用 エンクロージャー [保存]ボタンでインベントリフィールドをグループ化する
私の質問は（そしてそれはあなたに頭の悪い馬鹿げた質問かもしれません）でしょう、なぜ両方のオプションを提供するのですか？
ユーザーが選択する単一のオプションを保持しないのはなぜですか。
「在庫に追加」。ユーザーは、システムが更新を維持するために、持っている追加のアイテムを配置する必要があります。
そうすれば、彼らがする必要があるのは、受け取った新しいSOHアイテムを追加するだけで、データベースはそれ自体で更新されます。
ユーザーに自由を与えるという論理を理解しました。
しかし、トンネルビジョンを提供し、次のような認知的負荷を取り除くことは、-"エラー、これらを追加するか、それとも私の合計ですか？"は、ユーザーにとってより良い傾向があります。
混乱はWordの「更新」に起因するのではないかと思います。
それは私がネイティブスピーカーではないためかもしれませんが、このWordは古い値が上書きされることを示唆していません。
少しナイーブに聞こえるかもしれませんが、ラジオボタンの名前を"set as current SOH value"に変更すると役立つ場合があります。
（余分な文字のスペースは画面に問題がないようです）
またはSocrates Koliosのアドバイスに従って、選択を完全に削除します。
TL; DRバージョン
これまでの情報から、ほとんどの場合、この画面でonlyadd to stock（SOH）オプションが必要になると思います。ただし、以下で説明するように、これにより、システムの手持ち在庫の概念にorが追加され、在庫チェックの実行時にorが実行合計に追加される場合があります。 （基本的に、両方のアクションに同じ画面が使用されます）。
pdate/set stockオプションはおそらく他の場所（おそらくマネージャーの画面上のみ）にあり、在庫チェックプロセスが完了すると使用されます。
ユーザーが実行しているプロセスが完全に明確ではないため、手持ち在庫（SOH）に追加したり、SOHを更新/設定したりすることが最も理にかなっている場合は、完全には明確ではありません。 UIを提示する最良の方法を決定するには、まだ行っていない場合、ユーザーが実行するアクション/プロセスを明確に定義する必要があります。
ただし、すぐに思い浮かぶ2つのアクションは次のとおりです。
入荷の処理 –サプライヤから小包/出荷が到着し、ユーザーは在庫コードと受け取ったアイテムの数をスキャン/入力します。
在庫チェックの実行 –ここでは、システムに対してチェックするために物理的に存在するものを手動でカウントして（ショップや倉庫内の）棚をローミングします。
これらについては以下で説明します。 これらのアクションが正しくない場合、または実行されている他のアクションがある場合は、指定してください。
入荷の処理の場合、私は在庫に追加が役立つと考えることができます–配達を開く人は、実際に在庫があるアイテムの数を知りません（知る必要もない）;彼らがする必要があるのは、システムにx more利用可能なアイテムがあることを伝えることだけです。
stock-checkingの場合は、さらに複雑になります。
- 特定のアイテムのすべてのインスタンスが同じ場所にあるguaranteedである場合、ユーザーはその場所に移動してアイテムを数え、その数を入力できます。この用途では、在庫の更新（または在庫レベルの設定）が適切なオプションになります。
ただし、その使用例はかなり制限されているように見えます。anyがある場合は機能しません。在庫が複数の場所にある可能性があります（倉庫内の複数の場所、倉庫と店頭の両方に） ）。さらに、システムはdifferencesシステムの在庫thoughtの在庫状況とactuallyの在庫状況を簡単に分析できません。小規模な組織の場合、これは問題にならない場合があります。ただし、大企業は、2つの間に不一致がある場合に知りたいと思うかもしれません。これは、不十分な作業慣行（配送が適切に処理されていない、アイテムが販売時に登録されていない）を示している可能性があります。過度の破損または盗難。
このレベルのチェックを提供するには、twoカウントを維持する必要があります：現在実装されているSOH（配信時に増加、販売時に減少）およびrunning在庫確認済み商品の合計。手順は（特定の在庫品目の場合）、次のようになります。
在庫確認商品の累計をクリアします。これは、確認する単一のアイテムの場合と、完全な在庫チェックを実行する場合はすべての在庫アイテムの場合があります。
ユーザーはショップ/倉庫を歩き回って、チェックされている単一のアイテムのインスタンスを探すか、見つけたすべてのものを処理します。どちらの場合も、在庫コードと見つかったアイテムの数をスキャン/入力し、配送を処理するときと本質的に同じ在庫に追加関数（基本的に同じ画面上）を使用します（違いは実行中のstock-check-totalが、通常のSOH値の代わりに増分されることを示します）。
演習の最後に、誰か（おそらくチェックを行っているユーザーではない）がstock-check-totalカウントを確認します。この時点でのみ（詳細な調査のための不一致に注意した後）、日々のSOHカウントが在庫チェックカウントから更新されます。
フィールドNew Stockを追加して、保存後の在庫を表示します
[〜＃〜] soh [〜＃〜]はすでに表示されています。 カウントされた数量の下に、選択したラジオボタンに基づいて、保存をクリックした後のNew Stockを示すフィールドを追加します。
このようにして、ユーザーはSOHがカウント数量によって増加するか、カウント数量に設定されることを確認できます。
ジョナサンのデザイン をベースとして使用：
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
その他の変更：
- 「Update SOH」を「Set as SOH」に変更しました
- 最後にカウントされた日付は自動的に更新されます
ユーザーがオプションの結果を確認できるようにします。