ヘルプテキストは入力の上または下にあるべきですか？
「ヘルプテキスト」の一部のバリアント、つまり見出し、ラベル、およびプレースホルダーを補足するテキストをサポートするフレームワークは多数あります。フィールドの目的が複雑であるか不明確である可能性がある場合に、その目的を簡単に説明するためによく使用されます。
これの一例は、次に示すBootstrapのヘルプテキストです。
別の例は、以下に示すDjangoのヘルプテキストの例です。
これが現在の実装で、入力の補足テキストaboveがあります。
ここでの質問はヘルプ/補足テキストは対応する入力フィールドの上または下にある必要がありますか？
あなたの場合、それは上になるはずですが、フォームの再設計を検討してください
通常、フォームは全体のワークフロー（フォーム）をマイクロワークフロー（各フィールド）に分割して表します。
これは、フォームのレイアウト方法に関して多くの決定を下すのに役立つため、フォームUXについてシンプルでありながら強力な考え方です。
まず、全体的なワークフローを明確にする必要があります。これが、通常フォームが垂直に編成され、フローがユーザーに明確になるように（上から下へ）理由です。ユーザーはフォームをナビゲートする方法を示していない（横にまたがって、下に、次に横に？）ため、フォームは2x2マトリックスでフィールドを編成します。これはアンチパターンです。
![enter image description here]()
- ユーザーがフォームをナビゲートする方法についての手掛かりが得られるように、フィールドを垂直に整理する（より良い）か、ラベルを付ける（1,2,3,4）ことにより、全体的なフローを改善することを検討してください。エントリの順序が重要ではない場合でも、フローはstillが重要です。これは、ユーザーがそれを知らないためです。
ワークフロー全体を整理したら、各フィールドをmicro-workflowと考えます。
- フィールドには長いラベル（ "ヘルプテキスト"と呼ばれるもの）とプレースホルダーがあります。これは、1つのフィールドに入力するためだけに、大量の認知的負荷をユーザーに提示します。ユーザーは長いキャプションを読む必要があります。次に、フィールドを調べてプレースホルダーを読み取り、そのプレースホルダーを先ほど読んだラベルに関連付ける必要があります。彼はフィールドに入力する必要があります。
- これをしないでください！。代わりに、マイクロワークフローを達成するための最良の方法を考えてください。ユーザーは、フィールドの機能を理解し、フィールドに正確に入力する必要があるだけです。
- つまり、ラベルまたはプレースホルダーを使用することをお勧めしますが、両方は使用しないでください。
- 長いラベルが本当に必要な場合は、フィールドを空白のままにします。これにより、明確なマイクロワークフローがユーザーに表示されます。ラベルを読んでから、空白のフィールドに入力します。
マイクロワークフローの観点から考えると、配置の問題ははるかに簡単になります。フォームが上から下に整理されている場合は、フィールドマイクロワークフローを上から下に向けることも意味があります。つまり、上にラベルを付けると下の入力ボックス。
ちなみに
マイクロワークフローモデルは、ラベルとプレースホルダーの両方を使用してフィールドを設計する場合にも役立ちます。マイクロフローは次のとおりです：1. understand the field、次に2. fill it in、これは、フィールドの説明にラベルを使用できること、および記入方法]を説明するプレースホルダーを使用できることを示しています：
ヘルプテキストが常に入力フィールドの後に表示される主な理由は、人々がヘルプを検索するためです何かがうまくいかない場合のみまたはわかりにくい。他の例と、ヘルプボタンが配置されている場所について考えてください。
通常、テキストは無視され、人々は自分にとって重要と思われるものだけを読んでいることが知られているため、これらのフィールドに入力する人は、最初に試用版とエラー版のプロセスを通過します。
人々がほとんどのフォームを取得できない場合、それはあなたがすべて間違ってしまったことを意味し（フォーム自体）、自明ではないか、ラベルのテキストが混乱しています。たくさんの友達やユーザーといつでも基本的なテストを行うことができます。
フィールドのヘルプテキストは、誰かが何かを入力し、最終的に期待される結果（関連性がない、エラー、タイプの詳細など）が得られない場合に使用する必要があります。
あなたのものはヘルプテキストの典型的なケースです-それはcomplementaryです。
補完的な要素
補足とは、フィールドの性質を短く一般的な方法で示す別の視覚要素（ラベル/プレースホルダー）があり、ヘルプテキストが長くて詳細な説明を提供することを意味します。
あなたの例では、（ラベルがあまり明確でないため）初めてユーザーがテキストを必要とするようですが、経験豊富なユーザーは必要ありません（ラベルの意味をすでに知っています）。
すべての経験豊富なユーザーが必要とする、より短い説明を提供する別の要素があるため、テキストafter the fieldを持つという強い議論があります-経験豊富なユーザーには邪魔になりませんですが、初めてのユーザーでも簡単に見ることができます。
アクセシビリティ
ただし、フィールドの後にヘルプテキストを配置する場合の問題は、スクリーンリーダーがユーザーがフィールドに焦点を合わせた後にのみ表示されることです。
これは、ラベルまたはフィールドにタイトルまたはaria-label属性を指定することで簡単に対処できます。
段階的開示
経験豊富なユーザーがこのフォームを使用する可能性が高い場合、ホバー/クリック時にヘルプテキストを提供する疑問符を付けるなど、このヘルプテキストを「オンデマンド」にするか、またはフィールドがフォーカスされている（タイトルまたはツールチップ）。これは視覚的なノイズを節約します。
プレースホルダーとラベル
ユーザーがテキストの入力を開始すると、プレースホルダーは消えますが、ラベルは消えません。
プレースホルダーは、single-visitタイプのフォームに適しています。つまり、ユーザーはフォームに入力し、再び入力したフォームに戻ることはありません。ログインページと登録ページはそのような例です。
ユーザーがフィールドフォーム（「曲の詳細の編集」など）に再度アクセスできる場合は、プレースホルダーとは異なり、ラベルが表示されます。
それは本当にユーザーが何を望んでいるかに依存します。フレームワークはそこから入手できますが、UXデザイナーとして、設計しているユーザーグループについて、およびユーザーテストの後にユーザーグループがそれに慣れているかどうかを知る必要があります。
フィールドの外側のプレースホルダーテキストは常に表示されますが、フィールドの内側のテキストは消えるか、場合によってはユーザーが削除して書き込む必要があります。これは、フィールド内のプレースホルダーテキストの欠点の1つです。
フォームフィールド内のプレースホルダーテキストは、フィールドに含まれる情報を覚えたり、エラーをチェックして修正したりすることを困難にします。また、視覚および認知障害のあるユーザーに追加の負担がかかります。
あなたはもっと知ることができます http://www.nngroup.com/articles/form-design-placeholders/
ヘルプテキストは初心者ユーザーにとって非常に重要であり、フォームフィールドが本当に複雑な場合は、すべての人に必要です。適切な設計は、「フィールドとともにヘルプが利用可能な場合」です。推奨テキストは、入力するデータの種類をユーザーに示す「ヘルプ」の一種でもあります。フォームフィールドの例を以下に示します。 
ヘルプテキストは入力フィールドの下にある必要があります。この方法では、ユーザーは入力フィールド内のラベルとヒントテキストをスキャンするだけでよいので、認知的負荷が軽減されます。これらが十分でない場合、ユーザーは入力フィールドの下をさらに読むことができます。 
入力フィールドの下に配置することで、必要に応じてデータ検証のための自然な配置も提供されます。データ検証テキストは、ヘルプテキストを冗長にする追加の説明です。
この例には、必要なフォームのレイアウトに応じて、2つの対話オプションが含まれています。
「ヘルプテキスト」がフィールドの上と下のどちらにあるかは重要ではありませんが、確認する必要があるのは、説明しているフィールドに近いということです。簡単に言うと、ユーザーが「ヘルプテキスト」がどのフィールドに関連しているかを認識できれば問題ありません。複雑にしないでおく。
ヘルプテキストは
- あなたが本当に必要なものであること（多くの場合、それは必要ではなくむしろ習慣から追加され、フォームを散らかして複雑にするだけです）
- 来る前後ではなくフィールド（結局のところ、フィールドへの入力にヘルプが必要な場合は、フィールドに到達する前にその情報を読む必要があります）
- ラベル自体に組み込む。これが最も直接的でアクセスしやすい場所だからです。
ですから、あなたのやり方は完璧だと思います。
変更のために切り替えないでください
上記の表示に慣れているユーザーベースがある場合、変更を主張するのは困難です。これによって理解力が大幅に向上するわけではないので、標準を切り替える前に多くのユーザー検証を行う必要があります。
OTOH、ノーマルがいい
一般の人々にとっては、フィールドの下がより一般的な標準であり、おそらく新しいユーザーの方が学習をあまり必要としません。多くの新しいユーザーを呼び込むことを計画していて、ユーザーの検証で既存のベースが比較的簡単に調整できることがわかった場合は、より一般的なアプローチを採用します。
ヘルパーテキストは、実際のフィールドの上にある必要があります。ユーザーは、入力する前に、入力内容を知る必要があります。これは、ユーザー側での複雑な視線管理を回避するためです。
トップダウンの読み取りフローもより自然に感じられ、広く採用されています。
あなたはこの同じトピックに関するこの素晴らしい記事をチェックしたいと思います： http://uxmovement.com/forms/why-infield-top-aligned-form-labels-are-quickest-to-scan
それはすべてhelpと役立つヒントまたは補足の間のコンテキストに帰着します。
- 必須のデータやラベルであれば、上記は明確であり、垂直階層に準拠しています。
- それがフィールドの上にラベルが付いた電話番号のような明らかなヒントである場合、infieldはスペースを節約します（特に電話の場合）。
- 簡単な例で、より大きなフィールド（おそらく複数の回答がコンマで区切られたもの）でユーザーにボールを転がさせることができる場合は、フィールドの下または右側に役立つでしょう。