Fifty screens on paper before a single pixel

Before drawing anything, I mapped every screen the product needs and grouped it by who sees it. Four branches: public site, job seeker, employer, and internal admin.

It came to 50 screens.

Why the count matters

That number is the honest scope. Without it, you design the six screens you already had in your head, ship a portfolio piece, and discover later that there is no interface for the thing the product actually promises.

Three examples of what only the sitemap surfaced:

The trust page. The whole positioning rests on "we verify listings". Without a page explaining what is verified, that is a slogan. It is now one of the strongest pages in the file, and the best part of it is the section admitting what is not checked.

The AI decision log. The research established that ranking candidates is a high risk system under the EU AI Act, requiring logged and explainable decisions. That obligation needs a screen. Nobody would think of it while sketching a job board.

The apply-for-me approval queue. I had argued for a capped, per-application-approved service instead of volume auto-apply. The sitemap made it obvious that this argument had no interface. The safety mechanism existed only in a document.

Grouping by audience, not by navigation

The four branches are public, seeker, employer and admin, and the split is deliberate. Screens sorted by menu structure hide the real question, which is who is allowed to see this and what are they trying to do.

It also made the paid boundary visible. Paid seeker services get a green outline on the map, and there are only four of them. Everything else is free, which is the pricing decision made visual: search, saved searches, the tracker and applying stay free forever, because charging for the basics is what kills trust in this category.

Wireframes as argument settlers

Seven grey box wireframes, four desktop and three mobile. Deliberately ugly: grey rectangles, labels in caps, fake copy drawn as bars rather than lorem ipsum, so nobody can mistake one for finished design.

The job they do is to make layout arguments cheap. Moving a filter rail in a wireframe costs nothing. Moving it after the visual design exists costs an afternoon and makes you defensive about the version you already made look nice.

Two things got settled here. The job detail page needs a sticky panel that carries the response rate and the apply action together, because those two things answer the same question: is it worth my time. And the mobile search screen needs the filter count on the trigger button, because a "Filters" button that does not say how many are active is a button you have to tap to learn anything.

The thing I got wrong

I built the sitemap, designed for a while, and then Safi looked at the file and said it felt like a lot of pages were missing.

He was right. I audited it: the sitemap mapped 50 screens and 17 were designed. I had built the interesting ones and quietly skipped sign in, create account, the empty states, the closed job state, and most of the admin product.

So I wrote a gap audit as a table, page by page, with a phase order. About 80 frames and 14 components missing. Then I worked the phases in order, components first because everything reuses them, then the employer dashboard because that is the paying customer and it was the thinnest area.

The lesson is not "make a sitemap". I did make one. The lesson is that a sitemap is only useful if you audit against it, because the fun screens will always get designed first and the boring ones are where the product actually lives.

The file finished at 82 screens.

Next: the website at two breakpoints, and what changed between them.