API for Market Intelligence
Designed an API-first architecture that became the backbone of a market intelligence platform — powering both the product UI and direct client integrations simultaneously.
API
UX Researcher
Internal Trainer
Market Intelligence
API Design
Endpoint Design
Documentation Architecture
User Research
Access Management
Internal Training
My Role & Responsibilities
From architecture proposal to shipped product
My involvement started at the architectural level — I proposed making the API a first-class layer shared across the product UI and client integrations. From there, I moved into the details: co-designing the endpoint syntax with the IT team, structuring the documentation, and running user research across all three user types.
I also designed the API key management interface and delivered internal training for the support team — giving them the tools to help clients optimise their queries and use the API in their own data quality workflows.
-
Architecture Input
Proposed and advocated for an API-first architecture where a single layer powers both the product UI and client-facing integrations. -
Endpoint Co-Design
Collaborated with the IT team to define endpoint syntax: parameter names, naming conventions, and response descriptions. -
Documentation Structure
Designed the information architecture of the API documentation to serve users ranging from first-time analysts to experienced integrators. -
User Research
Conducted interviews with beginner analysts, power users, and IT teams to surface gaps in usability and mental model mismatches. -
Access Management UI
Designed the API key management interface supporting per-user keys with organisation-level control over who can access the API. -
Internal Training
Delivered training for the customer support team on using the API to help clients optimise queries and verify data quality.
The Challenge
One platform, three very different types of API users
The platform served a wide range of users who all needed API access — but for completely different reasons. Junior analysts were exploring data for the first time. Senior analysts were building automated workflows. IT teams at client organisations were constructing internal tooling for their own end users.
On top of the user complexity, the existing architecture treated the API as a secondary layer — separate from the main product. New features took longer to reach clients via API, and the mismatch created friction for technically sophisticated users who expected parity.
-
Fragmented API Layer
The existing architecture decoupled the API from the product UI, creating delays whenever new features shipped. -
Diverse User Profiles
One API had to serve beginner analysts, power users, and IT integrators — each with fundamentally different needs and mental models. -
Endpoint Clarity
Parameter names, response structures, and endpoint paths needed to be intuitive enough for junior users while precise enough for developers. -
Access Control Complexity
Client organisations needed to manage API access per user — not per account — while maintaining centralised control at the organisation level.
Preview
Shipping an API that works for everyone — from first query to production integration
The challenge wasn't just technical — it was about making a complex, enterprise-grade API feel approachable for some users while remaining precise and powerful for others. Each design decision had to hold up across a very wide range of technical confidence levels.
A single API layer for the entire product
The original system maintained separate paths for the product UI and client API access. This created a feature gap — capabilities available in the interface weren't always accessible programmatically, and vice versa.
I proposed consolidating them into one shared API layer used by both the main application and external clients. The result: every feature shipped to the interface is immediately available via API, without extra development overhead.
Co-designing the language of the API
Endpoint design is rarely treated as a UX problem — but for API users, the names of parameters and the structure of responses are the entire interface.
Working alongside the IT team, I contributed to defining the naming conventions, parameter labels, and endpoint descriptions. The goal was consistency and clarity: a junior analyst reading the docs should be able to form a valid query; a developer integrating at scale should never need to guess what a field means.
Interviewing users across the full skill spectrum
I ran research sessions with three distinct user groups: junior analysts discovering the API for the first time, advanced users optimising complex queries, and IT teams building internal integrations for their own organisations.
The interviews surfaced concrete gaps — terminology that was opaque to beginners, documentation sections that power users had to reverse-engineer, and access patterns that didn't match how IT teams structured their internal tooling. These findings directly shaped endpoint descriptions, documentation structure, and the access management model.
API keys that match how organisations actually work
Most API platforms issue keys at the account or organisation level. But analysis of how client organisations were structured revealed a different reality: access needed to be controlled per individual user, with the organisation deciding which users could use the API at all.
I designed the key management interface around this model — users generate and manage their own keys, while organisation admins retain full visibility and control over who is authorised. This matched the real governance structure of enterprise clients without adding friction for end users.
Shipped and in production
An API that serves analysts, developers, and support teams alike.
The platform's API launched and is actively used across all three target user groups. The architecture decision — one shared API for both the product UI and external integrations — eliminated the feature parity gap and reduced the overhead of shipping new capabilities to clients.
Live in Production
The API launched successfully and is used by clients ranging from individual analysts to enterprise IT teams.
API-First Architecture
A single shared API layer now powers both the product UI and client integrations, ensuring immediate feature parity on every release.
Per-User Access Control
The key management model reflects how enterprise organisations actually govern access — by user, with organisation-level oversight.
Support Team Capability
Trained support staff to use the API directly — enabling faster client troubleshooting and independent data quality verification.
API design is product design
An API isn't a backend concern — it's a user interface for a different kind of user.
By treating the API as a core product layer shared with the main UI, we removed an entire class of delivery friction. New features no longer had to wait for a separate API release cycle.
The research across user types reinforced something that's easy to overlook in enterprise products: the people using the API aren't a monolith. Designing for that range — from first-time analysts to IT teams building internal platforms — is what makes an API genuinely useful, not just functional.