「柔軟なワークフロー」よりも「早期予防」を優先すべきですか？
はじめに
かなり単純なユースケースで、4つの（シック！）相互に関連するモーダルウィンドウを明示的に指定する仕様があります。これは、昔ながらの考え方の結果のようです。つまり、「問題定義を定義しましょう」ではなく、「要件をどのように正確にとして機能させるか」と定義します。広い意味で」言い換えれば、古典的な "HOW"と "WHAT"の問題です。
これが要件と私の考えです。確認し、フィードバックを提供し、独自の推奨事項を作成してください。
元の要件
新しいバッチの作成–ポップアップボックスを開き、ユーザーがバッチIDとバッチの説明を入力し、ドロップダウンから支払い期間の終了日を選択し、ドロップダウンから流通部門を選択できるようにします...
バッチID、支払い期間の終了日、および配布部門が必要です...、ユーザーは「作成」または「キャンセル」を選択できます
- ユーザーがその支払い期間と配布部門で別のバッチと同じIDのバッチを作成する場合、「このバッチIDはこの支払い期間にすでに存在しています。別の値を入力してください」というメッセージを表示します。
- ユーザーが新しいバッチを作成すると、「新しいバッチを今すぐ開きますか？」という別のポップアップが表示されます。 「はい」を選択すると、検索パラメーターにバッチ値が入力されてバッチが開き、「いいえ」を選択するとポップアップが閉じて、ユーザーは同じ画面に留まることができます
- ユーザーが「はい」を選択し、保存されていないトランザクションがある場合は、「このバッチを開く前に変更を保存しますか？」というプロンプトを表示します。 [はい]、[いいえ]、[キャンセル]ボタンがあります
UXを簡素化
私は、より良いUXには複数の代わりにsingleモーダルウィンドウがあると思います。
基本的なバッチ情報を入力するためのモーダルウィンドウがあります。これは、「新しいバッチの作成」セクションで説明されているとおりです。
「このバッチIDは既に存在します」ウィンドウが削除されました。バッチの作成に失敗した場合に表示される[作成]ボタンの横に検証エラー通知が表示される場合があります。
「変更を保存しますか？」ウィンドウが削除されます。これは、ページ上に失いたくない変更がいくつかある限り、バッチ作成のメカニズムを無効にすることで実現できます。つまり、新しいバッチを作成する前に、ユーザーが貴重な入力を保存できるようにしたいと思います。
「今すぐ新しいバッチを開きますか？」ウィンドウが削除されます。 「作成」と「キャンセル」の隣に「作成バッチを開く」という追加のボタンがあります。ボタンは、バッチ作成が成功した後にのみ表示/有効化されます。
したがって、モーダルの数が4から1に減り、複雑なフローはライナー（より単純なもの）に置き換えられます。複雑なシステムを構築して維持するのは難しいので、それは私にとって物事をより簡単にします。ただし、システムを単純化しすぎないようにしたいと思います。つまり、"最適"/"理想" UXを犠牲にしています。
質問
私の考え方は、この状況での進め方ですか？
/結果への対応の代わりに、特定のシナリオを回避でUXを簡略化する必要がありますか？
この場合、ワークフローの柔軟性が低い（線形性が高い）のは悪いことですか？
PS私はnotに設計または強力な設計の学位を持っているフルスタック開発者です/ UX原則の基礎。したがって、私の見解と意思決定のほとんどは、システムの簡素化によってもたらされます。
P.P.S。同様の質問を検索しようとしましたが、あまりよくありませんでした。 @モデレーター、私の質問の一部がルールに違反しているかどうかを知らせてください。更新したり削除したりします。
モーダルを削除するというあなたのアイデアは、正しい方法のように思えます-ステップ3まで。モーダルを削除したいという理由だけでコア機能を無効にすることは、私にとってはやり過ぎであり、多くのユーザーを困らせるでしょう。他の情報を編集した後で新しいバッチを作成しようとしていますが、ボタンがないか無効になっています。そのボタンを再度表示させるには、変更を保存する必要があることをどのようにして知っていますか？
保存されていない変更がある場合でも、[新しいバッチを作成]ボタンを使用できるようにしておくことをお勧めします。それらを自動的に保存するか、新しいものを作成する前にユーザーにそれを実行するかどうかを尋ねます。デフォルトでそれらの新しいバッチを開くこともできます。ユーザーが通常、バッチを作成した後、バッチに対して実行したいことがある場合、ユーザーはすぐにそれを実行したいと思うでしょう。
もちろん、システムのワークフローとアーキテクチャが私が推測しているものと異なる場合、上記のアドバイスは意味をなさないかもしれません。いくつかのUIモックアップを作成し、ユーザーの調査を行って、システムとやり取りするときに何が発生するのかを調べます。