API SETU
From a rigid developer portal
to a
platform people want to use.
Redesigning India's national API infrastructure by simplifying how developers publish, discover, and consume APIs at scale.
MY ROLE
Product Designer
responsibilities
Research, IA, Interaction Design, Visual Design
TIMELINE
Feb 2023 - Apr 2024
CLIENT
API Setu / Digital India Corporation
LONG STORY SHORT
Government-grade power, without government-grade friction.
API Setu is an Open API platform run by India's Ministry of Electronics and IT. It is part of critical infrastructure, but with a user experience that was turning developers away rather than inviting them in.
I came in as the UX lead from UX4G, I redesigned the end-to-end platform: the public-facing website, the API publishing workspace, the discovery and consumption flows, and the admin controls for managing organisations.
Three things drove every decision: make it feel credible, make it feel flexible, and make the right action obvious at every step.
the problem
A platform that worked.. but only if you already knew how.
API Setu was functional. APIs were being published and consumed. But spend any time with it and the cracks showed up fast. The platform assumed you'd figure it out. There was no guidance for new users, no flexibility for experienced ones, and nothing that communicated why this platform was worth trusting.
1. The platform didn't look or feel credible
Cartoony illustrations, bright playful colours, buried navigation. The homepage read like a side project, not national infrastructure. For a platform handling sensitive government data, that mismatch in tone was killing trust before users even got started.
2. Workflows were rigid & unforgiving
The publishing flow was locked into a strict linear sequence. No going back, no previewing, no room to breathe. Every developer I spoke to mentioned Postman within the first few minutes. The comparison wasn't flattering.
3. Discovery & Management were afterthoughts
The directory was a flat list with no filters, no categories, no way to evaluate an API before committing to it. For organisations trying to manage teams and permissions, the admin side was even rougher. Complex controls with almost no visibility into what was happening.
research & insights
Three ways into the same problem.
Working directly with the development team
The API Setu developers were my main stakeholders, and also my closest proxy for actual users. That was unusual, and genuinely useful. I could get real reactions to early ideas fast, understand what was technically possible, and catch assumptions before they became design decisions. The thing I took away most wasn't a feature request. It was this: they wanted a platform they'd be proud to show another developer. That set the bar.
3.1
Zoom meetings with stakeholders
Image
Competitive analysis
I looked at Postman, Rapid, and a few other tools developers actually enjoy using. The pattern was consistent: flexible flows, inline testing, workspaces that felt like theirs. These weren't advanced features. They were the baseline expectation. Any platform that fell short of this just felt broken, regardless of what it was technically capable of.
3.2
Products benchmarked
Image
Auditing the existing platform
did a structured UX audit of the existing site and portal. Inconsistent hierarchy, vague CTAs, a visual language that undermined rather than built trust. None of it was subtle. Writing it all up against established UX principles gave me a clear, evidence-backed argument for why this needed more than a visual refresh, and why the team should care about it.
3.3
Comprehensive UX audit of the existing product
Image
Beyond fixing problems, my aim was to elevate API Setu to meet modern expectations and reinforce its role as a credible government platform.
design process
The decisions that shaped the outcome
With the problems framed and the research informing direction, the design process centred on a handful of pivotal decisions. These weren't the only things I worked on but they shaped how the platform came out to be.
1. What should a government API platform look like?
The old homepage was too casual. The obvious fix was to go corporate and clean. But that felt wrong too. API Setu needed to feel like somewhere worth being, not just somewhere official. It needed to attract developers who had platforms like Postman as their reference points.
4.1.1
Existing website analysis
Images
I explored a few directions before landing on a space exploration theme. APIs as navigating a digital universe. It sounds abstract but it worked. It gave the platform ambition and personality while staying within government design guidelines.
4.1.2
Redesigned hero section on the landing page
Image
4.1.3
Space exploration theme
Images
2. Rethinking the API publishing flow
The old publishing flow had one mode: forward. Step 1, step 2, step 3, no going back. The moment I reframed the question from 'how do we fix the steps' to 'how do we make this feel like a workspace', everything changed.
4.2.1
Existing API Publisher's flow analysis
Images
The question wasn't "how do we fix these steps in the publishing flow", it was "how do we give developers the feeling of a workspace rather than a form."
That reframe changed everything: collapsible nav, a persistent preview pane, inline docs, jump-to-any-step freedom. Developers could move the way they actually think, not the way a form tells them to.
4.2.2
Publishing flow exploration
Images
4.2.3
API publishing - before & after
Slider
3. Making API discovery actually work
The old API directory was a wall of text. No filters, no categories, no context. You had to already know what you were looking for.
4.3.1
Analysis of existing API directory and listing pages
Images
I redesigned it around browsing: structured categories, keyword and criteria filtering, list and grid views, and a basket model so users could shortlist multiple APIs and subscribe in one go. It went from transactional to actually explorable.
4.3.2
Reimagined API directory page
Images
4.3.3
Redesigned API search and listing page
Images
final designs
Four areas transformed, end to end.
1. Website & Onboarding
New homepage, new visual identity, new sign-up flow. The partner onboarding process was rebuilt so organisations understood what they were getting into before being asked to do anything. Step-by-step, no clutter, no guesswork.
5.1.1
Redesigned homepage zoomed out
Images
5.1.2
Consistent visual design adopted for other pages in the website
Images
I explored different directions for the sign-in/up flow. The visual language of these screens would determine the direction that the entire product would take, so I presented various options to the stakeholders for their review.
5.1.3
Explorations for sign-in/up page
Images
5.1.4
Reimagined onboarding for citizens and partners
Images
2. API publishing workspace
Non-linear, flexible, built around how developers actually work. First-timers get a guided tour with tooltips throughout. Experienced users can jump straight in. Bulk upload for multiple endpoints. Collapsible nav so the preview panel gets the space it deserves.
5.2.1
API publishing flow - before & after
Slider
5.2.2
Getting new users familiarized using a guided tour
Images
I created a straightforward six-step publishing flow for new users that aligns better with the mental model of our target audience: developers looking to publish APIs for public consumption. These steps won't be pushed to experienced users who choose their own sequence based on their workflow.
5.2.3
Comprehensive API publishing flow
Loop
5.2.4
Collapsible navigation panel
Loop
3. API Discovery & Consumption
Searchable, filterable, browsable. The listing page now puts collections, endpoints, documentation and testing all in one place. Subscribe via a basket, add what you want, review it, commit once. The consumer dashboard shows active subscriptions and usage at a glance.
5.3.1
API directory - before & after
Slider
5.3.2
Switchable list/grid views on the search results page
Images
5.3.3
Category-level exploration of APIs
Images
5.3.4
API listing page - before & after
Slider
5.3.5
Bulk API subscription flow
Loop
5.3.6
API Consumer dashboard
Image
4. Organizational management & admin
Admins finally had a home screen. Teams, roles, permissions, member management, all there. Onboarding requests are reviewable with actual context. Partner service requests from DigiLocker and others have a proper approval flow built in.
5.4.1
Organization home dashboard
Image
5.4.2
Organization management: teams & people
Image
API setu admins can efficiently manage organization requests for Digital India partner services. They review use cases and organization profiles to make informed approval decisions, enhancing partnership and service management.
5.4.3
Digital India's partners' service request management
Loop
constraints & trade-offs
What the final designs don't show you
A polished set of screens can make a project look straightforward. This one wasn't. There were situations that shaped the work in ways that aren't visible in the final designs, but understanding them explains why certain decisions were made the way they were.
1. No design infrastructure to lean on.
UX4G, the government initiative set up to guide and improve the UX of government digital products including ones under Digital India (like API Setu) was was brand new when I joined this project. I was their representative, parachuted into a dev team that had never worked with a designer. No design system, no brand guidelines, no one to bounce visual decisions off.
Every banner, icon, and illustration I either made myself or hunted down and adapted from online resources. It was scrappy. It also made me significantly more self-reliant than I'd ever had to be before.
2. Every change was a negotiation.
API Setu had real users and real technical debt. The team's default was cautious, and fair enough. More engineering effort, more testing risk, more chance of breaking something that was working.
I learned fast to pick my battles.
Some things I could redesign freely. Others I had to work around. Getting precise about that difference saved a lot of friction.
3. The sandbox- a feature I believed in that didn't ship.
I wanted an integrated testing sandbox, test your API before publishing, try someone else's before subscribing, all without leaving the platform. The kind of thing Postman makes feel obvious.
It didn't make it. A Swagger module was already there, replacing it felt too disruptive, and the call was made to keep it. I understood. I still think the sandbox was right. That tension, between what's best and what's buildable, is one of the more honest parts of this project.
the impact
A platform ready to grow
Quick disclaimer: these numbers weren't caused by design alone. Ministry mandates, Digital India policy push, and growing partner interest all played a part. I'm not claiming credit for the growth. What I do believe, based on three years working alongside these teams, is that the redesign made the difference between people arriving and people actually staying.
At the start of the project
Publishers
Published APIs
Transactions per month
Publishers up 57%. APIs on the platform up 61%. Transactions up nearly 3x. Again, ministry mandates, policy push, and expanding Digital India partnerships all contributed to this. But a platform that developers found confusing and off-putting was not going to onboard 600+ new publishing organisations and retain them. The usability had to be there for the growth to stick.
Post revamp
Publishers
Published APIs
Transactions per month
LEARNINGS
What this project taught me
1. My first time owning a product end to end.
This was the first project where I was responsible for the whole thing, not a flow, not a feature, but a product with four distinct user types and dependencies across government departments. That was a lot. But it's also where I learned the most. How to hold multiple perspectives at once. How to sequence work when everything feels equally urgent. How to explain design decisions to people who live in code.
2. Design systems: wish I'd started earlier.
I came into this project relatively new to the concept of design systems. By the time I was halfway through, I understood why they matter. Without a coherent system in place from the start, the design files became increasingly difficult to manage & redundant components started existing. Decisions made early created inconsistencies that took time to untangle later. The further into the project I got, the more I wished I had established the design system foundations first rather than building them reactively.
3. Sometimes you make the case and still lose.
The sandbox was the feature I fought hardest for. I thought it was the thing that would bring the experience closest to what developers actually expected. It didn't ship. Swagger stayed. The call was pragmatic and I respect it, but I'd still push for the sandbox first thing if I ever got back into this.