I design products that turn complexity into clarity, especially where trust, structure, and usability matter. My strength is shaping clearer logic, stronger flows, and experiences people can understand with confidence.
01
Systems Thinking
I turn layered workflows, business rules, and constraints into product structures that feel coherent.
02
Clarity In Complexity
I design for trust-heavy domains where hierarchy and decision-making matter, across AI, Web3, SaaS, and ops tools.
03
Design With Product Sense
I connect user needs with business logic, so the result is a stronger product, not just a polished interface.
04
Collaboration That Moves Work
I align teams quickly and help move ideas from exploration into something that can be built well.
Moving work from ambiguity to execution — aligning PMs, engineers, and business stakeholders without losing design intent along the way.
Design Lead (4+ Teams)Stakeholder AlignmentDiscovery WorkshopsDesign CritiquesSprint PlanningFigma-to-Dev Handoff
Get In Touch
LET'S CREATE CLEARPRODUCTS.
Open to product design roles, collaborations, and systems-heavy work across AI, Web3, SaaS, and operational platforms. If you're building something ambitious, I'd love to hear about it.
Contact
For product design roles, collaborations, or portfolio conversations, the details below are the fastest way to reach me.
Making regulated payment flows feel guided instead of blocking.
Approach
KYC-led progressive access across onboarding, wallet, and payments.
Outcome
A clearer payments concept built around visible access states.
The Challenge
If users are blocked too early, the app feels empty. If you expose too many features too soon, it loses credibility. Financial products have to earn trust before they can ask for compliance — and most get it backwards.
The real design challenge wasn't the flows or the screens. It was the sequencing. When users hit a locked feature with no explanation, the app stops feeling like a product and starts feeling like a wall. Every dead end is a trust deficit.
Design Reframe
Instead of treating compliance as a hidden technical layer — something to get past — I made access states a visible, legible part of the journey. So the product feels honest and predictable from the first screen, not just after verification.
Core PrincipleProgressive unlock: users begin with limited but meaningful functionality and earn access to more features as trust milestones are completed.
Process
SCOPE OF WORK
Problem
Regulated flows feel blockingCompliance as a hidden layerAccess state confusion
Research
Fintech user flowsKYC UX patternsCompetitive audit
Solution
Access state architectureProgressive unlock systemGuided restriction pattern
UI & Prototype
Onboarding & KYC screensWallet & payments UIUtility & support flows
Delivery
Mobile UI kitFigma prototypeInteraction specs
Design Decisions
3 CALLS I MADE
01
State before screens
I mapped three user states — pre-KYC, partial KYC, and fully approved — before designing a single screen. The alternative was to build features first and add access gates later. That approach creates an interface full of unexplained dead ends. State-first meant every restriction was designed in, not bolted on.
02
KYC as a trust journey, not a gate
Instead of treating verification as a checkpoint to get past, I designed it as a product moment. The in-review state tells users what they can still do, what's coming next, and that the app is working with them. No disappearing into a black hole after submission. Compliance becomes part of the story, not the end of it.
03
Every restriction earns its presence
Any feature the user can't access has to explain why, show the path forward, and signal when it changes. The tradeoff was more states to design and more conditional specs to write. The payoff was an app that feels honest rather than hostile — one where restrictions are understood, not just encountered.
Key Decisions
KEY DESIGN MOVES
Selected Screens
Trust Built Into Onboarding
The KYC flow is treated like part of the product journey, not a hidden compliance checkpoint.
Wallet As Progressive Value
Once eligibility is clear, the wallet becomes the visible bridge into everyday payment actions.
Progress Visible After Verification
The partial-KYC state makes available features and next steps explicit instead of leaving users in a dead end.
Everyday Payments Made Practical
Utility and recharge flows make the product feel useful beyond onboarding by supporting familiar payment moments.
Trust Extended Through Support
History and help surfaces reinforce continuity, so the app feels like an ongoing financial service rather than a one-off tool.
01
Compliance Without Bureaucracy
Designing a regulated payments experience that still feels useful and approachable.
02
Inclusion Before Approval
Making pre-verification users feel part of the product rather than excluded from it.
03
Consistent Product Logic
Connecting onboarding, KYC, wallet, and payments inside one understandable system.
Takeaway
WHAT THIS PROJECT SHOWS
This project shows my ability to design around business rules, compliance requirements, and user trust at the same time. It reflects how I think about progressive enablement, product clarity, and useful experiences under real-world constraints.
A workflow-driven project and shoot management system for photography studios, built inside a broader studio business platform.
Workflow DesignDashboard UXService Business ToolsProject PlanningOperations Design
Role
Product and workflow experience design
Problem
Generic project tools do not fit multi-event studio work.
Approach
Workflow-first design across setup, shoots, deliverables, and payments.
Outcome
100% adoption across 100+ studios. 30% increase in monthly active users post-launch.
The Challenge
Studios end up stitching together spreadsheets, calendars, chats, and finance trackers — not because they want to, but because no product was built around how they actually work.
A wedding studio managing 20 clients doesn't have a project problem. They have a coordination problem. Multiple events, multiple photographers, multiple payment milestones — all moving in parallel, all connected. Generic project tools model tasks. Studios model relationships.
Design Reframe
Instead of adapting a generic project management model to studio work, I treated the product as a studio-specific operating system — one that mirrors how photography work actually unfolds, from booking intake through final delivery.
Core PrincipleWorkflow-first design: every screen connects to the next real step in a studio's operational flow, not just a list of features.
Process
SCOPE OF WORK
Problem
Generic tools don't fit studiosMulti-event project complexityPayments disconnected from work
Research
Studio workflow mappingPhotography business patternsSaaS workflow audit
Desktop web systemFigma prototypeWorkflow specifications
Design Decisions
3 CALLS I MADE
01
A guided flow, not a form
The new project experience is a 4-step guided journey — define details, set up shoots, plan deliverables, track payments — rather than a single flat form. This matches how studios actually think about a booking: first what, then when, then what's produced, then what's owed. Breaking it into steps makes a complex setup feel like a conversation.
02
Shoots as first-class objects
I treated shoot events as distinct entities with their own crew assignments, status, and context — not just items on a project checklist. That decision unlocks operational visibility: filter by overdue shoots, see unassigned crew, track each event independently. When shoots have their own identity, managing them stops being memory work.
03
Payments inside the project, not beside it
Client payment milestones live inside the project view, not in a separate finance module. I considered keeping finances separate — it's cleaner in isolation. But a studio managing 20 projects can't afford the context switch. Keeping payments adjacent to the work they're tied to means one less place to check and one fewer thing to forget.
Key Decisions
KEY PRODUCT DECISIONS
Selected Screens
Operational Dashboard Layer
The overview screen gives teams business context and execution visibility in one place.
Multi-Event Planning
Shoot events become the true planning surface, with structure for staffing, timing, and coordination.
Project Detail At A Glance
The side panel adds reminders, payment status, and deliverable progress without forcing constant page-hopping.
Structured Project Creation
The project setup flow captures package, shoots, deliverables, and payments in a sequence that matches studio work.
Event Coordination In Context
Event-level views pull together venue, crew, timing, and notes so planning feels operational, not administrative.
01
Real Studio Fit
Designing a system that matches the actual workflow of a photography studio.
02
Planning and Execution
Connecting project creation directly with staffing, scheduling, and delivery.
03
Financial Visibility
Surfacing payment and delivery progress alongside production progress.
Takeaway
WHAT THIS PROJECT SHOWS
This project demonstrates my ability to design for a highly specific business domain rather than relying on generic SaaS patterns. It shows how I map real operational workflows and build product structure around how work truly happens.
Web3 flows often feel fragmented and difficult to trust.
Approach
Unified overview, staking, governance, and transfer flows.
Outcome
35% lift in task completion. 25% reduction in staking flow abandonment.
The Challenge
Web3 products ask users to switch between multiple tools just to understand what they hold, what they can do next, and how participation actually works. That's not a content problem. It's a product structure problem.
The crypto-native assumption is that users already understand the protocol. Most don't. The result is interfaces that are technically accurate but experientially exhausting — lots of information, almost no guidance. Governance participation especially suffers: raw on-chain data with no context for why it matters.
Design Reframe
Instead of building around protocol capability and expecting users to navigate around it, I designed around user intent — what are you trying to do, what context do you need, and how do you act with confidence in a domain where trust is earned slowly.
Core PrincipleParticipation platform over wallet utility — governance, staking, transfers, and portfolio visibility united under one coherent surface.
Process
SCOPE OF WORK
Problem
Fragmented Web3 toolsProtocol complexity for usersGovernance hard to participate in
Governance, staking, transfers, and portfolio overview all live in one persistent navigation rail instead of separate disconnected tools. A narrower product might have done one thing better. But interchain users don't have one job — they monitor, participate, and move assets. One nav keeps context intact across all of them.
02
Structure first, visual language second
I spent the first design phase on layout logic and information architecture before committing to any visual direction. The dark, high-contrast purple system came after the product structure was resolved. In Web3, trust and clarity are both weak by default. The visual direction had to reinforce both — not just signal premium.
03
Governance as readable decisions
Proposal screens were designed to give users enough context to vote with actual understanding: full description, voting distribution, and an integrated voting interface. The alternative — surfacing raw on-chain data — would have been accurate for protocol experts. But accurate and usable are different things. I designed for the person who needs to vote, not just the one who already knows how.
Key Decisions
KEY STRUCTURAL DECISIONS
Selected Screens
Portfolio Visibility First
The dashboard gives users orientation before asking them to act across staking, transfers, or governance.
Participation With Structure
Action-heavy flows are framed as guided product experiences instead of raw protocol controls.
Governance As A Real Workflow
Proposal browsing is treated like a decision surface, with enough structure to support informed participation.
Transfers Made Product-Led
Cross-chain movement is presented as a guided action flow, reducing the sense of raw protocol complexity.
Decision Detail Before Action
Proposal detail screens slow the user down just enough to support more informed participation and voting confidence.
01
Structure Over Fragmentation
Holding portfolio visibility, governance, staking, and transfers inside one coherent system.
02
Readable Governance
Designing participation as a decision-oriented experience instead of a lightweight add-on.
03
System Maturity
Evolving from wireframes into a stronger visual and reusable interface layer.
Takeaway
WHAT THIS PROJECT SHOWS
This project demonstrates my ability to work in technically dense, emerging product categories without losing sight of usability. It also shows range across wireframing, iterative refinement, dashboard design, and system-level thinking.
A multi-module enterprise platform for managing datasets, policies, access permissions, audit trails, and compliance workflows.
Enterprise SaaSGovernance UXAccess ControlPolicy DesignAdmin Systems
Role
Product and experience design
Problem
Governance work is fragmented across disconnected tools.
Approach
Structured around datasets, policies, access, audit, and simulation workflows.
Outcome
A more operational governance product with clearer relationships across modules.
The Challenge
Policies affect datasets. Access affects users and groups. Audit logs validate whether governance rules are actually working. When the product doesn't make those relationships visible, teams stop trusting the system and start building workarounds.
Enterprise governance tools are usually assembled department by department. Policies live in one system. Access lives in another. Audit is somewhere else entirely. The result is governance as overhead — something you do after the real work, not something that enables it.
Design Reframe
Instead of building isolated modules for each governance function, I designed the platform around the relationships between them — so that a policy decision connects visibly to the datasets it affects, the users it governs, and the audit trail that proves it worked.
Core PrincipleDecisions before data — every module is designed to help governance teams make calls, not just store records.
Process
SCOPE OF WORK
Problem
Governance tools are fragmentedPolicy decisions are opaqueAudit has no product home
I started with the data catalog layer because if teams can't understand what data exists and how it's organized, every downstream decision — policies, access, audit — becomes abstract. Catalog-first meant every other module had something concrete to anchor to. Governance about nothing in particular is just documentation.
02
Policy simulation before activation
Instead of making policy changes irreversible or opaque, I designed a simulation and impact-preview flow. Teams can see which subjects, actions, and resources a policy affects before going live. The tradeoff was added product complexity. The payoff was a governance workflow that doesn't require perfect confidence upfront — test, revise, then activate.
03
AI for drafting, not deciding
I positioned AI inside specific high-complexity tasks — policy creation in plain language, catalog setup, schema conflict handling — not as a general assistant. The design question was where AI reduces genuine cognitive load versus where it adds noise. In enterprise governance, the answer is drafting and discovery, not decision-making. AI helps you start. The team decides.
Key Decisions
KEY PRODUCT DECISIONS
Selected Screens
Catalog As Foundation
The system starts by making data assets understandable so policy and access decisions have real context.
Policies With Consequences Visible
Preview and impact layers help governance work feel operational instead of buried inside forms.
Auditability Built In
Violations, approvals, and event logs make governance accountable instead of purely administrative.
Access Decisions With Structure
User and permission management is designed as a controlled workflow, not a loose set of admin toggles.
AI Support Inside Governance Work
Assistant-led patterns help with discovery and policy support without replacing the structured decision layer.
01
Cross-Module Clarity
Making relationships between datasets, policies, users, and audit trails easier to understand.
02
Admin Decision Support
Designing interfaces that support both routine management and high-stakes governance choices.
03
Useful AI Integration
Integrating AI into enterprise workflows in a practical, non-gimmicky way.
Takeaway
WHAT THIS PROJECT SHOWS
This project demonstrates my ability to work on complex enterprise systems where information architecture, operational clarity, and cross-module thinking matter more than isolated screens. It reflects how I design products that need to support administrative rigor and long-term usability.
Teams need both live response tools and long-term planning visibility.
Approach
Separated real-time monitoring from fleet analytics while keeping one system.
Outcome
A dual-dashboard platform for faster response and smarter optimization.
The Challenge
When visibility is weak, teams struggle to respond quickly. When planning is weak, the same failures repeat. The problem isn't that operations teams don't have data — it's that they have the wrong data at the wrong moment.
Airport ground support runs under tight time pressure. One delayed response cascades into a missed departure. But the tools built for real-time response and the tools built for operational planning have always been separate — because they were designed for different people, at different moments, with completely different needs.
Design Reframe
Instead of forcing both needs into one overloaded dashboard, I separated the two jobs — a monitoring dashboard for live situational awareness, and an operations dashboard for longer-term fleet intelligence — while keeping both inside one connected platform.
Core PrincipleDifferent decision horizons need different interfaces, but they should live in the same system so insights from one inform the other.
Process
SCOPE OF WORK
Problem
Real-time and planning in one toolAlert stream with no contextNo link from insight to action
Research
Airport ops contextFleet management patternsControl-room interface research
The live monitoring dashboard uses a spatial map as its foundation, not rows or abstract metrics. Airport assets have location — and that location affects urgency, response routing, and zone assignment. Seeing an asset in spatial context is a fundamentally different and faster decision than reading its status in a table. The map is the interface, not just a widget inside it.
02
Zones as alert logic, not decoration
Geofences and operational zones — terminal ops, cargo, fuel, emergency services — aren't just visual overlays on the map. I used them to structure the alert model: an incident in a fuel zone carries different urgency than one in passenger services. Without spatial context, the alert stream is just noise. With it, teams can triage by location, not just by timestamp.
03
Operations dashboard that recommends, not just reports
The analytics layer was deliberately designed to suggest interventions — predictive maintenance schedules, smart redeployment, AI-driven allocation — rather than stop at diagnosis. Most reporting tools tell you what went wrong. In airport operations, knowing something is broken is only useful if you know what to do about it next. The dashboard closes that gap.
Key Decisions
KEY PRODUCT DECISIONS
Selected Screens
Control-Room Monitoring
The live map, alert layer, and asset context work together to support fast operational response.
Fleet Intelligence Layer
The analytics view shifts from incidents to recurring patterns, utilization issues, and intervention opportunities.
Fast Asset Search In Context
Search and filtering help teams pinpoint the right vehicle quickly without losing the operational map view.
Operational Trends Over Time
Analytics views help teams move from immediate monitoring into longer-term performance, maintenance, and efficiency decisions.
Alerts Linked To Action
Incident and alert layers are tied back to operational context, making the dashboard useful for response, not just monitoring.
01
Real-Time and Strategic Views
Supporting immediate response and longer-term planning in one product ecosystem.
02
Actionable Maps
Making map-based interfaces useful for prioritization rather than visual overload.
03
Decision Support
Connecting asset-level monitoring with network-level patterns and recommendations.
Takeaway
WHAT THIS PROJECT SHOWS
This project demonstrates my ability to design operational systems where clarity, urgency, and layered decision-making matter. It shows how I think about real-time products, geospatial monitoring, analytics workflows, and the relationship between tactical and strategic dashboard design.
Product Designer · Hyderabad, India
