AI-enabled is common. AI-native is rarer.
An AI-enabled marketplace uses AI to improve an existing flow.
An AI-native marketplace uses AI to change the way the marketplace works.
An AI-enabled job marketplace might add a résumé summary, a better keyword search, or a tool that helps write a cover letter. These are useful, but the base flow is the same. The jobseeker still searches, scans, filters and applies.
An AI-native job marketplace asks a different question: what if the product could understand a person's skills, goals, limits and recent actions well enough to bring useful roles to them?
That changes the design job. The interface is no longer just a set of pages. It becomes a feedback system.
My framework: the active matching loop
I call my framework for this the active matching loop.
It has four parts:
- Read intent
- Form a view of fit
- Act with care
- Learn from response
The loop sounds simple, but each step changes how the product should be designed.
1. Read intent
In a classic marketplace, intent is often typed into a search box.
That is useful, but it is thin.
In an AI-native marketplace, intent also comes from behaviour: saves, skips, applies, views, profile changes, location settings, salary signals and past decisions.
Stated preferences still matter. In fact, they matter more when the system starts acting on behalf of the user. But stated preferences are only one layer.
The design risk is overconfidence. A person who clicks one role, product or profile does not become that click. A good matching system learns from signals without reducing people to their last action.
2. Form a view of fit
Fit is not the same as similarity.
A weak marketplace shows more of the same. A stronger one can spot adjacent options: a role that stretches someone slightly, a seller with a better trade-off, or a match that works because the timing is right.
This is where design and model work meet. What does good mean? Relevance? Speed? Quality? Fairness? Long-term outcome? User control?
I do not leave those choices to the model alone. They are product choices.
3. Act with care
A marketplace that acts too little feels passive. A marketplace that acts too much feels creepy.
The design work is choosing the right level of action for the level of trust.
A low-risk action might be showing a role in a feed. A higher-risk action might be sending a message, changing a profile, or applying on someone's behalf.
AI-native design needs visible limits. The user should know what the system can do, what it has done, and how to correct it.
4. Learn from response
Every action in an AI-native marketplace is also feedback.
A save is not the same as an apply. A skip is not the same as "never show me this again". A long view might mean interest, confusion or doubt.
Good design turns weak signals into useful learning without making people fill in a form every two minutes.
This is why small controls matter. "Not the right level", "Too far away", "Not this company", "Not now" and "Show me more like this" are simple UI choices, but they teach the system in ways a raw click cannot.
How I am applying this at SEEK
This is the kind of shift I am working through at SEEK: moving parts of the job marketplace from search-first towards match-first.
Search still matters. Filters still matter. A jobseeker should still be able to say exactly what they want and get a clear result.
But jobseekers should not need to know the perfect title, company, category and keyword set before the product can help.
The design question becomes: how can SEEK become more active in the matching process while keeping trust and control intact?
A few lessons are shaping the work.
The first match carries extra weight
The first roles an AI-led surface shows matter more than normal search results.
A weak search result feels like a bad result. A weak AI match can feel like the product has misunderstood the person.
That means the first surface has to be careful. It needs enough confidence, enough range and enough explanation to make the system feel worth listening to.
Reasoning should be light, not loud
People do not need a full model trace. They need enough of the system's thinking to judge whether it is useful.
Small labels can do a lot: "Strong match", "Based on recent applications", "Similar to roles you saved", "Broader match".
The aim is not to explain everything. The aim is to help people calibrate trust.
Feedback belongs on the match surface
In job matching, dismissing a role is valuable feedback.
But asking "why?" every time is annoying.
The better pattern is light, optional feedback close to the card. One tap should be enough to say "not the right level", "too far away", "not this company", or "not now".
The product learns, and the user stays in flow.
Latency is a trust issue
When an AI system takes time, people do not think, "the model is doing useful work". They wonder if the product is stuck, weak, or missing context.
So streaming, skeleton states, progress cues and clear empty states are not polish. They are part of trust.
Designers need to work closer to the model
In classic product work, designers can sometimes treat the model as a back-end concern.
In AI-native marketplaces, the model is part of the product surface.
That means designers need to care about training signals, confidence, false positives, cold starts and feedback loops. Not because designers need to become machine learning engineers, but because these choices shape the experience.
Why this matters to you
For hirers, better matching means less noise. The goal is not more applicants. It is more of the right applicants, with clearer signals about why a person might fit.
For candidates, the promise is agency plus guidance. A good AI-native marketplace should help people see better options without making the process feel opaque or out of their control.
For designers, this is a new craft problem. We are not just designing screens around AI. We are designing how AI participates in a market.
That means the important design questions change:
- What should the system infer?
- When should it ask instead?
- How much should it explain?
- What should it never do without permission?
- How does the user correct it?
Those questions are where the product is made.
The design principles I use
These are the principles I am using to design AI-native marketplaces.
Start with intent, not inventory
Do not begin with what is in the database. Begin with what the user is trying to do, what they already know, and what the system can safely infer.
Show enough reasoning to earn trust
Users do not need the full model. They need enough of the system's thinking to judge whether it is worth listening to.
Keep correction close to the match
The best time to teach the system is when the user reacts to a match. Feedback should sit near the surface that caused the reaction.
Treat uncertainty as a design state
AI systems can be unsure. The interface should say so in plain ways. Overclaiming breaks trust faster than a weak result.
Protect user agency
The more active the system becomes, the more visible its limits should be. Helpful should not become pushy.
What I am building next
The next step is making the active matching loop easier to see, test and critique.
I want this to become more than a written framework. The right version is probably a small interactive model: adjust intent, signals and feedback, then see how the match changes.
Because that is the point of AI-native marketplace design. The product is not a static page. It is a loop.
And the quality of that loop is the quality of the marketplace.