Product
Conduit API Marketplace Assistant
Closing the gap between what developers ask for and how API catalogs are named. A conversational layer built on Ant Design 5.
Year :
2024
Industry :
Enterprise SaaS · API platforms · Telecom
Project Duration :
6 weeks
Nobody fails to find the API. They fail to recognise it.
A marketplace launches with sixty well-documented APIs and adoption stays flat. The instinct is always more documentation, better search, a nicer developer portal.
Then you watch a session recording. An integration developer types "customer verification" into search, gets four results named Number Verification v2.1, KYC Orchestration Service, Subscriber Identity API, and MSISDN Match v1.0, opens all four in tabs, and leaves.
They didn't fail to find the API. They failed to recognise it.
That gap — between how a developer describes a problem and how a publisher names a solution — is the largest single source of abandonment in an API catalog. It isn't a search relevance problem. Keyword matching, faceting, and better tagging all operate on the publisher's vocabulary, and the developer doesn't have it yet.
I spent several years designing enterprise integration and API platform products, and this pattern repeated across telecom and banking clients. It was never the documentation.
The brief said chatbot. The work was the catalog.
The obvious response is to add an AI assistant. I spent the first week arguing myself out of it.
A chatbot bolted onto a catalog is a search box with worse latency. If the underlying data only knows that an API is called Number Verification v2.1, a language model in front of it can only paraphrase that name. The intelligence has to live in the data, not the interface.
So the brief I actually worked to: make the catalog describable by outcome, then render that capability conversationally.
This changed what I designed. The primary artefact became a metadata model — outcome tags, a capability ontology, and composition recipes describing which APIs get used together and why. The conversation is the surface. The ontology is the product.
It also gave the work a second life. A catalog rich enough for a chatbot to compose APIs from intent is rich enough for an external agent to do the same. The conversational layer and the machine-consumption layer are one investment, not two.
Six principles came out of it. Conversation terminates in an artefact, never a paragraph. Absorb the search bar rather than adding a floating bubble beside the interaction that's already failing. Show the request, not the answer. Ground every technical claim in a named spec version. Route into the product for anything with commercial consequence — a typed "yes" is not consent to a billing change. And sandbox by default, with production as a deliberate act the assistant cannot take on your behalf.
What survived contact with a real design system
The concept was first built in a bespoke visual language, then rebuilt on Ant Design 5 — partly to test whether the thinking survived contact with a real system, which is the honest test of whether principles are principles or just preferences.
Most of it survived by being replaced. Ant ships a companion library for AI interfaces, Ant Design X, organised around a paradigm they call RICH. Four of my six principles already had names and components: Sender and Prompts for absorbing the search bar, Actions for terminating in an artefact, Sources for grounding, Steps for the composition. My hand-rolled citation pills came straight out.
That's the argument for adopting a mature system rather than admiring your own. The refusal screen — where the assistant says it has no answer and won't invent one — went from a note in the spec to a built screen in twenty minutes, because Result already existed. Principles that are expensive to build tend not to get built.
One thing needed extending, and it's the interesting one. Ant reserves colour for status: success, warning, error, info. Provenance isn't a status. There was no token for "this content was generated," and the obvious candidate — primary blue — is load-bearing everywhere else, since it means interactive. So I took geekblue from Ant's own extended palette: adjacent enough to belong, separate enough to read as a different kind of thing, and unclaimed.
Naming that as a proposed extension rather than quietly applying it is the point. A design system with no concept of provenance isn't a flaw in Ant Design — it reflects that the industry hasn't settled what generated content should look like.
This is a concept project, resting on domain experience and desk research rather than fresh primary research. Three things would need testing before anything got built: whether developers will actually type intent into a search field after a decade of keyword search, whether a citation meaningfully changes trust or gets ignored the way security warnings do, and whether five composition recipes really cover most discovery traffic. The first is the highest-risk decision in the design and it's a fifteen-participant study.
More Projects
Product
Conduit API Marketplace Assistant
Closing the gap between what developers ask for and how API catalogs are named. A conversational layer built on Ant Design 5.
Year :
2024
Industry :
Enterprise SaaS · API platforms · Telecom
Project Duration :
6 weeks
Nobody fails to find the API. They fail to recognise it.
A marketplace launches with sixty well-documented APIs and adoption stays flat. The instinct is always more documentation, better search, a nicer developer portal.
Then you watch a session recording. An integration developer types "customer verification" into search, gets four results named Number Verification v2.1, KYC Orchestration Service, Subscriber Identity API, and MSISDN Match v1.0, opens all four in tabs, and leaves.
They didn't fail to find the API. They failed to recognise it.
That gap — between how a developer describes a problem and how a publisher names a solution — is the largest single source of abandonment in an API catalog. It isn't a search relevance problem. Keyword matching, faceting, and better tagging all operate on the publisher's vocabulary, and the developer doesn't have it yet.
I spent several years designing enterprise integration and API platform products, and this pattern repeated across telecom and banking clients. It was never the documentation.
The brief said chatbot. The work was the catalog.
The obvious response is to add an AI assistant. I spent the first week arguing myself out of it.
A chatbot bolted onto a catalog is a search box with worse latency. If the underlying data only knows that an API is called Number Verification v2.1, a language model in front of it can only paraphrase that name. The intelligence has to live in the data, not the interface.
So the brief I actually worked to: make the catalog describable by outcome, then render that capability conversationally.
This changed what I designed. The primary artefact became a metadata model — outcome tags, a capability ontology, and composition recipes describing which APIs get used together and why. The conversation is the surface. The ontology is the product.
It also gave the work a second life. A catalog rich enough for a chatbot to compose APIs from intent is rich enough for an external agent to do the same. The conversational layer and the machine-consumption layer are one investment, not two.
Six principles came out of it. Conversation terminates in an artefact, never a paragraph. Absorb the search bar rather than adding a floating bubble beside the interaction that's already failing. Show the request, not the answer. Ground every technical claim in a named spec version. Route into the product for anything with commercial consequence — a typed "yes" is not consent to a billing change. And sandbox by default, with production as a deliberate act the assistant cannot take on your behalf.
What survived contact with a real design system
The concept was first built in a bespoke visual language, then rebuilt on Ant Design 5 — partly to test whether the thinking survived contact with a real system, which is the honest test of whether principles are principles or just preferences.
Most of it survived by being replaced. Ant ships a companion library for AI interfaces, Ant Design X, organised around a paradigm they call RICH. Four of my six principles already had names and components: Sender and Prompts for absorbing the search bar, Actions for terminating in an artefact, Sources for grounding, Steps for the composition. My hand-rolled citation pills came straight out.
That's the argument for adopting a mature system rather than admiring your own. The refusal screen — where the assistant says it has no answer and won't invent one — went from a note in the spec to a built screen in twenty minutes, because Result already existed. Principles that are expensive to build tend not to get built.
One thing needed extending, and it's the interesting one. Ant reserves colour for status: success, warning, error, info. Provenance isn't a status. There was no token for "this content was generated," and the obvious candidate — primary blue — is load-bearing everywhere else, since it means interactive. So I took geekblue from Ant's own extended palette: adjacent enough to belong, separate enough to read as a different kind of thing, and unclaimed.
Naming that as a proposed extension rather than quietly applying it is the point. A design system with no concept of provenance isn't a flaw in Ant Design — it reflects that the industry hasn't settled what generated content should look like.
This is a concept project, resting on domain experience and desk research rather than fresh primary research. Three things would need testing before anything got built: whether developers will actually type intent into a search field after a decade of keyword search, whether a citation meaningfully changes trust or gets ignored the way security warnings do, and whether five composition recipes really cover most discovery traffic. The first is the highest-risk decision in the design and it's a fifteen-participant study.
More Projects
Product
Conduit API Marketplace Assistant
Closing the gap between what developers ask for and how API catalogs are named. A conversational layer built on Ant Design 5.
Year :
2024
Industry :
Enterprise SaaS · API platforms · Telecom
Project Duration :
6 weeks
Nobody fails to find the API. They fail to recognise it.
A marketplace launches with sixty well-documented APIs and adoption stays flat. The instinct is always more documentation, better search, a nicer developer portal.
Then you watch a session recording. An integration developer types "customer verification" into search, gets four results named Number Verification v2.1, KYC Orchestration Service, Subscriber Identity API, and MSISDN Match v1.0, opens all four in tabs, and leaves.
They didn't fail to find the API. They failed to recognise it.
That gap — between how a developer describes a problem and how a publisher names a solution — is the largest single source of abandonment in an API catalog. It isn't a search relevance problem. Keyword matching, faceting, and better tagging all operate on the publisher's vocabulary, and the developer doesn't have it yet.
I spent several years designing enterprise integration and API platform products, and this pattern repeated across telecom and banking clients. It was never the documentation.
The brief said chatbot. The work was the catalog.
The obvious response is to add an AI assistant. I spent the first week arguing myself out of it.
A chatbot bolted onto a catalog is a search box with worse latency. If the underlying data only knows that an API is called Number Verification v2.1, a language model in front of it can only paraphrase that name. The intelligence has to live in the data, not the interface.
So the brief I actually worked to: make the catalog describable by outcome, then render that capability conversationally.
This changed what I designed. The primary artefact became a metadata model — outcome tags, a capability ontology, and composition recipes describing which APIs get used together and why. The conversation is the surface. The ontology is the product.
It also gave the work a second life. A catalog rich enough for a chatbot to compose APIs from intent is rich enough for an external agent to do the same. The conversational layer and the machine-consumption layer are one investment, not two.
Six principles came out of it. Conversation terminates in an artefact, never a paragraph. Absorb the search bar rather than adding a floating bubble beside the interaction that's already failing. Show the request, not the answer. Ground every technical claim in a named spec version. Route into the product for anything with commercial consequence — a typed "yes" is not consent to a billing change. And sandbox by default, with production as a deliberate act the assistant cannot take on your behalf.
What survived contact with a real design system
The concept was first built in a bespoke visual language, then rebuilt on Ant Design 5 — partly to test whether the thinking survived contact with a real system, which is the honest test of whether principles are principles or just preferences.
Most of it survived by being replaced. Ant ships a companion library for AI interfaces, Ant Design X, organised around a paradigm they call RICH. Four of my six principles already had names and components: Sender and Prompts for absorbing the search bar, Actions for terminating in an artefact, Sources for grounding, Steps for the composition. My hand-rolled citation pills came straight out.
That's the argument for adopting a mature system rather than admiring your own. The refusal screen — where the assistant says it has no answer and won't invent one — went from a note in the spec to a built screen in twenty minutes, because Result already existed. Principles that are expensive to build tend not to get built.
One thing needed extending, and it's the interesting one. Ant reserves colour for status: success, warning, error, info. Provenance isn't a status. There was no token for "this content was generated," and the obvious candidate — primary blue — is load-bearing everywhere else, since it means interactive. So I took geekblue from Ant's own extended palette: adjacent enough to belong, separate enough to read as a different kind of thing, and unclaimed.
Naming that as a proposed extension rather than quietly applying it is the point. A design system with no concept of provenance isn't a flaw in Ant Design — it reflects that the industry hasn't settled what generated content should look like.
This is a concept project, resting on domain experience and desk research rather than fresh primary research. Three things would need testing before anything got built: whether developers will actually type intent into a search field after a decade of keyword search, whether a citation meaningfully changes trust or gets ignored the way security warnings do, and whether five composition recipes really cover most discovery traffic. The first is the highest-risk decision in the design and it's a fifteen-participant study.