Loan Application Form That Loses Applicants

The current one-section form forces every applicant to see all 62 fields at once, including fields that are irrelevant to their situation. I would restructure into stages or steps and use progressive disclosure.

Proposed structure:

• Applicant details, Employment, Collateral, Disclosures, Review and Submit.
• Put the eight disclosure fields in the Disclosures step, not scattered across the form. They remain mandatory where regulation requires them, but they appear after the applicant has committed to the application.
• Use conditional visibility: if the loan is unsecured, skip Collateral entirely; if employment status is retired, show retirement income fields instead of employer fields. This reduces perceived length and actual data entry.
• Use address lookup and derivation to reduce fields. Do not ask for data that can be retrieved from a data page with consent.
• On mobile, use a single-column responsive layout, large touch targets, and one question group per screen. Provide Save and Resume with a clear return link.
• Use a review step that summarizes answers and links back to edit, rather than making applicants scroll a long read-only page.

Constellation is worth evaluating because its responsive templates and accessible components reduce custom UI risk, but the decision should be based on component coverage for date entry, disclosures, and save/resume. The structure matters more than the theme.

I would treat accessibility as a release gate, not a cleanup task after the new fields are added.

Plan:

• Fix the keyboard trap in the custom date picker first. Either replace it with an accessible Pega date component or correct focus management so Tab and Shift+Tab can enter and leave the calendar. Keyboard traps are a severe blocker.
• Fix color contrast on error text and any other text that fails 4.5:1 for normal text. Do not rely on color alone to indicate errors; add text and an icon with an accessible name.
• Audit labels, error identification, focus order, and name/role/value for custom controls. Ensure every field has a programmatic label and every error is announced and linked to the field.
• Test with keyboard only and at least one screen reader on the supported browser set. Automated tools catch some issues but not focus traps or reading order. Before adding the eight disclosure fields, the critical issues, especially keyboard traps and contrast, must be closed. New fields add more labels, errors, and focus targets; adding them on top of known failures increases risk and makes regression testing harder. The disclosure fields should inherit the same accessible pattern and be included in the accessibility acceptance criteria.

I would use the same application case and form, with an explicit assisted-channel context, rather than a separate contact-center case type.

Design:

• Capture two identities on the case: the applicant and the operator completing the application on their behalf. Do not overwrite the applicant with the operator ID.
• Add a caller verification step before the contact center can view or edit applicant data. Record consent and verification method for audit.
• Use the same stages and validation so the contact center does not bypass regulatory disclosures or income checks. The difference is the channel and the operator context, not the business logic.
• Use access roles to restrict who can act on behalf of a caller and which fields they can change. The contact center should not be able to alter verification results after submission.
• Save and resume must work for both channels. If the caller starts on mobile and calls in, the contact center should retrieve the same case by a secure reference, not create a duplicate.
• Audit views and changes by operator ID, with timestamps, and restrict audit access to authorized staff.

This avoids form duplication and keeps one source of truth for the application while making the assisted channel explicit and auditable.