入力フィールドのエラー状態はいつ消えますか？
私は2種類の行動が循環しているのを見てきました。 1つは、新しい入力の入力を開始するとすぐにエラー状態が消えるので（入力フィールドにフォーカスがあるとき）、もう1つは、入力が '受け入れられる'（たとえば、有効な電子メール形式が入力される）まで残ります。
ユーザーが入力を修正するまでエラー状態のコンテキストを維持することは有益だと想像できますが、私のチームはそれを逆に構築しました。
どの相互作用が望ましいのか、そしてその理由は？
編集：これは私が現在使用しているエラー状態です： 
現在、ビルドされたバージョンでは、フォーカスが合うとすぐにエラー状態が削除されます（通常の状態に戻ります）。私は、フィールドの入力が「修正」されるまでエラー状態が残るようにしました。
エラーメッセージは残ります。
「想起ではなく認識」という設計原則があります。ユーザーが物事を覚えるように強制されるべきではなく、タスクを完了するために必要な情報（またはオプション）を与えるべきであることを意味します。 「有効な電子メールアドレスを挿入する」など、エラーは非常に理解しやすいことが多いと主張する人もいます。しかし、パスワードルールのように、より複雑になることもあります（まあ、実際には、例のように実際に通信する必要があります）。ユーザーは、入力中にこの参照が必要になる場合があります。この情報を奪うことはユーザーにとって苦痛です。
したがって、入力が有効になるまでエラーメッセージを表示することをお勧めします。入力が正しくなるとすぐに検証情報が消えるはずです（「フォーカスが失われる」まで混乱しないようにしないでください）。
ここで@BrunoHに部分的に同意します。
'リコールではなく認識'ヒューリスティックにより、ユーザーは何が間違っていたかを覚えやすくなります。ただし、これには「悪い」側面があります。たとえば、ユーザーがエラー修正プロセス中に中断された場合、電話がかかってきたり、ドアベルが鳴ったりします。現在の入力が間違っていると思われるかもしれません。
これが heuristic 'Visibility of system status'の出番です。正しいことを確認するために正しい入力が行われたときに通知が変わるはずです。
入力例を変更した後で中断された場合、エラーメッセージが表示されるという意味の例を作成しました。システムステータスの通知で、入力が正しいことがわかります。
最後のメモとして、私は以前のエラーをステータステキストに組み込んでみます（「再現ではなく認識」）。したがって、私の例では、エラーメッセージが「ユーザー名が取得されました」である間、「取得されていません」と言います。
システムがチェックを開始するフィールドに入力し始めた瞬間に、システムにキーボードを聞かせることをお勧めします。たとえば、電子メールを入力する必要があります。入力を開始すると、「@」記号を入力するまでフィールドの周囲の輪郭が赤のままになります。この方法はすでに使用されており、適用できます。画像を確認してください：
@記号の前
@記号の後
説明の場合：このアプローチをすべてのタイプのフォームに適用することはできません。これは、限られた目的で使用されるオンザフライ検証手法の1つを示すためだけです主にメールに依存する新しい求人フォームを申請するような。
銀行システムなどで使用される複雑なフォームは、このタイプの検証を使用できません。送信を押すまで保持されます。