Vocabulary Lexicon
A vocabulary lexicon is a list that connects the words used inside the company to the words that real users use. Navigation and filters fail when we label things in our language instead of the user's language. When the word on a button or a filter does not match the word the user has in mind, the user does not recognise it, and so they do not click. This page solves that problem. It maps three different vocabularies to one recommended label.
The three vocabularies are:
- Backend term — what the code calls it, for example
Listings::JobandOrg::Company. - Product/doc term — what the domain docs call it, for example Talent, Gig, and Placement Credits.
- User term — what real people type into Google. This comes from Search Console, filtered to Singapore over 3 months.
The rule we follow is simple. Where a user word exists, the user interface uses the user word. Internal terms and doc terms stay internal, because the user has never seen them and does not expect them.
Search Console is the only unfiltered record of how strangers describe what they want, before they see our interface. This matters because our two data sources tell us two different things:
- GA4 tells us what users do inside our words, after they have already landed on our pages and can only click the labels we chose.
- Search Console tells us the exact words users arrived with, before our interface could influence them.
For naming, the second source is more honest, because it is not shaped by our own earlier choices.
The IA concepts behind this page
This page is built on a well-known research finding about language.
- The vocabulary problem. A 1987 study by Furnas and colleagues found that two people choose the same word for the same familiar thing fewer than 20% of the time. This is why we cannot assume our internal words match the user's words, and why we read the real words from search data.
- Speak the user's language. This is the second of Jakob Nielsen's 10 usability heuristics ("match between the system and the real world").
- Search-log analysis for finding real vocabulary is an established IA method (Rosenfeld, Search Analytics for Your Site).
For the full list of concepts and sources, see Theory & Method Foundations.
The words users actually type (Singapore, 3 months)
The table below lists the phrases people typed into Google to find us, in Singapore, from 2026-04-01 to 2026-06-30. The rows are grouped by theme and ordered roughly by demand. The table has three number columns. Impressions is the number of times we appeared in Google search results. Clicks is how many of those people then clicked through to the site. CTR (click-through rate) is the share of impressions that became clicks.
One honest limit before you read the table. CTR measures exactly one thing: how often people clicked our snippet in the Google results. It does not measure applications. In this same period the whole site recorded only 18 users with a completed application (the GA4 generate_lead event). That sample is far too small to tell which phrase turns a visitor into an applicant. So read CTR as "how well our search result matches this phrase", never as "this phrase converts to applications".
Read impressions and clicks together. When a phrase has high impressions but low clicks, there is strong demand but we present it badly in the search results. That combination is a direct instruction for what to build, because the demand already exists and we only need to serve it better.
| User phrase (theme) | Impressions | Clicks | CTR | Read |
|---|---|---|---|---|
| "part time" (546 distinct queries: part time job, part time app, …) | 9,578 | 49 | 0.5% | Biggest generic demand; high visibility, low relevance |
| "gig" / "gigs" / "gig jobs" | 3,901 | 53 | 1.4% | Real user word; strong demand, weak click rate |
| "job app" / "part time job app" | 3,983 | 25 | 0.6% | Users want an app; almost never click |
| "daily pay" / "daily cash" | 910 | 72 | 7.9% | Best click rate of any generic phrase — our differentiator |
| Employer names (627 distinct queries: ntuc, fairprice, mcdonald's, potato corner) | 13,612 | 235 | 1.7% | The single largest demand block — about 18% of all impressions; browse-by-employer is real |
| "dishwasher" / "dishwashing" | 336 | 33 | ~10% | Standout job title; high intent |
| "supermarket" | 281 | 32 | ~11% | Category-level demand with a strong click rate |
| "flexible" / "flexible part time" | 222 | 13 | ~6% | Good micro-copy for filters |
| "full time" | 47 | 0 | 0% | New offer; no organic footprint |
| cleaner / driver / warehouse / promoter | ~850 | 0 | 0% | Demand exists, zero clicks — supply or ranking gap |
Search Console, sc-domain:jodapp.com, Singapore, 2026-04-01 → 2026-06-30:
- The high-volume rows (part time, employer names, gig, job app) are a large, reliable sample.
- The single job-title rows, such as dishwasher, supermarket, and flexible, have small counts, so read those as directional.
A note on baselines, because "good CTR" needs a fair comparison. The whole-site average CTR is 3.76%, but that number is inflated by people who searched for our brand ("jodapp") and clicked at 19.8%. The fair baseline for a generic phrase is the non-branded average: 1.39%. Every CTR comparison on this page uses that baseline.
The three-language reconciliation
This is the main table for the whole page. It brings the three vocabularies together in one place, so that when you design any label you can find the concept in a single row and read across it. When you need to name something in the interface, find the concept here and use the value in the Recommended UI label column.
| Concept | Backend term | Product / doc term | User search term | Recommended UI label |
|---|---|---|---|---|
| The public job object | Listings::Job | Listing | "jobs", "job vacancy", "hiring" | Jobs |
| A short / daily job | Gig::TempJob, Gig::Job; employment_type: gig | Gig, Shift | "gig", "daily pay", "one day job" | Gig (chip + badge) |
| A part-time job | employment_type: part_time | part-time | "part time" — the biggest generic demand | Part-time (chip) |
| A permanent job | Careers::Job; employment_type: full_time | Careers, full-time | "full time" — 47 impressions, 0 clicks | Full-time (chip) |
| Next-day payment | — (no payment-timing field exists yet) | next-day pay | "daily pay", "daily cash", "get paid daily" | Daily pay (badge + filter — pending one business rule; see Taxonomy & Filters) |
| The hiring organisation | Org::Company | Employer, Company | "ntuc", "mcdonald's", "fairprice" | Companies (nav item); Companies hiring now (page title) |
| A physical branch | Org::Outlet | Outlet | "woodlands civic centre", "jurong east" | Outlet / the mall or place name |
| Job classification | Taxonomy::Category | category | "supermarket", "F&B", "warehouse", "events" | concrete names — see Taxonomy |
| The person seeking work | Identities::User + Talent::Profile | Talent, Worker, Applicant | (users don't search for themselves) | You / no public label |
| No-experience-friendly | is_no_experience_required | — | (implied by "no experience") | No experience needed (chip) |
| Employer spend | billing_entitlements | Placement / Gig Credits | (n/a — employer side) | employer-only, not on jobseeker UI |
The job-type filter chips are exactly All · Gig · Part-time · Full-time, matching the real backend employment_type values. Here is the reasoning. Users search "part time" far more than any other generic phrase (9,578 impressions), so page copy and marketing text should pair "gig" with plain part-time language. But gig and part-time are different job types in our inventory, and a filter must return exactly what its label promises. So the copy speaks the user's words, and the chips match the data. This replaces the older recommendation on this page of a single combined "Part-time & gig" lane.
One honest point about the Full-time chip: its evidence is inventory need, not search demand. We list full-time jobs, so the filter must expose them. The search data does not justify it on its own — "full time" had 47 impressions and 0 clicks in 3 months.
The docs use several different words for the same one person. These are:
- Talent — the profile.
- Worker — while the person is on a gig.
- Applicant — after the person has applied.
Using different words for this person is fine internally, but the jobseeker UI should not make the user learn these words. In the jobseeker interface, address the user as you. Use the word Applicant only in the employer view, where it is the natural word for the employer to read.
Adopt these exact words
Each recommendation below uses a word that the search data has already proved. Where a number is given, that number is the reason to trust the change.
- Lead with the user's words: pair "gig" with plain part-time language in page copy. The data: "part time" is the biggest generic demand phrase, with 546 distinct queries and 9,578 impressions in 3 months. "Adhoc" and "ad hoc" together appeared in exactly 1 query, with 1 impression and 0 clicks. Because users type "part time" and almost no one types "adhoc", headlines and page copy must lead with "part time" and "gig", never with "adhoc" or "on-demand manpower". This is the single biggest naming correction on the whole page. One boundary: this rule is for copy, not for the filter. A combined "Part-time & gig" filter chip would mix two different
employment_typevalues, and a filter that returns something different from what its label says breaks trust. The filter chips stay exactly All · Gig · Part-time · Full-time — see the note above. - Make "Daily pay" a first-class label. A first-class label means the product treats the phrase as a real, built-in feature: a badge on the jobs that qualify, and a filter. The data: "daily pay" earns a 7.9% CTR (72 clicks from 910 impressions), against the non-branded average of 1.39% — about 5.7 times better than a normal generic phrase. (We do not compare against the whole-site average of 3.76%, because brand searches at 19.8% CTR inflate that number.) One honest limit: this is the best click rate in search results, not proof of application conversion — with only 18 completed applications site-wide we cannot measure which phrase leads to applying. The decision stands on the click data plus consistency with our main promise, "Work today, get paid tomorrow". The badge and filter also need one business decision before they are cheap to build — see Taxonomy & Filters.
- Use "Flexible hours" as micro-copy. Micro-copy means the short helper words that sit on a filter or a card. "Flexible" phrases click at about 6% CTR (13 clicks from 222 impressions), roughly four times the non-branded average. The sample is small, so treat it as directional — but it is a safe, cheap word to use on filters and gig cards.
- Reinforce the app. The phrase "job app" has about 4,000 impressions, which shows that users are explicitly looking for an app, not only a website. Show "Get the app" prominently, because the intent is already clear.
- Add a "Browse by employer" entry point, labelled "Companies". The data: employer-name queries are 627 distinct queries with 13,612 impressions and 235 clicks — the single largest demand block, about 18% of all impressions. The top organic landing pages are all NTUC FairPrice and McDonald's outlet jobs. (An organic landing page is the first page a person reaches from unpaid Google results.) The logic: users arrive by employer name, but nobody searches the container words "companies" or "employers" — so the container label cannot come from search data; we simply pick one clear word and keep it consistent everywhere. The decision: the navigation item is Companies, and the page title is Companies hiring now.
- Use concrete job-title words as browse chips and category names. A chip is a small tappable button that runs one search or applies one filter, for example a "Dishwasher" chip. These plain words match how users describe the work. The words to use are:
- dishwasher
- cashier
- supermarket
- barista
- pantry
- catering assistant
- packer
- medical escort
- food packing
Fix these mismatches (our word ≠ their word)
The table below lists the places where our word does not match the user's word. Each row names where the mismatch appears, the word we currently use, the word the user uses, and the action to fix it. A mismatch matters because the user does not recognise our word, so they either miss the feature or leave the page.
| Where | We say | They say | Action |
|---|---|---|---|
| Core positioning | "adhoc / on-demand manpower" | "part time", "gig", "daily pay" | Rename the offer; lead with user words |
| Location filter | Region / planning area / subzone (geo_area_path) | Employer names, mall and outlet names ("woodlands civic centre", "jurong east"), "near me" | Filter by employer + outlet/mall, not administrative region |
| Job titles / meta | outlet role names (e.g. "RA cashiering") | "cashier", "job vacancy", "hiring" | Add plain-language and "vacancy/hiring" terms to titles and meta |
| Full-time discovery | assume organic search will find it | "full time": 47 impressions, 0 clicks in 3 months | Full-time needs internal cross-linking, not reliance on organic search |
| Search box placeholder | "Search by Title, Category, Company, Location or Description" | (users just type a role) | Stop advertising the naive full-text behavior; suggest real terms instead |
Here, "naive full-text behavior" means the search matches the typed words anywhere in the text — such as the title and the description — not only in the job title.
An earlier version of this page called this claim directional. The full 3-month Search Console pull (Singapore, 2026-04-01 → 2026-06-30) made the employer-level claim strong. Here is exactly what the data shows:
- Employer-name queries: 627 queries, 13,612 impressions.
- Specific place, outlet, or mall queries: 139 queries, 1,033 impressions. Examples: "fairprice jurong east", "jobs at woodlands civic centre", "seletar mall".
- Broad administrative regions on their own (for example "jurong jobs", "tampines jobs"): 3 queries, 4 impressions. Essentially nobody.
- "near me": 173 queries, 524 impressions. When users express closeness, they say "near me" — they do not name a planning area.
The logic: employer beats place by about 13 to 1 on impressions, and broad regions are almost absent. So the claim "users start a location search from the employer, not from an administrative region" is now tagged strong. It also means our geo_areas administrative tree (5 regions, then 55 planning areas, then 332 subzones) is not how a jobseeker starts.
One honest caveat stays, at the outlet level. The top organic landing pages are employer-plus-outlet pages partly because those are the jobs we actually have. This is a supply effect: the landing-page pattern may reflect our own supply, not only user preference. So "users specifically want outlet-level browsing" is still partly confounded, and should be confirmed with on-site location-search analysis and tree-testing (see Theory & Method Foundations). The employer-level conclusion does not depend on the landing pages, so it stands on its own.
The design decision: make employer + outlet the primary location entry point, and keep the region tree as a coarse fallback.
Words with demand but zero clicks (a supply or ranking check)
The words below get impressions but no clicks at all. There are two possible reasons for this. Either we have no matching jobs to show, or our pages rank too low in Google because the page titles do not match the phrase the user typed.
The words are:
cleanerdriverwarehousepromotereventpackerjob portaljob boardfairprice hiring
Action: for each word, first confirm whether we have the supply, meaning whether we actually have jobs that match it.
- If we do have the supply, then it is a ranking or title problem, and the fix is to correct the page meta and add internal links.
- If we do not have the supply, then we either reduce how much we feature the word in navigation, or we treat it as a category where we should go and recruit that supply.
This list is a direct input to the Taxonomy decisions.