the.field.jobs

The problem

Most employment platforms weren't built for people with disability. The ones that were felt like compliance exercises: job boards with accessibility bolted on, or government portals built for case managers rather than job seekers. the.field.jobs was a two-sided marketplace with no incumbent behaviour to learn from, no established mental model on either side, and a value proposition that only worked if both candidates and employers changed how they thought about hiring. Nobody had done this before. The UX had to do the work of making both sides believe it was worth trying.

What I did

Design lead on a short contract. End-to-end ownership of the design surface: IA, navigation, modals, profile architecture, transactional flows, UX writing, accessibility implementation, and delivery coordination. I also fed into product strategy on the monetisation model, which shaped employer onboarding directly. A significant part of the engagement was working with the tech partner to build accessibly, which meant writing requirements, testing with real assistive technology users, and pushing back hard when "it can't be done" turned out to mean "we haven't tried."

Three months. No prior research, no validated IA, no design system. A small startup team with limited runway. Accessibility wasn't a nice-to-have; the platform only mattered if it worked for the people it was built for, on day one.

Exploration

The two-sided adoption problem

This wasn't one design problem. It was two overlapping ones with different failure modes. Job seekers needed to feel safe on a platform they had no reason to trust yet. Employers needed enough structure and familiarity to act without prior experience of inclusive hiring. Those requirements pull in different directions. The design had to hold both.

What we didn't know

With no prior research and no existing users, almost everything about candidate expectations was assumption. What did people with disability want to disclose on a profile? How much control did they need over that? What would make them abandon before finishing? These were the first questions, not the last.

Early user input

A small number of sessions with people with disability before committing to an IA surfaced something important. The assumption that candidates would want to lead with their disability turned out to be wrong for most participants. Skills and experience first, with disability context available but in the candidate's control. That became the organising principle for everything that followed.

UX process

Candidate profile input

The form experience for candidates was its own design problem. Fields, dropdowns, and data entry for profile information needed clear structure, accessible input patterns, considered UX writing, and error handling that didn't make people feel like they'd failed. The order and grouping of that content mattered too: what you ask first signals what the platform thinks is important about you.

How candidate data appears to recruiters

The same information that candidates entered through a functional form needed to present as a polished, readable profile on the recruiter side. Candidates were anonymised until an employer committed to hiring, so the profile had to be useful and credible without being identifying. Recruiters could browse and search; contact was gated behind signup and purchase.

Application flow

When a candidate applied, what the employer received needed to be coherent and complete. That meant designing the application submission experience and the received application view as a connected pair, not separately.

Employer profile input

Employers had their own input surface: company profile, and a model for describing the accessible features of their workplace. That second part required particular care. It needed to be specific enough to be genuinely useful to candidates, without becoming a compliance checklist that nobody filled in honestly.

Job listing creation

Employers created and managed listings through their own flow. That surface needed to be familiar enough to reduce friction for people with no prior experience of inclusive hiring platforms, while still capturing the information that made listings useful on the candidate side.

Payment and listing management

Ad pack purchase sat inside the employer journey, with a freemium entry point (one listing per month) and paid packs beyond that. I fed into where that sales moment landed in the flow and how much friction it could carry. The listing management experience covered the full lifecycle: draft, live, closed, applications received.

Final design

Accessibility: requirements, testing, and pushback

Accessible interaction patterns were design decisions, not implementation afterthoughts. I wrote accessibility requirements for the tech partner, then tested against them with NVDA and VoiceOver. When things failed, I diagnosed why.

Modals were a good example. The assumption was that all modals would fail accessibility testing. Testing with a blind user showed exactly why they were failing: focus wasn't being trapped inside the modal, and wasn't being returned on close. Once that was understood, the pattern was solvable. The modal worked. "It can't be done" became "here's how."

Colour contrast was a different argument. The palette passed Lighthouse. I still pushed back, because passing an automated check and not giving people headaches are not the same thing. The PO needed convincing. They were convinced.

Navigation and structure

Full navigation design including keyboard behaviour, focus management, and skip navigation, built from scratch with no prior design system to inherit from.

Two views of the same data

Every piece of content candidates entered had to work in two contexts: a functional input form and a polished recruiter-facing profile. Designing both, and making sure the information architecture held across them, was one of the more considered parts of the work.

Employer experience

Skills and role-based discovery. Anonymised candidate profiles that were useful without being identifying. Employer onboarding, listing creation, application review, and listing management as a coherent end-to-end flow.

What happened

The platform launched on time, accessible, and coherent across both sides of the marketplace. Small team, no prior foundation, three months. No headline conversion metrics from this engagement. What it demonstrated: a category that didn't exist can be designed into existence, and accessibility and experience quality aren't in tension. They were the same problem.

What I learned

The early user sessions were the most important work on this project. Not because they confirmed a direction, but because they invalidated the one we were about to go with.

The accessibility work taught me that "it can't be done" is almost always a requirements problem. Write the requirement clearly enough, test with real users, show the failure mode, show the fix. That's the process.

The bigger miss was the e-commerce flow. I argued against putting upsell prompts immediately after the signup button, before employers had even filled in their details, let alone seen any value from the platform. I lost that argument. The site launched with the friction in, and it showed. For a platform asking employers to change how they thought about hiring, the sales ask needed to come after the behaviour change, not before it. Interrupting the signup flow to sell ad packs to someone who hasn't yet made an account is just optimism dressed up as a conversion strategy.

Links