Creating And Shipping Employer Onboarding UX

Certain identifying details and artifacts have been omitted or generalized to preserve confidentiality.

What I noticed

Pier’s product helped employers create an opportunity, invite candidates into an AI-assisted interview, and review structured evidence without delegating the hiring decision. Employer onboarding was therefore not one registration screen. A new employer had to sign up, enter business and role details, understand what the system accepted, create an opportunity, and know what to do next. If eligibility rules blocked submission or the interface gave no clear next action, the product could lose the employer before they reached the part that created value.

The design problem was to collect accurate information without turning Pier’s eligibility logic into a rejection gate.

At a glance

• Product area: employer signup, opportunity creation, and the path into sharing and review
• Users: first-time employers and returning employers with an existing opportunity
• Collaborator: Pier’s technical cofounder owned the core-product engineering; I owned the onboarding requirements, UX definition, handoff, partner guide, and release QA, with go/no-go and production checks shared between us
• Constraint: the system needed complete, usable data while allowing every employer to submit and routing eligibility separately
• Decision: let data-quality problems block submission, but use eligibility only to determine what happened after submission
• Artifacts: requirements specification, high-fidelity mockup link, user- flow rules, error-state designs, UX rationale, engineering handoff, partner guide, and release-QA record
• Observable result: the first-time and returning-employer paths passed release QA, the guide matched the live product, and the launch communications used the production guide

What I owned

I defined the employer-signup requirements and the information the product needed from the user. I then created the user-flow rules, routing table, error- state behavior, UX rationale, and handoff material that gave engineering one coherent implementation contract.

The central choice was simple but consequential: missing or invalid data could stop a submission; business eligibility could not. Eligibility changed the next state and message instead of rejecting the employer before the team could learn from them.

Taking the experience through release

The design artifacts were the start of the work. Before launch, I tested the experience the way partners would encounter it: a first-time employer creating an opportunity and a returning employer opening an existing one.

That QA exposed practical failures, including an out-of-market employer being rejected, broken navigation after rejection, unclear return paths, and guide language that did not match the interface. I documented the issues, worked with Pier’s technical cofounder as product fixes landed, updated the guide to the live behavior, and reran both employer paths before the release decision.

Result

The team released an employer-onboarding path that supported both first-time and returning-employer journeys. The partner guide matched the production experience, both paths passed final QA, and the guide was used in the launch communications sent to the two pilot partners.

What I learned

I learned that onboarding is product definition in motion. Requirements, routing, interface language, error behavior, and the next action all determine whether a new user can reach the value the team built. The PM responsibility is not finished when the flow is specified; it continues until the shipped experience makes sense to the person using it.