Employer job form (/employers/careers/jobs/create)

The screenshot shows the form before the category picker shipped; where the picker changes a finding, the text says so. This is a functionality-side product in Garrett's duality: the employer is here to complete a task, not to read.

Plane 1 — Strategy

User need: an ops manager (Creative Eateries, FairPrice, McDonald's outlet level) wants applicants for one role, fast, with as little writing as possible. Many of our employers read English as a second language — the same plain-language bar we hold for seekers applies to them.

Business need: structured, complete listings. Every structured field (category, pay range, benefits flag) becomes a search filter, a badge, and SEO data on the marketplace side. The trial-ended banner in the screenshot is a reminder that this screen also carries the conversion moment for paying customers.

Where they conflict: completeness costs employer time. The form currently resolves the conflict well in one place (previews show why a field matters) and poorly in another (nothing can be saved as a draft — an interrupted employer loses everything). That gap is a strategy-level finding, not a layout problem.

Plane 2 — Scope

What the form collects today: title (48 chars), company, employment type, job category, summary (200 chars), optional requirements and benefits (one per line), description, address area + full address, pay type, currency, pay-shown flag, pay range.

• Strength — the previews are scope made visible. The right column renders the seeker-facing ListingsJobListView and CareersJobDetailView live. The 48-char title limit stops titles that would truncate in the list card. This is the correct way to justify a field limit: show the container it must fit.
• Gap — no draft, no duplicate. Employers who post the same role across outlets (FairPrice pattern) retype everything. "Duplicate from an existing job" is likely the single largest time-saver we could add, and it is pure scope — no new page needed.
• Gap — free-text requirements and benefits. One-per-line text is easy to enter, but it is where the double-bullet and dash artifacts on the detail page come from (see Job detail page). We keep the free-text scope decision, and fix it at render time.
• Open question — closing date. The detail view can render "Closes on …", but the form never collects a closing date. Confirm whether this is deliberate before the redesign locks the field list.

Plane 3 — Structure

Section order: Overview → Details → Address → Pay, single long page, previews fixed on the right.

• Strength — the category picker (shipped after the screenshot). The old dropdown hid the category list behind a click; the taxonomy research showed employers could effectively see only 10 of 89 options. The new TaxonomyCategoryPickerField (PR jodapp-web#1311) shows every category as a two-column grid of radio buttons. In interaction-design terms this converts recall into recognition — the employer picks from what they can see instead of guessing what to search. This is the pattern the rest of the form should learn from: when a choice set is small and fixed, show all of it.
• Question — is Pay last on purpose? Pay is the strongest filter on the seeker side and the field employers most often hesitate on. Placing it last means the employer meets the hardest decision when their patience is lowest, and the previews have shown placeholder pay values ($1,000 - $2,000) all the way down. Worth an A/B or at least a prototype with Pay directly after Overview.
• Strength — previews as a feedback loop. The employer sees the seeker's view while typing. This teaches the seeker's mental model without a single line of instruction. Keep it; several skeleton fixes below exist to protect it.

Plane 4 — Skeleton

This is where the form fails its users today — quietly.

• Broken feedback, already ticketed (jodapp-web#1318):
  • The character counter never turns red when the employer goes over a limit (#1315). The 0/48 and 0/200 counters exist precisely to give this feedback.
  • Checkbox validation messages never display — the checkbox turns red with no explanation (#1316).
  • The preview pay line can read $1,000 - $2,000 undefined on the defaults path (#1314). A broken preview undermines the form's best feature.
• Microcopy needs one editing pass. Verbatim strings from careers-job-form-fields.jsx: "Shown in it's own section", "Drag the btm right corner to show expand this text box". For non-native readers, broken grammar is not cosmetic — it adds parsing work exactly where we are asking them to follow an instruction. One pass, one PR.
• One submit button, bottom-right, non-sticky. On a failed validation at the top of a long page, the employer is left at the bottom with a button that appears to do nothing. Verify what actually happens on submit failure (does focus move to the first error?), then decide between a sticky action bar and an error summary at the submit point.
• Mobile is unaudited. The two-column preview layout must collapse on small screens; nobody has documented what the form looks like there. Screenshot it before the redesign starts.

Plane 5 — Surface

• The form is Bootstrap-default almost everywhere; the brand appears only in the primary button and the active nav item. That restraint is fine for a work tool — but section headings ("Overview", "Details") have nearly the same visual weight as field labels, so the page reads as one undifferentiated column. The design system's heading scale (Plus Jakarta Sans) gives us the fix for free.
• The trial-ended banner (danger pink, top of page) outshouts the task. If the banner must persist, move it to a quieter style once acknowledged — the employer posting a job is the conversion behaviour we want; interrupting it works against the banner's own goal.

What to prototype in Claude Design

All of these use components already in the Jod Design System: CareersJobForm, CareersJobFormFields, TaxonomyCategoryPickerField, TextField/TextareaField (error and counter states), ListingsJobListView (preview card).

1. Pay section moved directly after Overview.
2. Sticky action bar with submit + validation summary.
3. Section headings on the design-system heading scale.
4. The mobile layout of form + previews.