PDF の履歴書は洗練されていてプロフェッショナルに見えますが、データを収集することはできません。採用担当者や人事システムが候補者に職歴、学歴、スキルを構造化されたフォームに入力する必要がある場合、フラットな PDF を送信すると不必要な摩擦が生じます。静的な PDF 履歴書を入力可能な申請フォームに変換すると、元のコンテンツを参照として保持しながら、データ収集の問題が解決されます。このプロセスには、履歴書のテキストを抽出し、それをフォーム フィールドにマッピングし、すべての応募者から標準化された情報を取得する対話型の PDF Forms ドキュメントを作成することが含まれます。
フォームを作成する前に履歴書コンテンツを抽出する
フォームフィールドを作成する前に、編集可能な形式の履歴書のコンテンツが必要です。元の履歴書に対して PDF から Word への変換を実行し、テキストを再配置可能な文書に取り込みます。出力には、候補者の名前、連絡先の詳細、日付と説明を含む職歴、教育エントリ、スキル リスト、および認定資格が含まれます。この抽出されたコンテンツは、どのフォーム フィールドを作成するか、およびドロップダウン メニューにどのラベルとオプションを含めるかを決定するための参考資料になります。
抽出されたテキストを確認して、履歴書に一般的に影響を与える変換アーティファクトがないか確認します。職歴セクションの箇条書きは、構造化されたリスト項目ではなく、単純なダッシュまたはアスタリスクとして変換される場合があります。スキルや連絡先情報の複数列レイアウトは 1 つの列に結合される場合があります。 「専門的経験」や「教育」などのセクション見出しは、書式が失われ、周囲のテキストに溶け込む場合があります。これらのアーティファクトは、セクション区切りとフィールド グループが最終フォームのどこに表示されるかを決定するため、続行する前にこれらのアーティファクトをクリーンアップしてください。
フォームフィールド構造の計画
入力可能な申請フォームには、雇用主が期待する情報と一致する論理フィールド階層が必要です。基本的なテキスト フィールド (氏名、電子メール アドレス、電話番号、郵送先住所) から始めます。これらは、すべてのアプリケーションに必要な短い単一行の入力です。ドロップダウン メニューに続いて、最高教育レベル、経験年数、就労許可ステータスなどの標準化された選択を行います。ドロップダウンにより、すべての応募者にわたって一貫したデータ形式が確保されるため、審査担当者にとってフィルタリングと比較が容易になります。
職歴と学歴のセクションには、単一の大きなテキスト領域ではなく、テキスト フィールドの繰り返し構造を使用します。役職、会社名、開始日、終了日の個別フィールド、各ポジションの簡単な説明ボックスにより、データを体系的に並べ替え、検索、エクスポートできます。すべての職歴に対する 1 つの自由形式のテキスト ボックスからは、解析や候補者間での比較が困難な非構造化データが生成されます。以下の表は、一般的な履歴書セクションを最も適切なフォーム フィールド タイプにマッピングしています。
| 再開セクション | フィールドタイプ | 理由 |
|---|---|---|
| 連絡先情報 | テキストフィールド | 短くて予測可能な入力 |
| 教育レベル | 落ちる | 標準化されたオプション |
| 職歴 | テキストフィールド + 日付ピッカー | ポジションごとに構造化されている |
| スキル | チェックボックス | 既知のリストからの複数選択 |
PDF エディターでフォームを構築する
空白の PDF または元の履歴書の変換バージョンをフォーム作成ツールで開きます。フォーム フィールド ツールバーを使用して、応募者が情報を入力する位置にテキスト フィールド、ドロップダウン、チェックボックス、日付ピッカーを配置します。予想される入力形式の例を示すプレースホルダー テキストを使用して、各フィールドに明確なラベルを付けます。 (555) 123-4567 のようなプレースホルダー テキストを含む電話番号フィールドは、形式の混乱を防ぎます。プレースホルダー YYYY-MM-DD を含む日付フィールドにより、収集されたデータの日付形式が一貫していることが保証されます。
上から下、左から右への自然な読み上げの流れに従うようにタブ オーダーを設定します。 Tab キーを押す応募者は、ページ間をランダムに移動するのではなく、名前から電子メール、電話番号へと論理的に移動する必要があります。ほとんどの PDF エディターには、フィールドを正しい順序にドラッグできるタブ オーダー パネルが表示されます。マウスに触れずにキーボードのみを使用してフォームの空のコピーに入力して、タブ オーダーを自分でテストします。 Tab キーでスキップしたり、順序を外してアクセスしたりするフィールドは、タブ オーダーの位置を調整する必要があります。
検証ルールを追加してデータ品質を向上させる
フォームフィールドの検証は、申請者がフォームを送信する前に一般的な入力エラーを検出します。 @ 記号とドメイン拡張子の存在をチェックする検証ルールを備えた電子メール フィールドにより、連絡先情報のタイプミスを防ぎます。電話番号フィールドがちょうど 10 桁に制限されているため、数字が少なすぎたり多すぎたりするエントリがブロックされます。これらの検証ルールは、申請者が送信しようとするか次のフィールドに移動しようとすると PDF ビューアで実行され、即時にフィードバックを提供します。
自動システムによって処理される Fillable PDF フォームの場合、検証は役立つだけでなく不可欠です。電話番号の 1 桁の欠落や日付の形式が間違っていると、人間が目にする前に申請書全体が申請者追跡システムによって拒否される可能性があります。検証済みの各フィールドの下に、必要な形式を説明するメモを追加して、応募者が何が間違っていたかを推測することなくエラーを修正できるようにします。
配布前にフォームをテストする
入力可能な応募フォームを 1 人の候補者に送信する前に、最初から最後まで自分で 3 回入力してください。まず、完全にフォーマットされたデータを入力して、意図したパスがスムーズに動作することを確認します。 2 番目に、検証済みフィールドに意図的に間違った形式を入力して、エラー メッセージが明確に表示され、フォームが無効なデータの送信を防止していることを確認します。 3 番目に、多くの応募者が電話で求人応募を完了するため、モバイル デバイスでフォームに記入します。キーボードでは使いやすいフィールドでも、タッチスクリーンではイライラするほど小さかったり、位置がずれていたりすることがあります。
3 つのテスト実行をすべて完了したら、送信またはエクスポート関数を使用してフォーム データを抽出し、スプレッドシートで開きます。すべてのフィールド値が正しい列に配置されていること、フィールドが重複または省略されていないことを確認します。 WukongPDF のようなツールは、単一のブラウザベースのワークフローでフォームの作成とデータのエクスポートを処理します。これにより、複数のアプリケーションを切り替えることなく、エクスポートされたデータの構築、入力、確認を迅速に繰り返すことができるため、テストが簡素化されます。
データ収集を改善するためのフォーム フィールド プロパティの構成
各フォーム フィールドには、収集されたデータを下流で使用する方法に影響を与えるプロパティがあります。フィールド名は、フォーム データがスプレッドシートにエクスポートされるときに列ヘッダーになるため、特に重要です。フィールドには記述的かつ一貫した名前を付けます。text1 ではなく applicant_first_name、field12 ではなく applicant_email です。一貫した名前を付けることで、難解なフィールド名を意味のあるラベルにデコードする別のマッピング ドキュメントを必要とせずに、エクスポートされたデータをすぐに使用できるようになります。
すべてのテキスト フィールドのフォントとフォント サイズを、周囲のドキュメント テキストと一致するように設定します。入力したテキストがラベルとは異なるフォントで表示されるフォームでは、まとまりのない、プロフェッショナルでない外観が作成されます。 PDF にフォントを埋め込むと、どのデバイスでも一貫したレンダリングが保証されます。ドロップダウン メニューの場合、モバイル画面で読みやすいように、フォント サイズを少なくとも 11 ポイントに設定します。携帯電話でドロップダウンをテストし、水平にスクロールしなくてもすべてのオプションが表示されることを確認します。
WukongPDF は、単一のワークフローでフィールドの名前付け、検証、データのエクスポートを含むフォーム構築ツールを提供します。これにより、従来のデスクトップ PDF フォーム エディターと比較してセットアップ時間が短縮されます。
モバイル応募者向けにフォームを設計するときは、電話で長文テキストを入力するのはデスクトップのキーボードよりもはるかに難しいことを考慮してください。段落長の回答を必要とする自由記述フィールドの数を最小限に抑えます。できるだけ多くのフィールドでドロップダウン メニュー、ラジオ ボタン、チェックボックスを使用します。カバーレターや関心のある声明が必要な場合は、大きなテキスト領域を提供しますが、モバイルでの入力はオプションにします。
入力可能な申請フォームを配布した後、最初の提出バッチに一般的なデータ入力の問題がないか監視します。複数の応募者がダッシュ、括弧、ドット、またはスペースを使用して電話番号を入力する場合は、すべての一般的な形式を受け入れ、処理側で正規化するようにフィールド検証を標準化します。応募者が一貫して特定のフィールドをスキップする場合は、ラベルが不明瞭でないか、モバイルのスクロール ラインの下にフィールドが隠れていないかを確認してください。
申請者がフォームの残り部分を把握できるように、複数ページの申請フォームに進行状況インジケーターを追加することを検討してください。ページ 2/5 を示すシンプルなヘッダー、または影付きの長方形で作成された進行状況バーは、応募者に完了感を与え、長いフォームの放棄率を減らします。 PDF フォーム ツールが条件付きロジックをサポートしている場合は、以前の回答に基づいてセクションを表示または非表示にし、個々の申請者にとってフォームをできるだけ短くします。
大規模な応募者プールにフォームを展開する前に、さまざまなデバイスとブラウザを使用する 3 ～ 5 人の社内テスターでパイロット テストを実施します。フィールドの明確さ、セクションの論理的な流れ、および発生した技術的な問題に関するフィードバックを収集します。 5 人によるパイロット テストでは、何百人もの実際の応募者を挫折させ、採用チームの時間を浪費するサポート リクエストを生成する可能性があるユーザビリティの問題の大部分を発見しました。
フォームを数回のアプリケーション サイクルで使用した後、収集されたデータを確認して、フォーム設計の改善を示唆するパターンがないか確認します。ドロップダウン メニュー オプションが選択されていない場合は、不要である可能性があるため、フォームを短くするために削除できます。テキスト フィールドが予期しない形式のデータを常に受信する場合は、フィールド ラベルまたはプレースホルダー テキストを明確にする必要がある可能性があります。