Information Architecture — Jobseeker Marketplace Redesign
This section defines the structure of the jodapp.com jobseeker product before any screen is drawn.
Information architecture (IA) is the plan that decides four things:
- What content and features exist in the product.
- What each one is called (the labels the user reads).
- How they are grouped together.
- How a user moves from one part to another.
Most redesigns do not fail because the colours or spacing are wrong. They fail because nobody questioned this underlying structure before opening a design tool. So we question it here, first, and we write the answer down before we design any screen.
This is an architecture document, not a visual design. You will not find colours, spacing, or components here. You will find structure, labels, grouping, and flow. Every decision below is checked against three kinds of ground truth:
- Real Singapore usage data — what users actually do on the site.
- The backend domain model — what the system can actually serve.
- The product docs — what we have decided to build.
When these three disagree, we point out the disagreement, because that gap is usually the exact place where the product is broken today.
The big picture (a map of this section)
Before the details, here is the whole section as one map. It works like the billing-layers diagram: each stage of the work is a labelled layer, and each layer is expanded to show the deliverables inside it. Read it from the top down: the top layer is the foundation — the evidence and the theory that every stage below is built on — and beneath it are the four stages of work, in order. Every deliverable links to its own page, so you can also use this map as a table of contents.
Read the layers from the top down. First the foundation (the evidence and the theory) supports everything. Then Stage 1, understand the content and the words users use. Then Stage 2, design the structure of navigation and filters. Then Stage 3, design the journeys through the screens. Finally Stage 4, decide what to fix first.
Every method in this section is grounded in established IA theory. The full catalogue of concepts, their sources, and an honest note on what is proven versus what is our own presentation choice, is in Theory & Method Foundations. Each deliverable page also has a short "The IA concepts behind this page" panel that you can open on demand.
The evidence base
Every claim in this section can be traced back to one of five studies that were run at the same time. All the analytics are filtered to Singapore only. Jobs on jodapp are open to Singapore citizens and PRs, so traffic from other countries is not a real user and would only add noise to the numbers.
| Source | Scope | Date range | What it tells us |
|---|---|---|---|
| GA4 product analytics | jodapp.com, Singapore only | 2026-04-02 to 2026-06-30 (90 days) | How users move through the site, where they leave, and which device they use |
| Google Search Console | sc-domain:jodapp.com, Singapore only | 2026-04-01 to 2026-06-30 (3 months) | The exact words users type into Google to find us — our real vocabulary |
Backend audit (jodapp-api) | Rails domain model and database | Current main branch | What data and features exist to power browse, search, and filters |
Frontend audit (jodapp-web) | React Router app | Current main branch | The current structure as it is today: routes, labels, filters, and the apply flow |
Product docs (docs) | Domain, billing, and board-web docs | Current main branch | The canonical vocabulary, the plan to merge the products, and the monetization plan |
The development database contains seed jobs, not real production jobs. Because of this, we never guess demand or popularity from the jobs table. Demand comes from two live sources instead:
- Search Console tells us what people search for.
- GA4 tells us what people engage with.
The database is used for one narrow purpose only: the supply-side vocabulary, which is the fixed set of categories the system is able to attach to a job.
Evidence strength tags
Not every claim in this section rests on the same amount of evidence. Some claims are backed by large, clean data. Some rest on a small signal that could have another explanation. Some are reasoned judgements that we have not measured yet. To make this clear, the key claims in this section carry a small coloured box, placed right after the claim, that names the strength and shows the proof. The three levels mean:
- Strong — backed by a large amount of data from one clean source, or a fact we checked directly in the code or the docs. It is safe to build on this directly.
- Directional — a real signal, but from a small sample, or with a possible second explanation. It points in a direction, but we should confirm it with a cheap test before it drives the build.
- Assumption — a reasoned judgement based on good practice or on logic, which we have not measured in our own data. Treat it as a hypothesis to test.
Here is what each of the three looks like in use:
These boxes describe how strongly our data supports a claim or finding. They are a different thing from the status labels in Theory & Method Foundations, which describe how well established an IA method is. A claim with no tag is usually background, or a decision that has already been made, rather than a data finding.
The simple rule: build first on the strong claims. Send the directional and assumption claims to a quick validation step before you invest heavily in them.
The core thesis
Four findings change how we should think about the whole redesign. If you read nothing else on this page, read these four.
Finding 1 — The biggest drop-off is on the job list, and the funnel is really two funnels
The /jobs list is the most-used page on the whole site. In 90 days it received 35,914 views from 2,886 users, and each user spends about 3.7 minutes on it. It is also the page where we lose the most people:
- 53% of the people who reach the job list never open a single job.
- On desktop this is even worse: 67% open no job at all.
GA4, jodapp.com only, Singapore, 90 days:
- Of 3,011 users who reached the list, only 1,417 opened a job.
- 53% opened none.
- 67% opened none on desktop.
The home page is a smaller opportunity than it first appears, because most users do not start there. Of the 18,671 jodapp.com Singapore sessions in 90 days, only 27.8% begin on the home page (5,199 sessions). The rest enter elsewhere: 25.2% land directly on a specific job-detail page (4,707 sessions, arriving from Google search and Google-for-Jobs links), 13.3% on the FAQ page (2,478 sessions), and 10.3% on the /jobs list (1,927 sessions). So 72.2% of sessions do not start on the home page, and direct entry onto a single job page almost equals the home page.
GA4, jodapp.com only, Singapore, 90 days:
- Of 18,671 sessions, 27.8% start on the home page and 72.2% start elsewhere.
- 25.2% start on a job-detail page.
- 13.3% start on FAQ.
- 10.3% start on the
/jobslist.
This leads to a clear conclusion:
- The job card and the job list are the most important surface to fix, because the list is the most-used page and holds the biggest drop-off point.
- The job-detail page also matters as an entry point, because 25.2% of sessions land on one directly with no earlier context — see Primary Flows, Flow 1.
- The home page should be improved after these, not before.
Below the list, the path splits in two. An earlier version of this page drew one funnel from the list to a completed application. That single funnel hid an important fact: its top is mostly gig traffic, and its bottom is entirely careers. The two job types complete in two different places, so they must be read as two funnels:
- Gig jobs carry about 75% of job-detail traffic: 15,032 views by 3,334 users across 512 gig job pages. Every gig Apply link leaves the site. The application completes on
gig-partners.jodapp.com, where 146 users completed one in 90 days — about 4.4% of gig detail users. - Careers jobs carry about 25% of job-detail traffic: 4,984 views by 2,646 users across 74 careers pages. The careers application completes on jodapp.com itself, but only 18 users completed one in 90 days — a conversion of 0.68%.
GA4, Singapore, 90 days:
- Careers pages are identified by the
hqURL segment, so the split is measured, not estimated. - Gig: 15,032 detail views, 3,334 users, 512 pages (4.5 views per user).
- Careers: 4,984 views, 2,646 users, 74 pages (1.9 views per user).
- Completions: 146 users on gig-partners (~4.4% of gig detail users); 18 users on jodapp.com (0.68% of careers detail users).
Singapore, 90 days. The top of the traffic is mostly gig. All applications completed on jodapp.com are careers. All gig applications complete on the separate gig-partners site. Why a paid post can return only 2 applicants is explained in Finding 2 — the cause is traffic per post, not only conversion.
Two numbers in this funnel need honest footnotes:
- "18 completed applications" is a site-wide count. The completion event (
generate_lead) fired 33 times for 18 users anywhere on jodapp.com. Only 7 of those 18 users passed through the full list → job detail → form sequence. The other 11 landed directly on a job page or took another path. Both numbers matter: 18 is the site total, 7 is the strict funnel total. - "Started apply" was a proxy, not a real event. The earlier funnel showed 347 users "starting to apply" (a 76% loss from the 1,417 who opened a job). That number is the
form_startevent, which fires on the search form, the login form, and the sign-up form — never on a job-detail page. So it measures "reached a gate before applying", not "started an apply form". A real, jodapp.com-native apply event does not exist yet.
GA4, jodapp.com, Singapore, 90 days:
generate_lead= 33 events from 18 users site-wide.- 7 of those users came through the full list → detail → form sequence.
form_startfires on the search, login, and sign-up forms only — checked against the event setup.
The Google Analytics property mixes two sites: jodapp.com (the jobseeker web we are redesigning) and gig-partners.jodapp.com (the separate older gig portal where every gig application completes). Every number in this document is locked to jodapp.com, except where we name gig-partners explicitly.
We are not fully blind across the two sites. A cross-host funnel can trace roughly 60–65% of the gig-partners completions (about 97 of the 146 users) back to the jodapp.com job list. But this stitching is partial, and jodapp.com still has no event that fires at the moment a user acts to apply — the form_start proxy fires on search, login, and sign-up forms instead.
So the missing piece is a jodapp.com-native apply event: one event that fires when the user taps Apply, for both job types. It is the first item in the Prioritization Roadmap, because without it we cannot prove that any redesign worked.
Finding 2 — Traffic per post is the hard limit, not conversion alone
The funnel numbers above explain why conversion is poor. They do not explain why a paid post returns only 2 applicants. To explain that, we must count the visitors that one job post actually receives. The arithmetic is short, so we walk through it step by step:
- The median careers post receives about 19–22 unique visitors in 90 days. The upper quartile reaches 34 views. The top 2 careers posts alone take 48% of all careers detail views, so a typical post gets far less attention than the average suggests.
- Now imagine a perfect funnel: 100% of visitors apply. The median post still receives only about 19 applications in 90 days. Conversion work cannot beat this ceiling, because a conversion rate cannot go above 100%.
- Competing job boards set the market expectation near 100 applicants per post (the fastjobs benchmark). Step 2 shows this is unreachable on today's traffic, no matter how good the funnel becomes.
- New organic traffic will not close the gap soon. Organic search brings about 960 clicks per month and has been flat for 3 months. Full-time job queries have 47 impressions and 0 clicks — no organic footprint at all.
GA4, Singapore, 90 days — visitor counts per careers detail page across all 74 pages:
- Median about 19–22 unique visitors.
- Upper quartile 34 views.
- Top 2 posts take 48% of careers detail views.
GSC, Singapore, 3 months:
- About 960 organic clicks per month, flat April–June.
- Full-time queries: 47 impressions, 0 clicks.
Because of this arithmetic, the CTO confirmed a realistic success target: 20–40 applicants per promoted post. Reaching it needs two levers at the same time:
- Fix the careers apply flow, so a visitor who wants the job can actually apply. Today only 0.68% do.
- Build distribution, so a promoted post is shown to hundreds of the visitors the site already has — the /jobs list alone gets 35,914 views per quarter — instead of the median 19.
Neither lever works alone. A perfect funnel on 19 visitors gives 19 applicants. Heavy traffic into a 0.68% funnel gives almost none. This finding reshapes the order of work in the Prioritization Roadmap.
Finding 3 — Two products are becoming one, so we design for the finished product
jodapp has two kinds of jobs today:
- Gig jobs — short or daily work, coming from the older JodGig system.
- Careers jobs — full-time work, added recently.
These two are in the middle of being merged into one single marketplace. This is not a guess. The product docs already describe the finished state: one jodapp.com jobseeker home page that shows both kinds of jobs, with /gig/jobs and /careers/jobs underneath.
Because of this, we design the IA for the finished, merged product, even while the backend migration is still in progress. One part of the product still cannot be joined:
- Applying to a gig job still sends the user to the old
gig-partners.jodapp.comsite.
We must be honest about the status of this handoff. No document calls it temporary. Two documents treat it as a stable part of the architecture: the analytics architecture doc defines a "Showroom (jodapp.com) / Checkout (gig-partners)" split as a working principle, and the DNS domain list marks gig-partners.jodapp.com as "no-change". So today, the handoff is institutionalized, not temporary.
This IA proposes retiring the handoff as the end-state: the gig application should eventually complete on jodapp.com. That is a proposal, not a decision. Before any implementation issue is created, a migration decision doc must be written in the 35-gig domain docs (docs before issues). Until that decision exists, we design the navigation for the merged product, but we treat the gig apply handoff as a fact of the current system and hide it from the user as much as possible.
Finding 4 — We use the user's words, not our words
Google Search Console is the only honest record of how real people describe what they want, because it captures their words before they ever see our interface. When we read those words, three patterns stand out.
People search for "part time". They almost never search for "adhoc", which is the word we use internally.
Search Console, Singapore, 3 months:
- The "part time" family is 546 queries with 9,578 impressions and 49 clicks.
- "adhoc" and "ad hoc" together appear in exactly 1 query, with 1 impression and 0 clicks.
People search for "daily pay", and when we appear for it, they click far more often than for other non-branded phrases. (This measures clicks on our search result, not visitor-to-applicant conversion — with only 18 completed applications we cannot know which phrase produces applications.)
Search Console, Singapore, 3 months:
- The "daily pay" family has 72 clicks from 910 impressions — a 7.9% click rate, 5.7x the 1.39% average of non-branded queries where we are visible.
- The honest baseline is 1.39%, not the site-wide 3.76%: the site-wide average is inflated by branded queries, which click at 19.8%.
For location, people search for a specific employer or place, not for a broad region. Employer and brand queries dominate: 627 queries with 13,612 impressions and 235 clicks. Specific-place queries (for example "fairprice jurong east") add 139 queries with 1,033 impressions. Broad region queries on their own are almost absent: 3 queries with 4 impressions. Employer beats broad region by roughly 13 to 1. "Near me" is also a real pattern: 173 queries, 524 impressions.
Search Console, Singapore, 3 months:
- 627 employer/brand queries (13,612 impressions, 235 clicks).
- 139 specific-place queries (1,033 impressions).
- Against that: 3 broad-region queries (4 impressions).
- An earlier version tagged this claim directional; with the full query classification the ratio is about 13:1, so we now treat it as strong.
So we build the navigation and the filters from these real words. The full mapping is in the Vocabulary Lexicon.
Two decisions that anchor everything
The CTO confirmed these two decisions, and both are supported by the data and the docs.
Decision A — Treat gig and full-time as one product
We keep gig and full-time inside one product, with two clearly-labelled lanes, and we design for the merged end-state now. The reasons are:
- The product docs already describe this merged end-state (the board-web Phase 2 plan).
- Both types of user arrive through the same entry points, so one product serves both.
- Building two separate sites would create a permanent split that we would later have to undo.
Decision B — Seed a small, demand-matched, extensible category set
We re-seed the job categories as a small starter set that matches measured demand, with a written rule for growing it. The CTO clarified this on 2026-07-03: the set is not limited to blue-collar work. The business may add roles such as florists or admin staff whenever there is inventory or demand. The decision has three parts:
- Start with the 8 demand-seeded categories in Taxonomy & Filters. Search Console shows users search a small number of concrete categories, such as Food & Beverage, supermarket, warehousing, and events. So the starter set follows demand, not an industry list.
- Add an explicit "Others" catch-all. Every job always gets a category, and no job is forced into a wrong one.
- Add an extension rule, written down: a category earns a browse entry when it has at least N live jobs or clear search demand in Search Console. Start with N=10 and adjust.
Two clarifications, so this decision is not misread:
- The 89 categories in the repo today (for example "Investment Banking" and "UX/UI Design") are the development seed. The production seed is not implemented, so the production count is unverified. We treat the 89 as the canonical in-repo list, and most of it does not match today's inventory.
- This decision re-seeds the contents of the existing
taxonomy_categoriestable. It does not add a new table or a new filtering mechanism. This distinction matters because a 2026-05-07 decision (docs/30-49-domains/35-gig/notes/2026-05-07-decision-gig-pay-rates-org-job-roles.md) rejected adding a new small taxonomy table (its "Option D"). There is no conflict: that decision was about not creating a second taxonomy structure. This decision only changes the rows inside the structure we already have.
The design principles that follow from these decisions
- One marketplace, typed lanes. Gig and Careers are different types of the same job space. Job type is a filter and a label. It is never a separate part of the navigation.
- Findable and buildable, both at once. We only add a category, filter, or browse path if it satisfies two conditions: the data model can support it, and the search data shows real demand for it.
- Mobile-first, always. About 3 in 4 users are on a mobile phone: 74% of jodapp.com sessions, and 76.7% of our Google search clicks. The list, the filters, and the apply flow are designed for mobile first, and desktop is treated as the wider secondary case.
- Capture the intent early, ask for the rest later. The recorded application is the valuable thing. We record it first, and we ask the user to complete their profile afterwards, in small steps. Screening also comes after capture: 1–3 short employer-defined questions, asked after the application is recorded, so the employer still learns enough about each applicant. We never block the application with a form wizard or an ad.
- Exceptions are named, and their end-state is decided in writing. Where the migration forces a compromise, such as the off-site gig apply, we do not pretend it is temporary — today two docs treat it as stable architecture. We name the exception, we propose its end-state, and we require a written migration decision doc before we build toward that end-state.
The single most important metric
Everything in this section serves one business goal: the number of applications an employer receives per open job. The CTO-confirmed target is 20–40 applicants per promoted post.
Finding 2 showed the arithmetic: the median careers post gets about 19 unique visitors in 90 days, so even a perfect funnel gives about 19 applications. Because of this, the metric has two levers, and both must move:
- Conversion. Raise the careers rate from detail visitor to recorded application: from 0.68% today toward the gig benchmark of about 4.4%. The redesigned apply flow does this.
- Distribution. Raise the unique visitors per promoted post from the median 19 to hundreds, by routing traffic the site already has: featured pinning on the /jobs list (35,914 views per quarter), a home-page featured rail, "similar jobs" and "more from this employer" links, and job-alert emails to registered talent.
This changes the order of work from the earlier version of this document. The earlier order was: fix the funnel, then grow traffic, and only then sell visibility. That order was wrong, and the reasoning is worth walking through:
- The old order assumed poor conversion was the reason paid posts fail. The data says the bigger cause is distribution: a $400 post today buys a listing row that a median of 19 people ever see. Even at 100% conversion, that is 19 applicants — below the target, and real funnels convert a few percent, not 100%.
- The client is buying applicants, not a listing row. So the product we sell must include the thing that produces applicants: distribution of the post to the visitors we already have.
- The distribution bundle is the sellable product, and it reuses the paid-placement infrastructure that already exists in the ads work. So monetization does not wait at the end of the roadmap. It moves forward, next to the conversion fix.
What was wrong before was not selling too early. It was selling posts with no distribution attached.
One measurement rule still applies before either lever can be proved: jodapp.com needs a native apply event. Today the site records only 18 completions in 90 days, the "apply start" number is a form_start proxy that never fires on a job page, and gig completions can only be traced across hosts (about 60–65% of them). The native event is Phase 0 of the Prioritization Roadmap.
How to read this section
The eight deliverables build on each other, in this order. One extra page, Theory & Method Foundations, sits underneath all of them and records the proven concepts we used.
| # | Deliverable | The question it answers |
|---|---|---|
| — | Theory & Method Foundations | Which proven IA theories and methods does this plan use, and what is honestly not proven? |
| 1 | Content Inventory | What must a user find, do, and understand — grouped by how often they need it? |
| 2 | Vocabulary Lexicon | What do users actually call these things? This is the evidence for our labels. |
| 3 | Navigation Hierarchy | How is the product grouped into 2 or 3 levels, with exact labels? |
| 4 | Taxonomy & Filters | What categories and filters let a user reach a relevant list of jobs in fewer than 3 clicks? |
| 5 | Primary Flows | What are the most important paths from arrival to a finished goal? |
| 6 | Screen Map | What is every screen, what is its job, and how does it connect to its neighbours? |
| 7 | Friction Points | Where do users leave the site, and why? |
| 8 | Prioritization Roadmap | What do we build first, ranked by impact and effort? |
Scope and non-goals
In scope is the jobseeker-facing web product. This includes:
- The home page.
- The job list and search.
- The job detail page.
- The filters.
- The apply flow.
- The jobseeker account.
This is the demand side of the marketplace, and it is the side that decides how many applications an employer receives.
Out of scope for this document are the following, which are referenced only where they feed the jobseeker experience:
- The employer dashboard and the internal team or ops portal. These appear only where they affect the jobseeker view, for example a "featured employers" flag set by sales. (That flag has no spec anywhere yet — a spec must be written before it is built.)
- Visual design and the component library.
- SEO tactics. Acquisition itself is in scope: it is a first-class later phase of the Prioritization Roadmap, because organic search brings only about 960 clicks per month and is flat. The tactics live in the marketing docs (
74-marketing). The43-seo-patternssection contains only one JSON-LD implementation page, so do not look for tactics there. - The billing and entitlement engine. It is covered in the ads billing docs (
38-ads, billing-integration-phase-2) and referenced here only where monetization depends on the IA. The entitlement engine that a job-boost product needs is Phase 3 of that billing work.