Navigation Hierarchy
Navigation is the set of menus and links that let a user move from one part of the product to another. It is the structure that guides the user through the product. The user relies on it all the time, even when they are not thinking about it, so we decide it carefully before we draw any screen.
This redesign follows four rules:
- Maximum 3 levels. A user should never have to go deeper than three steps in the menus to reach one thing. The three steps are named global navigation, section, and item. We explain what each of these means, with a Jod example, right after this list. If a path seems to need a fourth menu step, that is a sign it should be a search or a filter instead of a menu.
- Every label is a user word. Each label comes from the Vocabulary Lexicon, which records the exact words real users type. We do not use words from the backend or from internal corporate naming, because the user does not know those words.
- One marketplace, typed lanes. Gig, part-time, and full-time jobs live inside one single job space. They are never separate sites. The user narrows the space with job-type chips, and the chips are exactly All · Gig · Part-time · Full-time. The full reasoning for this exact set is in the "Inside Jobs" section below.
- Mobile-first. 74% of jodapp.com sessions are mobile — about 3 in 4 users are on a phone. Because of this, we design the primary structure for a phone first, using a bottom bar that is easy to reach, and we treat desktop as the wider secondary case.
GA4, jodapp.com, Singapore, 90 days:
- 74% of sessions are mobile (13,431 of 18,154).
- Search Console: 76.7% of search clicks are mobile.
- Both sources say about 3 in 4.
What a "level" means, with a Jod example
First, the word navigation means the menus and links a user taps to move around the site. It does not mean the content itself, and it does not mean a search box or a filter. A search box and a filter narrow a list of jobs; navigation moves the user between different parts of the site.
A level is one step down in these menus. We use three levels, and each one has a name:
- Level 1 — Global navigation. This is the main menu that appears on every page: the top bar on a computer, and the bottom bar on a phone. Example menu items: Jobs, Companies, How it works.
- Level 2 — Section. A section is a named group of things inside one Level 1 item. A section is not a whole page on its own; it is one part inside a Level 1 item. Example: inside Companies, there are two sections — Featured employers and Companies hiring now.
- Level 3 — Item. An item is the single, specific thing the user opens at the end. Example: the NTUC FairPrice company page.
Put together, one real Jod path looks like this:
Now the reason for the rule. If we ever feel we need a fourth level — a menu inside a menu inside a menu inside a menu — it is a sign that we are using menus to do a job that a filter or a search should do instead. For example, we should not build this as menu levels:
- Jobs, then Gig, then Food & Beverage, then Kitchen, then Dishwasher.
That path is five levels deep, and the user would get lost. Instead, "Food & Beverage" and "Dishwasher" are a filter and a search on the job list, not menu levels. The job list stays at Level 2 (inside Jobs), and the filters do the narrowing. This keeps the menus shallow, while the user can still reach a very specific job.
The IA concepts behind this page
The navigation structure uses several established ideas.
- Broad and shallow beats deep. Research on menu breadth versus depth generally favours fewer levels with more choices per level, because it is easier to find things. This is why we cap the structure at 3 levels.
- Information scent (Pirolli & Card, Information Foraging Theory) says each label must clearly signal what is behind it, so users can follow the right path.
- Keep the choice set small. Hick's Law is often cited here, but it is about choosing among known, practised options; reading a new menu is different. The breadth-versus-depth research above is the correct basis. Both point the same way: keep the global navigation small.
- Faceted classification (Ranganathan) supports treating job type as a filter inside one job space, not as a separate site.
- Thumb reach supports the mobile bottom bar. This comes from practitioner research on how people hold phones (Hoober), not from Fitts's Law itself; Fitts's Law only adds that large, close targets are faster to hit.
Note: we did not use Miller's "7±2" to limit menu size, because that finding is about memory, not navigation.
For the full list of concepts and sources, see Theory & Method Foundations.
What is wrong today
The frontend audit (the review of the current jodapp-web app) found three problems that the new structure must solve.
-
Three competing navigation layers. Every page shows three separate navigation elements at the same time:
- the top navbar
- a breadcrumb bar (a row that shows the path back to where the user is, such as Home → Jobs → NTUC FairPrice)
- a sticky bottom "pill" scroller (a row of rounded buttons fixed to the bottom of the screen that the user scrolls sideways)
Because there are three of them, the user sees three different versions of the navigation for one product, and this is confusing.
-
A fragmented brand. The navigation shows several different brand names:
JodGigJodAppJodBoardJodCareersPartner PortalGig Partners
In addition to these names, the login page shows two separate account systems, stacked one above the other as two login cards. When the user sees this many names and two logins, they think jodapp is several separate products, when it is really one product.
-
A hardcoded employer in the global navigation. The global navigation contains one fixed employer, "McDonald's Jobs". A single hardcoded employer does not scale, because it cannot grow as more employers join. A generic, scalable Companies entry belongs in that place instead, because it works for every employer.
The proposed structure
The proposed structure keeps to three levels, uses a small global navigation, and labels everything with user words. The diagram below shows the full structure: the top-level items under jodapp.com, and what sits inside Jobs, Companies, How it works, and the Account menu.
Level 1 — Global primary navigation
The global navigation is kept deliberately small, because a short list of top-level items is easier for the user to read and understand. Each label is chosen from evidence, not from opinion. The table below lists every Level 1 label, where it goes, and the evidence that justifies it.
| Label | Destination | Why this label (evidence) |
|---|---|---|
| Jobs | The one marketplace list (/jobs) | Users search "jobs"; this is the core loop, and /jobs is the most-used page (35,914 views in 90 days) |
| Companies | Browse by employer / featured employers | Employer-name queries are about a quarter of search demand (627 queries, 13,612 impressions); replaces hardcoded "McDonald's Jobs" |
| How it works | Trust & comprehension hub | 1,859 users viewed the FAQ; we read this as a comprehension gap (an inference, so directional) |
| Rewards | Points & vouchers for gigs | Existing retention driver (/rewards, 360 users) |
| Get the app | App download | "job app" / "part time job app" ≈ 4,000 impressions — enough for a Level 1 entry, not enough for a bottom-bar slot (see the mobile section) |
| Log in / Account | Auth, then account menu | Utility, right-aligned |
| For employers | Employer product entry | A single entry to the employer side of the product, instead of several separate brand names |
The hub groups the content that helps the user understand the product and feel confident in it. Its contents are exactly:
- How it works (the hub's own landing page: applying, selection, payment)
- Insurance
- Daily pay explained
- Eligibility
- FAQ
We group these under one hub, instead of placing each one separately in the top navigation. This keeps Level 1 small, and it gives the high FAQ traffic a better place to go while the user is still moving through the main flow.
About is not in the hub. The About page answers "who is this company", not "how does this product work". It stays a standalone page in the footer, under the footer's "Company" group. The screen map and the primary flows use this same hub definition.
Level 2 — Inside "Jobs" (the marketplace)
Inside "Jobs" is where the rule "one marketplace, typed lanes" becomes real. The lanes are shown as prominent type chips, not as separate navigation. A "chip" here is a small button the user can tap to filter the list. The table below lists the controls inside the Jobs list.
| Control | Options | Notes |
|---|---|---|
| Type chips | All · Gig · Part-time · Full-time | Maps to employment_type; deep-linkable as /gig/jobs and /careers/jobs for SEO |
| Quick filters | Daily pay · Category · Employer / Outlet · Pay | The four highest-value filters (see Taxonomy & Filters). The Daily pay filter is cheap only if the business adopts the rule "every gig job pays the next day" — an open business decision, detailed in that page |
| Sort | Best match · Newest · Highest pay · Soonest start | "Best match" is only a label for the relevance ranking that already runs when the user types a query — no backend change. "Highest pay" needs one new allowed sort value — a small backend change |
Why exactly these four chips. The reasoning has three steps.
- The data shows what users type. The "part time" family is the largest search demand group: 546 queries and 9,578 impressions in 3 months. No other job-type word comes close. So the page text and marketing copy must speak plain part-time language, and "Part-time" must be a visible chip.
- A chip is a filter, and a filter must match the real backend values. The
employment_typefield is an enum — a fixed list of allowed values — with the valuesgig,part_time,full_time,contract, andcasual. A chip that does not map to one of these values cannot filter anything. - Gig and part-time are different job types in our inventory. A gig job is short daily work that pays the next day; a part-time job is an ongoing job with fewer hours. Because the two types are different in the data, one combined "Part-time & gig" chip would mix two different things and filter wrongly.
So the chips are exactly All · Gig · Part-time · Full-time. "Gig" stays as the badge word for short daily-paid work, and the copy around it pairs it with plain part-time language, because "part time" is the word users actually search.
In the table above, deep-linkable means a web address that opens a specific pre-filtered view directly. For example, /gig/jobs opens the job list already filtered to gig jobs.
Level 2 — Inside "Companies"
The table below lists what sits inside the Companies section, and what each item does.
| Item | Function |
|---|---|
| Featured employers | Editorially promoted companies. No spec exists yet for the featured flag, so a short spec must be written before this is built |
| Companies hiring now | All active companies with open jobs, sortable by job count / recency (endpoint exists today) |
| Company page | One employer's jobs, grouped by outlet — matches how users search ("fairprice jurong east") |
Why the label "Companies". Users do not search the words "companies" or "employers". They search employer names directly: 627 employer-name queries with 13,612 impressions in 3 months, about 13 times more than searches for places. So there is no user word for the container itself — only for what is inside it. Because the label is a container name, we pick one clear word and keep it consistent everywhere: the navigation item is Companies, and the page title is Companies hiring now. The Vocabulary Lexicon records this pair as the recommended labels.
Account menu (utility, Level 2)
When a user is logged in, they get one single, clean menu. This replaces the current design, which splits the user's identity into a separate gig account and careers account. This is not a new idea of this IA: the analytics architecture already defines Principle D, "Fluid Identity" — one Identities::User that carries both gig and careers personas. The user has one account, so they should see one menu:
- My applications (track status — this is the main reason users come back)
- Saved jobs (bookmarks)
- Profile (edit, skills, experience)
- Log out
Mobile navigation — a bottom bar for the core loop
74% of jodapp.com sessions are mobile — about 3 in 4 users are on a phone. The core loop is the main path a user repeats: browse → view → apply → track. Because both of these facts are true, the primary mobile structure is a fixed bottom tab bar, not a hamburger menu. A hamburger menu is the menu hidden behind a three-line icon, which the user must tap to open. The bar holds the four most frequent actions; everything else goes into the hamburger.
The table below shows the four bottom-bar tabs, both when the user is logged out and when they are logged in.
| Tab | Logged out | Logged in |
|---|---|---|
| 1 | Jobs | Jobs |
| 2 | Companies | Saved |
| 3 | How it works | Applications |
| 4 | Log in | Account |
Why "Companies" gets a logged-out slot and "Get the app" does not. The reasoning has three steps.
- The data shows demand. Employer-name searches are about a quarter of all search demand (13,612 impressions), and employer searches beat place searches about 13 to 1. Browsing by employer is a frequent first-visit task.
- Our own frequency model (in the Content Inventory) places "Get the app" in Tier 3 — useful, but not one of the most frequent actions.
- A bottom-bar slot is the most valuable space in the product, so it must go to the more frequent action.
So the logged-out bar gives its slot to Companies, and "Get the app" moves to the hamburger menu and the footer.
The logged-in bar, and a bug this design fixes. The logged-in bar keeps Jobs, Saved, Applications, Account — the returning user's core loop, in which checking application status is the main reason to come back. That means Companies is not in the logged-in bar. Today this creates a real gap: a logged-in mobile user has no path to Companies at all — it is not in their bar and not in their menu. We fix this by adding Companies to the logged-in hamburger menu. Browsing by employer is a discovery task that a returning user does less often than checking applications, so the hamburger is the right place — but there must be a place.
The hamburger holds the items that are not in the bar for the current state:
- Logged out: Rewards · Get the app · About · Legal
- Logged in: Companies · How it works · Rewards · Get the app · About · Legal
The current mobile menu hides the core loop inside a hamburger menu and repeats desktop patterns on a phone. A bottom bar instead keeps the four things people do most easy to reach on a phone. This is the single most impactful mobile navigation change, and it is cheap to build.
Footer (persistent chrome)
An earlier version of this page called the footer "Level 3". That naming was wrong. A Level 3 item is the specific thing at the end of a menu path, such as one company page. The footer is not part of the menu hierarchy at all: it is persistent chrome — a fixed frame that repeats on every page. It does not take the user deeper; it repeats links that already exist elsewhere, so a user can recover from any page. The table below lists the footer groups and their links.
| Group | Links |
|---|---|
| Find jobs | Jobs · Gig jobs · Part-time jobs · Full-time jobs · Companies |
| Understand | How it works · Daily pay explained · Insurance · Eligibility · FAQ · Rewards |
| Company | About · Contact · For employers |
| Legal | Terms of Use · Privacy Policy |
| Get the app | App Store · Google Play badges |
Note that the "Understand" group mirrors the "How it works" hub exactly, and About sits in the "Company" group, not in the hub — the same rule as in the hub note above.
Brand consolidation (a naming prerequisite)
The navigation cannot be clean while the product still uses many different brand names. The table below shows the recommended way to consolidate these names into fewer, clearer ones.
| Today (fragmented) | Recommended | Rationale |
|---|---|---|
| JodApp, JodGig, JodCareers | Jod (one jobseeker brand at jodapp.com) | Gig and full-time are lanes, not brands |
| JodBoard, Partner Portal, Gig Partners | Jod for Employers (one entry) | A single entry to the employer side of the product |
| Two login cards (gig vs careers) stacked on one page | One "Log in"; account-linking handled quietly inside | Principle D ("Fluid Identity") already defines one Identities::User; the login UI must match the model we documented |
Today, gig apply still redirects to the old gig-partners.jodapp.com site, and the legacy gig accounts there are separate from jodapp accounts. Be precise about the status of this handoff: no document says it is temporary. Two documents currently make it permanent: the analytics architecture doc enforces the "Showroom (jodapp.com) / Checkout (gig-partners)" split, and the DNS domain list marks gig-partners.jodapp.com as "no-change".
This IA therefore proposes retiring the handoff as the end-state; it does not assume it. Before any issue is created for this, a migration decision doc must be written in docs/30-49-domains/35-gig/ (docs before issues). Until that decision, the IA hides the brand split from the user — one "Jod", one "Log in" — while the apply redirect stays. Do not build permanent navigation around the split, and do not build anything that assumes it is already gone.
Validation — every Level 1 label traces to evidence
Every label must trace back to real evidence, so that no label is chosen by opinion alone. The table below lists each label and the data that supports it. Note that the evidence is not the same kind for every row: some labels are justified by search demand, and some by what our inventory needs. The table says which is which.
| Label | Backed by |
|---|---|
| Jobs | GA4: /jobs is the most-used page (35,914 views); GSC: "jobs" is the base query |
| Companies | GSC: employer-name queries — 627 queries, 13,612 impressions, about a quarter of search demand and ~13x place searches |
| How it works | GA4: 1,859 users on the FAQ. The traffic is solid; reading it as a comprehension gap is an inference (directional) |
| Get the app | GSC: ~4,000 impressions for the "job app" family — enough for Level 1, not enough for a bottom-bar slot (Tier 3 frequency) |
| Daily pay (chip/filter) | GSC: best click rate in search results — 7.9% CTR (72 clicks / 910 impressions) vs the 1.39% non-branded average, about 5.7x. This measures search-snippet clicks, not visitor→applicant conversion |
| Part-time chip | GSC: the "part time" family is the largest demand group — 546 queries, 9,578 impressions |
| Gig chip | Inventory and product: gig is a real employment_type value, and "Gig" is the product's word for short daily-paid work. This is not a search-demand word |
| Full-time chip | Inventory need, not search demand: we list full-time jobs, so the filter must exist. Full-time queries had 47 impressions and 0 clicks in 3 months |