Screen Map
A screen map is the complete list of every view in the product. For each screen it records three things:
- The name of the screen.
- The function, which means the one job the screen is there to do.
- The relationships, which means the screens a user arrives from and the screens a user can go to next.
The reason we write this down before designing is simple. A screen only makes sense in relation to its neighbours. If we design each screen alone, we tend to add features that do not connect to anything, and we tend to forget the paths between screens. The screen map forces us to see the product as a connected system.
The IA concepts behind this page
- A sitemap and screen inventory is a standard information-architecture deliverable: list every screen and how the screens connect, before designing any of them.
- The keep, redesign, simplify, add, or remove labels are a form of ROT analysis (Redundant, Outdated, Trivial) from content audits, which decides what to carry forward and what to drop.
For the full list of concepts and sources, see Theory & Method Foundations.
Status labels
Every screen below has a status, so the team knows what kind of work it needs.
- Keep — the screen is fine as it is for now.
- Redesign — the screen exists but needs significant change.
- Simplify — the screen exists but is too heavy and must be made lighter.
- New — the screen does not exist yet and must be built.
- Remove — the screen should be deleted, because a better screen replaces it.
The site map
This diagram shows the main jobseeker screens and how a user moves between them. The four screens in the core loop are the ones almost every visit passes through. Important: the apply chain in this map is the new flow — the application is captured first, and the account comes after. The current product does it in the opposite order; the difference is explained under "Account screens" below.
Core loop screens
These are the screens the user passes through to reach the goal of applying. They receive the most design effort, because they carry almost all of the business value.
| Screen | Function (its one job) | Reached from | Leads to | Status |
|---|---|---|---|---|
| Home | Give a first impression and send the user into the job list, categories, or featured employers | Direct visit, Google, brand search | Job list, Companies, How it works | Redesign |
Job list & search (/jobs) | Let the user narrow a large set of jobs down to the ones they want | Home, nav, category deep-links | Job detail | Redesign |
Job detail (/jobs/{company}/{location}/{role}) | Give one job enough information to decide, and make applying easy | Job list, company page, Google | Apply, similar jobs | Redesign |
| Apply (light gate) | Verify an email or phone, then record the application immediately, tied to that verified contact | Job detail | Application submitted | Redesign |
| Application submitted | Confirm success, invite the user to finish creating the account, and offer next jobs | Apply | Finish account (sign up), My applications, similar jobs | New |
How the light-gate chain works. These four rules resolve the chain from "verified contact" to "account", so no screen is left ambiguous:
- The application is tied to the verified email or phone from the light gate. That is enough to record it and to let the employer contact the applicant.
- The Application submitted screen invites the user to finish creating the account. It is an invitation, never a wall.
- My applications requires the finished account, because it shows history and status across jobs.
- An applicant who skips account creation is not locked out: they receive email links to their application status. If they later finish the account, the applications tied to their verified contact are already there.
A note on the job detail screen. It has two variants today, because one comes from Careers::Job and one comes from Gig::TempJob. A variant is one of two versions of the same screen — here, the gig version and the careers version of the job detail page. The user should not feel this difference. Both variants show the same core information in the same order. The real difference is the apply step: a careers job has a single Apply button, while a gig job has one Apply link per shift group, and each of those links leaves the site for gig-partners.jodapp.com. This IA proposes retiring that handoff as the end-state, but the decision is not made yet — a migration decision doc in docs/30-49-domains/35-gig/ must be written first.
Discovery screens
These screens help the user find jobs by a path other than the main list. They matter because the search data shows strong demand for browsing by employer and by category.
| Screen | Function | Reached from | Leads to | Status |
|---|---|---|---|---|
Companies hiring now (/companies) | Let the user browse employers, and show a "featured employers" row | Nav ("Companies"), home | Company page | New |
Company page (/companies/{company_slug}) | Show one employer's open jobs, grouped by outlet | Companies list, Google, home rail | Job detail | Redesign |
Category landing (for example /gig/jobs) | A pre-filtered list for one category or job type, good for Google landing | Google, nav chips, footer | Job detail | New |
The navigation item is Companies and the page title is Companies hiring now — one consistent pair, used the same way in the navigation hierarchy and the flows.
A note on the current "McDonald's Jobs" screen (/jobs/mcdonalds). This is a single employer hardcoded into the navigation. It should be removed, because the generic company page covers the same need for every employer, not just one.
Two retention-critical modules (parts of a screen, not screens of their own) also belong on this map, because the flows depend on them and neither exists today:
- Similar jobs on the job detail page — gives the roughly 3 in 4 users who view a job but do not apply a next step other than leaving.
- Featured employers rail on the home page — the entry point for the employer-browsing demand. The featured flag has no spec anywhere yet, so a short spec must be written before this is built.
Both appear in the new-to-build list at the end of this page.
Account screens
These screens let the user apply and then return. The goal is to make them as light as possible, so they never block the main task.
First, the order changes. Today, the account comes before the application: the user taps Apply, must sign up (with a 6-digit email OTP), is then bounced back to the login form and must sign in a second time, and must pass a 6-step profile wizard with 3 hard gates (salary, education, skills) before the application can be recorded. In the new flow, the application comes first: the light gate verifies an email or phone, the application is recorded at once, and creating the account is an invited step afterwards. The rows below describe the screens in their new roles.
| Screen | Function | Reached from | Leads to | Status |
|---|---|---|---|---|
| Sign up | Finish creating the account after an application (from the invitation), or create an account directly from the nav | Application submitted, nav | My applications, Profile | Simplify |
| Log in | Return to an existing account | Nav, apply gate (existing users) | Where the user was before | Simplify |
My applications (/talent/job-applications) | Show the status of every job the user applied to (requires the finished account) | Account menu, confirmation screen, status emails | Job detail | Keep |
Saved jobs (/talent/job-bookmarks) | Show jobs the user saved for later | Account menu, job list | Job detail | Keep |
Profile (/talent/profile) | Hold the user's experience, skills, and details | Account menu, invitation after apply | Link gig account, Account menu | Redesign |
Link gig account (/talent/profile/link-gig-account) | Connect a legacy gig-partners account to this account | Profile | Profile | Keep |
A note on the profile setup. Today it is a 6-step wizard that the user must finish before their first application can be recorded: Talent Information (including a required salary expectation), Work Experiences, Certificates, Skills, Educations, and Confirmation. Three of the steps are hard gates the user cannot skip — salary, education, and skills; experiences and certificates are skippable. A wizard is a form split into several steps that the user must complete one after another. This blocks the application and is a major reason people leave. The redesign moves profile completion to after the application, and makes it incremental rather than one long required form. There is also a hidden friction in sign-up itself: after the OTP, the user is not logged in and must sign in again on the login form. Fixing that bounce is separate, cheap, and worth doing even before the new flow.
A note on the two account systems. Today the login page shows a gig account and a careers account as two login cards, stacked one above the other. This confuses the user. It also contradicts our own doctrine: the analytics architecture's Principle D ("Fluid Identity") defines one Identities::User that carries both gig and careers personas — the split exists only against the legacy gig-partners app. The redesign presents one login, and any account linking happens quietly in the background. The "Link gig account" page stays for that purpose, deliberately quiet: it is reachable from the Profile, not from the main navigation.
Trust and comprehension screens
These screens answer the question "how does this work and can I trust it?" The high traffic on the FAQ page shows that users have this question often, so these screens are important, even though they are not part of the core loop.
GA4, jodapp.com, Singapore, 90 days:
- 1,859 users viewed the FAQ page.
- The FAQ is the third most common landing page (2,478 sessions, 13.3% of all sessions).
- The traffic numbers are solid; reading them as "the product does not explain itself" is a reasonable inference, not a measured cause.
The "How it works" hub contains exactly: How it works (the hub's landing page), Insurance, Daily pay explained, Eligibility, and FAQ. About is not in the hub — it answers "who is this company", not "how does this work", so it stays a standalone footer page under the footer's "Company" group. The navigation hierarchy and the flows use this same definition.
| Screen | Function | Reached from | Status |
|---|---|---|---|
How it works (/how-it-works) | Explain applying, selection, and payment in one place (the hub's landing page) | Nav, footer, home | Redesign |
| Daily pay explained | Explain the "get paid next day" promise and how payment works | How it works hub | New (as a section) |
Insurance (/insurance) | Explain worker protection | How it works hub, footer | Keep |
| Eligibility | Explain who can apply (age, work pass, documents) | How it works hub | New (as a section) |
FAQ / Help (/help/faqs) | Answer common questions without contacting support | How it works hub, footer | Keep |
Rewards (/rewards) | Explain points and vouchers for completing gigs | Nav, home | Keep |
About (/about) | Establish that the company is real and trustworthy | Footer ("Company" group) | Keep |
Get the app (/app) | Send the user to download the mobile app | Nav, hamburger, footer, home | Redesign |
A note on the "How it works" hub. Today the trust content is spread across several separate top-level pages. The redesign groups it under one "How it works" hub, so that the high FAQ demand has a single, clear home, and so the top navigation stays small.
Support, legal, and exit screens
These screens are used rarely, but they must exist. They belong in the footer, not in the main navigation — except "For employers", which is also a Level 1 nav item because it is the single entry to the employer side of the product.
| Screen | Function | Reached from | Status |
|---|---|---|---|
| For employers | Send an employer out to the employer product (an exit link, not a jobseeker screen) | Nav, footer | Keep |
Contact (/contact) | Let the user reach a human | Footer | Keep |
| Reset password | Recover access to an account | Login | Keep |
Terms of Use (/terms) | Legal terms | Footer | Keep |
Privacy Policy (/privacy) | Privacy terms | Footer | Keep |
Summary of what changes
To make the amount of work clear, here is the count of screens by status.
- New screens and modules to build:
- Companies hiring now list.
- Category landing pages.
- Application submitted confirmation (with the finish-account invitation).
- Daily pay explained (as a section of the How it works hub).
- Eligibility (as a section of the How it works hub).
- Similar-jobs module on the job detail page (a module, not a full screen — retention-critical: it gives users who do not apply a next step).
- Featured-employers rail on the home page (a module — retention-critical and the entry point for the distribution product; the featured flag needs a spec first).
- Screens to redesign:
- Home.
- Job list and search.
- Job detail.
- Apply.
- Company page.
- Profile.
- How it works hub.
- Get the app.
- Screens to simplify:
- Sign up.
- Log in.
- Screens to remove:
- The hardcoded "McDonald's Jobs" page.
- Screens to keep as they are for now:
- My applications, Saved jobs, Link gig account, Insurance, Rewards, About, FAQ, For employers, Contact, Reset password, Terms, Privacy.
The order in which we do this work is decided in the Prioritization Roadmap.