What Users Taught Us

The Hour That Changed the Product

In early February, I sat across from a contractor who was looking at our platform for the first time. He'd agreed to spend an hour with us. We had a list of tasks for him to try. Within ten minutes, I knew the roadmap was wrong.

He didn't want to post a job. He wanted to see who was out there first. "Show me what's available, then I'll decide if it's worth my time to write up the position." Every employer we'd asked the same question that month said some version of the same thing. The flow we'd built assumed they'd start by posting. They wanted to start by browsing.

That single hour rearranged the priorities in the next sprint. This post is about what real users showed us, and how we changed.

Employers Search Differently Than We Expected

Our original design assumed employers would post a job, then wait for applications. In practice, employers wanted to browse available workers before committing to a posting. They wanted to see who was in their area, with the right skills, with availability that matched their timing.

So we inverted the priority. Worker discovery became the primary employer experience; job posting became a secondary action. Employers now search by trade, filter by location and availability, and review worker profiles before deciding whether to post.

Workers Don't Fill Out Forms in One Sitting

We designed a multi-step onboarding form and expected workers to complete it start to finish. What actually happened: workers filled out the basics, got interrupted or ran out of time, and came back later — sometimes on a different device, sometimes days later.

Some workers had caseworkers or community-organization staff helping them set up profiles at events. Others started on their phones during a break between job sites.

We redesigned onboarding to be incremental. Progress saves automatically. We don't require everything up front. A reminder goes out if someone started but didn't finish. The profile became a living document that grows over time, not a gate that blocks access.

Usability Testing Changed Everything

In February we ran structured usability sessions with both employers and workers. One 90-minute session generated seven core issues — not edge cases, but fundamental problems with how people understood and used the product.

Three examples:

• The same data showed differently on two pages. A worker's availability appeared on their profile and on the search results — but the two pages calculated it slightly differently, and users noticed. They didn't know which to trust.
• A primary button and a destructive button looked nearly identical. Same shape, same weight, only the color differed. In bright sunlight on a phone, the difference disappeared.
• A label that made perfect sense to us meant nothing to users. Internally we'd been calling something a "match score." Users read it as "test score" and assumed it was something they'd done wrong.

Every issue got fixed. But more importantly, the sessions changed our development process: if a feature can't be understood by a first-time user without explanation, it needs to be redesigned.

Mobile Isn't Optional

Early usage data confirmed what we should have known: the majority of worker activity happens on phones. Our initial desktop-first approach meant every page needed a mobile overhaul — responsive layouts, touch-friendly buttons, navigation patterns that work on a 6-inch screen.

For skilled trade workers, the phone is the primary computing device. If the platform doesn't work well on mobile, it doesn't work.

The Features We Cut

User feedback also told us what to stop building. Features that added complexity without adding value. Workflows that tried to be too clever. Onboarding steps that collected data we didn't actually use in matching or display.

Cutting features is harder than building them. Every feature removed made the remaining features clearer, faster, and easier to use. The product got better by getting smaller.

Accessibility as Product Quality

We achieved WCAG 2.1 AA accessibility compliance across the entire platform. This wasn't just about doing the right thing — it was a product-quality decision. Better form labels, clearer navigation, and consistent interactive patterns improved the experience for every user, not just those using assistive technology.

Accessibility is also a business requirement. Workforce-development organizations, government agencies, and grant programs evaluate platforms on accessibility. It opens doors that a non-compliant product can't walk through.

The Lesson

You can't build a platform for skilled trade workers from behind a desk. The feedback loop — build, deploy, test with real users, learn, fix, repeat — is the product development process. Everything before real user feedback is guessing. Everything after is building with evidence.