EHAC Course Registration Redesign

Background

The EHAC program offers online courses for both community members and hospital employees. Historically, the registration experience was fragmented: users signed up through three different pages—Community, Employee, and Spanish—with overlapping fields and no validation.

Reports generated from these registrations were filled with bad or incomplete data. Fields such as name, hospital, and location were often missing or incorrectly entered. Because these reports feed into broader program metrics and auditing, the lack of reliable data created downstream challenges for the business line.

Problem Statement

The EHAC registration experience needed to move from three disconnected pages to a single, adaptive interface that:

• Supports all course types (Community, Employee, Spanish) in one form
• Prevents invalid and incomplete submissions through validation
• Shows only relevant fields based on user type and language selection
• Produces clean, reliable data for downstream reporting and auditing

The solution needed to balance UX clarity, technical feasibility, and business reporting requirements.

Goals & Success Criteria

Goals

• Consolidate three separate registration pages into one unified form
• Reduce invalid or incomplete submissions through inline validation
• Eliminate non-essential fields to simplify the user experience
• Clarify the distinction between Community and Employee course options
• Align language options with real-world usage patterns

Success Criteria

• Single registration form successfully supports all EHAC course types
• Fewer bad records in reporting data (missing names, invalid hospitals, etc.)
• Irrelevant fields automatically disabled or hidden based on selections
• Clear differentiation between Community and Employee registrations
• Positive feedback from business stakeholders on data quality

Research & Discovery

Legacy Flow & Data Review

I began by reviewing existing course reports and the three legacy registration pages. The reports showed repeated patterns of missing fields, invalid values, and inconsistent hospital data. The UI itself did nothing to prevent this: there was no validation, no required-field logic, and no conditional behavior.

Key issues identified from the legacy experience:

• Three separate registration pages created inconsistency and confusion
• Fields like email, zip code, and country did not contribute meaningfully to reporting
• Users could self-identify incorrectly (for example, Employee vs Community)
• Hospital names and locations were manually entered and often inaccurate
• Spanish course usage for some flows was extremely low

Behavioral Observations

By analyzing patterns in the data and feedback from internal stakeholders, we inferred several user behaviors:

• Users skipped optional or confusing fields
• Community users sometimes selected Employee options
• Spanish was not needed in all flows
• Manual hospital entry increased errors

Stakeholder Collaboration

I partnered with a business line stakeholder to co-lead the redesign. Together, we defined:

• Which fields were required for reporting and auditing
• How Community and Employee workflows should differ
• Where Spanish options were appropriate

We also aligned with engineering regarding what could be handled via front-end logic.

Key Insights

1. Three separate flows caused unnecessary complexity
2. Lack of validation was the root cause of bad data
3. Several collected fields were unnecessary
4. Spanish usage did not justify universal placement
5. Hospital should drive city/state, not the reverse
6. Dynamic UI behavior could prevent invalid combinations

Solution Approach

Unified Registration Form

I redesigned the registration experience as a single unified form. Instead of directing users to separate Community, Employee, or Spanish pages, course type selection now drives the interface.

• One form for all course types
• Course type selection determines field behavior

Field Reductions & Simplification

We removed fields that did not meaningfully contribute to reporting:

• Removed: email address, zip code, country
• Removed: “identify your hospital” checkbox

This reduced user effort while keeping essential data.

Dynamic Form Behavior (JavaScript)

JavaScript logic controls how fields behave based on user choices:

• Employee: First/last name and hospital required; hospital auto-fills city/state
• Community: Hospital/city/state disabled
• Language: Employee defaults to English; Spanish only shown where appropriate
• Validation: Inline messages appear for missing required fields

Button Label & Microcopy

“Submit” was updated to “Take Course” to better communicate intent.

Requirements & Acceptance Criteria

Documentation included:

• Field requirements by course type
• Conditional form behavior rules
• Error messaging triggers
• Hospital-driven location logic

Final Design

Results & Impact

Performance & Data Outcomes

• Significant reduction in invalid or incomplete records
• Cleaner hospital/location data via auto-population
• Reporting consolidated into a single dataset

UX Outcomes

• Simpler, cleaner single-page experience
• Clearer Community vs Employee paths
• Fewer user errors due to inline validation
• Reduced cognitive load

Business Outcomes

• More reliable reporting data
• Less manual cleanup required
• Greater confidence in program metrics

Future Opportunities

• Add type-ahead hospital search
• Track error frequency to quantify usability gains
• Expand Spanish support where needed
• Integrate backend hospital verification

Skills Demonstrated

• UX and product strategy under reporting constraints
• Workflow and form redesign
• JavaScript-driven dynamic UI logic
• Cross-functional collaboration
• Requirements and acceptance criteria documentation
• Balancing UX with operational needs