Content Inventory
This page is the full list of everything a jobseeker must be able to do on jodapp.com. We describe each need as one of three kinds:
- Find something — for example, find jobs that they could do.
- Do something — for example, apply to a job.
- Understand something — for example, understand how and when they get paid.
We group these needs by frequency of use, which means how often a typical user needs each one. We use frequency to decide priority, and the reason is simple. The things people do on almost every visit deserve the most design attention and the shortest path, because a small improvement there helps a very large number of users. The things people do only once deserve to be out of the way, but they must still be easy to find when the user needs them.
We do not guess the frequency. We read it from two live sources:
- Singapore GA4 event and page-view volumes over 90 days. (GA4 is the Google Analytics product that records what users do on the site.)
- Search Console demand, which is the record of what people type into Google search.
The Google Analytics property mixes two sites: jodapp.com and the separate gig-partners.jodapp.com gig portal. Every number on this page is locked to jodapp.com. This is why some counts are smaller than the raw analytics first suggest.
Completed applications look very low here, and the reason splits into two funnels. Gig applications (about 75% of job-detail views) finish on gig-partners.jodapp.com, so jodapp.com numbers cannot see them. Careers applications finish on jodapp.com itself, and only 18 users completed one in 90 days. See the Overview and Friction Points for the full explanation.
Each item below also notes its current state. We do this so that the difference between what the user needs and what the product offers today is easy to see.
The items are grouped into five tiers, ordered from the most frequent to the least frequent:
- Tier 0 happens on almost every visit. This is the core loop.
- Tier 1 happens on most visits. This is discovery.
- Tier 2 happens occasionally. This is account and onboarding.
- Tier 3 is comprehension and trust.
- Tier 4 is rare. This is support and legal.
Design effort should follow this same order, from Tier 0 first down to Tier 4 last, because that matches how often users depend on each group.
The IA concepts behind this page
This page uses three established ideas, and one presentation choice of our own.
- Content inventory is a standard deliverable from information architecture and content strategy. It is the practice of listing every piece of content and every task before redesigning. (See Halvorson & Rach, Content Strategy for the Web.)
- Prioritising by frequency of use is long-standing interaction-design practice: the tasks people do most often should get the most design attention and the shortest path.
- "Job to be done" in the tables comes from the Jobs To Be Done framework (Tony Ulwick, popularised by Clayton Christensen). It is a practitioner framework — useful language, not proven theory (see the theory page).
- The "Tier 0–4" labels are our own presentation choice, not a standard model. The proven part is grouping by frequency; the tier numbers are only a way to show priority, and "core loop" is borrowed from product and game design.
For the full list of concepts and sources, see Theory & Method Foundations.
Frequency at a glance
Before we look at each tier in detail, this table gives the rough size of each tier, measured from Singapore usage over 90 days. It helps you quickly see which tiers carry the most user activity, so you can judge where the biggest tiers are.
| Tier | Theme | Rough weight (SG, 90d) |
|---|---|---|
| 0 | Core loop — browse, view, apply | 35,914 list views · 20,016 job views (15,032 gig + 4,984 careers) · 18 users completed an application on jodapp.com |
| 1 | Discovery — search, filter, browse | 490 searches · filters via URL params · category browse not built |
| 2 | Account — sign up, login, profile, track | 492 users on /login (jodapp.com only); /my-jobs is on the separate gig-partners site |
| 3 | Understand & trust — how it works, daily pay, insurance | 1,859 users on /help/faqs (a comprehension signal) |
| 4 | Support & legal — contact, terms, reset | low, but must exist |
Tier 0 — The core loop (every visit)
Tier 0 is the core loop, which means the four steps that define the product. Every one of these is a task that the user does, not just something the user reads.
The path from one step to the next is called a funnel. In a funnel, some users drop off at each step, so fewer people reach each following step. This funnel is the place where we either keep the user or lose them, and it decides the main business result, which is how many applications an employer receives.
On Jod there are two funnels, not one. About 75% of job-detail views are gig jobs (15,032 views by 3,334 users), and a gig application finishes on the separate gig-partners.jodapp.com site — about 4.4% of gig detail users complete there (146 users). About 25% of job-detail views are careers jobs (4,984 views by 2,646 users), and a careers application finishes on jodapp.com itself — 18 users in 90 days, which is 0.68% of careers detail users. Only 7 of those 18 users went through the full list → detail → form sequence; the other 11 landed directly on a job page or took another path. A single combined funnel hides this: its top is mostly gig traffic, and its bottom is entirely careers applications.
GA4, jodapp.com, Singapore, 90 days:
- Careers pages are identified by the
hqmiddle URL segment; every other job-detail page is gig. - Gig: 15,032 views / 3,334 users / 512 pages.
- Careers: 4,984 views / 2,646 users / 74 pages.
- Completed applications on jodapp.com: 33
generate_leadevents by 18 users, all careers. - 7 of the 18 followed the full list → detail → form sequence.
The table below lists each step, the job the user is trying to get done, the data object behind it, and where the product stands today.
| Item | Job to be done | Object / data | Current state |
|---|---|---|---|
| Find jobs | "Show me jobs I could do" | Listings::Job list, paginated | Exists (/jobs); the #1 page, but 53% leave without opening a job |
| Scan a job card | "Is this one worth a tap?" | Job card: title, company, pay, area, type | Exists, but card is weak; a paid ad slot is inserted after every 5th card (one extra item per page of 10 — no job card is removed) |
| View a job | "Tell me everything about this one" | Listings::Job detail (gig or careers view) | Exists (/jobs/{company}/{location}/{role}); dense; a paid ad slot sits above the Apply button |
| Apply | "I want this job" | Careers::JobApplication (in-app) or gig shift (off-site) | Careers: in-app but heavy (login, OTP sign-up, re-login bounce, 6-step wizard — see Tier 2); 18 users completed in 90 days. Gig: redirects off-site to gig-partners; this IA proposes retiring that handoff as the end-state, but a migration decision doc must be written first |
| Track my application | "Did I get it?" | Application status | On jodapp.com this is /talent/job-applications (only 20 users); the /my-jobs page is on the separate gig-partners site |
Tier 1 — Discovery (most visits)
Discovery is how a user takes a large list of jobs and narrows it down to the few jobs they actually want, using search, filters, and browsing. This tier happens on most visits.
This tier is the most under-built compared to the demand for it. In other words, the search data shows that users clearly want these tools, but the product offers fewer of them than that demand justifies. The table below shows each discovery tool, what the user is trying to do with it, the data behind it, and its current state.
| Item | Job to be done | Object / data | Current state |
|---|---|---|---|
| Search by role | "cashier", "dishwasher", "part time" | Full-text search_vector | Exists; when the user types a query, relevance already ranks first (newest-first applies only when browsing without a query); searches description too |
| Filter by job type | Gig vs Part-time vs Full-time | employment_type enum | Exists (checkboxes) |
| Filter by pay | "Pays enough / daily pay" | pay_from/to, pay_type | Pay range exists; "daily pay" is not a filter, even though it has the best click rate in search results (7.9% vs the 1.39% non-branded average); building it depends on an open business decision (see Tier 3) |
| Filter by location | "Near me / at this mall" | geo_area_path (ltree) | Area filter exists (region → planning area); company and outlet filters exist in the backend but not in the UI; users think in malls and outlets. All careers jobs use a placeholder outlet, so outlet filtering is real only for gig jobs |
| Browse by category | "Show me all F&B jobs" | taxonomy_category_name | Not built — category shows as a badge only. The backend column exists, but there is no filter, no index, and gig and careers emit two different category vocabularies |
| Browse by employer | "Jobs at NTUC / McDonald's" | Org::Company index | Company pages exist; 25% of search demand is employer names |
| Sort results | "Best match / highest pay / soonest" | order_by | UI offers only "Latest Created / Updated". Relevance already works behind a typed query, but there is no "Best match" label to say so, and no "Highest pay" sort |
| Get job alerts | "Tell me when new jobs like this appear" | Saved search + email (no data object yet) | Not built — no alert emails exist today; a core retention lever in the revised plan (Phase 2 distribution bundle) |
| Save a job | "Keep this for later" | careers_job_bookmarks | Exists (bookmark icon) |
- Full-text search (the
search_vectorobject) means search that matches the typed words anywhere in the text — both the title and the description — not only in the title. - Recency sort means ordering the results newest-first. On Jod today, newest-first applies only when the user browses without typing a query. When the user types a query, relevance ranks first; jobs with equal relevance resolve toward the older job.
- Best click rate in search results means the highest CTR in Google Search Console. CTR is clicks divided by impressions: how often people who see our snippet in Google click it. It measures the step from seeing to clicking, not the step from visiting to applying. "Daily pay" queries have a 7.9% click rate against a 1.39% non-branded average — 5.7 times higher. With only 18 tracked completed applications, we cannot know which search phrase converts best into applications.
- ltree (used by
geo_area_path) is a Postgres way to store a tree path — here the country → region → planning-area hierarchy.
Tier 2 — Account and onboarding (occasional)
These steps are needed so that a user can apply and can come back later, but they are not the reason people come to the site. Because of this, the goal is to make each of these steps as quick and light as possible, so that they do not block the user from the job they came for. The table below shows each account step and where it stands today.
| Item | Job to be done | Object / data | Current state |
|---|---|---|---|
| Sign up | Create an account to apply | Identities::User + Talent::Profile | Long form with a 6-digit email OTP; after sign-up the user is not logged in and is bounced back to the login form — a hidden friction |
| Log in | Return to my account | Session | Exists; the page shows two login cards stacked vertically (gig vs careers) — see the note below this table |
| Complete profile | Be eligible to apply | Talent::Profile (6-step wizard) | 3 of the 6 steps are hard gates (salary, education, skills); experiences and certificates can be skipped. Blocks first application — a major friction point |
| Track applications | See status of what I applied to | Careers::JobApplication stages | On jodapp.com about 20 users; note /my-jobs is a different page on gig-partners |
| Manage bookmarks | Revisit saved jobs | Bookmarks list | Exists |
| Link my gig account | Connect legacy JodGig identity | Account link | Exists (/talent/profile/link-gig-account) — a migration artifact |
One account model already exists. The analytics architecture docs define Principle D, "Fluid Identity": one Identities::User record carries both the gig and the careers personas. The two-login page is not a product decision. It exists only because the legacy gig-partners app keeps its own separate user records. Because the account model is already one account, the work here is to align the login UI with the documented model — not to design a new account system.
Tier 3 — Understand and trust (comprehension)
This tier is the content that answers the user's questions "why should I trust this, and how does it work?" These are not tasks the user does; they are things the user needs to understand before they feel safe to apply.
The FAQ page has high traffic: 1,859 users. (FAQ means "frequently asked questions".) This number is an important signal. It suggests that the product does not explain itself well enough inside the core flow, so users have to leave that flow and go to a separate help page to get their answers.
GA4, jodapp.com, Singapore, 90 days:
- 1,859 users viewed the FAQ.
- The number is solid; reading it as "the product does not explain itself" is a reasonable inference, not a measured cause.
The table below lists what the user must understand and where that content sits today.
| Item | What the user must understand | Current state |
|---|---|---|
| The daily-pay promise | "Work today, get paid tomorrow" | Hero copy only; not a badge on jobs — see the open decision below this table |
| Gig vs Part-time vs Full-time | Which job type am I looking at, and how do they differ? | Fragmented across brands (JodGig / JodApp / JodBoard) |
| How selection works | Apply → accepted → confirmed (gig); apply → shortlist (careers) | In FAQ, not in the flow |
| When and how I get paid | Next-day pay, GIRO, rates | In FAQ |
| Insurance / safety | Worker protection | /insurance page exists |
| Rewards | Points and vouchers for completing gigs | /rewards, /jobs/sg/jod-rewards (360 users) |
| Eligibility | SG citizens and PRs only | Implicit; should be explicit |
| Get the app | "job app", "part time job app" is strong search demand | /app page exists; under-surfaced |
No payment-timing field exists anywhere: not in jodapp-api, not in the JodGig sync, not in the target gig schema. There are two paths:
- If the business commits to the rule "every gig job pays the next day", then the badge and a daily-pay filter become a frontend rendering of
employment_type = gig. Zero backend work. - Without that rule, the badge needs a new column on the jobs table, changes to both projection builders, and a one-off backfill.
Our recommendation is to adopt the rule. Until product decides, the badge and the filter stay out of the build plan.
Tier 4 — Support and legal (rare, but required)
These items are used rarely, but they must still exist, because a user who needs them has no other way forward. The table below lists each one and its current state.
| Item | Job to be done | Current state |
|---|---|---|
| FAQ / Help | Self-serve answers | /help/faqs — heavily used (see Tier 3 note) |
| Contact | Reach a human | /contact |
| Reset password | Recover access | Exists |
| Terms / Privacy | Legal | Exists (footer) |
| About | Company legitimacy | Exists |
Adjacent content that feeds the jobseeker view
The items below are produced by the employer side, or by the operations and sales side of the business, not by the jobseeker. But they are shown on the jobseeker product, so the information architecture must plan for them. The table below lists each item, who produces it, where it appears for the jobseeker, and its current state.
| Item | Produced by | Surfaces as | Current state |
|---|---|---|---|
| Featured / promoted employers | Sales/ops (team portal) | A "Featured employers" home rail | No flag exists, and no spec exists anywhere — the spec must be written first; the company index exists to build on |
| Sponsored placements / boost | Employer (paid) | Ad slots, boosted jobs | Paid campaign placement slots exist (home_hero, job_list_inline, job_detail_inline); Google AdSense is only a fallback when no campaign is sold. Job boost needs the entitlement engine — Phase 3 of the ads billing integration |
| Company profile & logo | Employer | Company card, job card, company page | Logo + name + description exist; no verification badge |
Tier 0 and Tier 1 are the parts of the product that users depend on almost every visit, so they matter the most. Within them, Tier 1 (discovery) is the most under-built compared to the real demand for it. That is why the next three deliverables focus their attention there: