Identity and access management (IAM) for the Airtel Cloud console: who can sign in, what they can do, and where. The first system Airtel brought in-house from its external platform partner.
Design lead. I built the model, the information architecture and the working prototype, working directly with product and engineering.
Senior Lead Product Designer, Airtel
Jun 2026 – ongoing
How I worked
With no PRD, I started from references and definitions, then let a working prototype carry the decisions.
- AuditScreen-by-screen study of AWS IAM
- ConsultA multi-cloud IAM practitioner inside Airtel
- MapThe legacy access model and its shortcuts
- DefineAgreed names and relationships before any screen
- PrototypeAI-directed prototyping on the Cloudscape system
- ReviewDecisions worked through with product and engineering
Why identity and access?
Prospective clients asked for IAM in sales pitches, and without it deals couldn't proceed. Leadership decided to build it as the priority, and to build it in-house: depending on a partner for identity and access was itself the risk.
IAM has to reconcile more concepts than almost any other module — identities, groups, accounts, roles, permission sets, policies, workloads, identity providers, trust, delegation, conditions and governance — while customers still relied on a fragmented legacy model.
The problem: one mental model for everything
The challenge was never a single concept. It was building one coherent model across all of them, from a standing start, with no PRD. Three research threads fed it: an audit of AWS IAM, a multi-cloud IAM practitioner inside Airtel who pushed for a provider-agnostic model, and a walkthrough of the legacy system it would replace.
“Before drawing a single screen, I wrote definitions.”
Project goals
- Unblock enterprise deals that stalled on missing IAM
- Replace a fragmented legacy model with one consistent, scoped one
- Stay provider-agnostic, because Airtel's own infrastructure spans AWS and GCP
Improvement 1: A model before screens
The core model became the spine of the whole module:
No Cell means no console access, regardless of role. That Account → Tenant → Cell hierarchy is a genuine divergence from both AWS and GCP.
Improvement 2: Decisions worked through, not imposed
Conditions. AWS sets conditions inline; product wanted a separate module. I put five questions to the product manager; his answer was cognitive load, since one condition can apply to many roles, and he was open to inline authoring too. We kept both paths.
Trust and Delegation. My first design treated them as one module. When product flagged that Delegation was being treated as a variant, I split them into two separate flows.
Catching my own mistake. I proposed a tree to show a user's accounts and cells, then realised it breaks when search must show matches together, and moved to expandable rows before anyone else flagged it.
Working method
Once the Cloudscape design system was mandated, I shifted to AI-directed, surgical prototyping, which respected the platform's micro-frontend boundaries.
Designing while the ground moved
IAM touches almost every part of the console, so the constraints came from everywhere:
I audited AWS IAM closely, then pushed for a provider-agnostic model so the design wasn't locked to one cloud.
I designed the model first, so screens could change without the concepts changing underneath them.
I moved to surgical, AI-directed prototyping, where careless changes across modules were costly.
Super Admin sat outside Cell scoping; the new hierarchy made the Cell the access gate for everyone.
What I gave up, on purpose
Every simplification in IAM gives up some flexibility. These were the ones worth making.
| Decision | What I gave up | Why |
|---|---|---|
| Build in-house, not the partner's IAM | Speed from reusing existing work | Control over identity was the point; the partner's walkthrough was mined for ideas only |
| Policies bundled into permission sets | Writing custom policies from scratch | Far less room for error; enough flexibility for now |
| No customer inline policies | Fine-grained one-off rules | Keeps access auditable and explainable |
| Conditions authored in both places | A single, simpler entry point | One condition applies to many roles, but people also expect it inline |
| One Overview page trimmed by persona | Two tailored pages | One source of truth, still relevant to admins and users |
| Expandable rows instead of a tree | A more visual hierarchy | Trees break when search must show matched accounts and cells together |
The impact
Not yet live. Engineering is building on a prototype with finalised permission sets, roles and grants; the formal product review is pending. I keep "decided in review" and "shipped" as separate claims.
What I learned: once my hands-on scope shrank, most of the leverage came from review, decisions and AI-directed execution. The job isn't avoiding AI-assisted thinking — it's knowing precisely which parts of the output are yours.