"I am scared to take out my car to unknown places but also want to explore the city since i have difficulty finding parking i feel frustrated at most of the times."

To help users find parking easily by providing real-time data on available spaces

To help them locate where they had parked their vehicle in case they have forgotten

To tackle the long queue during entry &amp; exit from parking

Reduce the wastage of time in searching for parking spaces

Allowing users to select spots on themselves

Provide seamless payment whichever mode user chooses to pay with

User surveys (Quantitative research) &amp; User interviews (qualitative research)

Navigation to closest parking spot to their destination

Provision to reserve spots before arriving at parking spots

"To preview additional screens of the app, kindly click on this link <a href="https://www.figma.com/proto/0q1kvAF2GhyTEQTjK2Xozx/Parked-Case-Study?node-id=3736-2376&amp;node-type=frame&amp;t=htiSntAwBWWxNzGp-1&amp;scaling=min-zoom&amp;content-scaling=fixed&amp;page-id=0%3A1&amp;starting-point-node-id=335%3A297">(Screens)</a>. Unfortunately, I can't display them here due to some animated elements."

I validated my design by testing 7 users with my working prototype. The 7 users were asked to walk through how they would book parking and search for parking spot in the app. All of the users were able to complete the tasks without any pain-points.Through guerilla usability tests, I found that users were having trouble with editing their booking after they've made the booking. My designs improves the editing option in bookings section on the homepage. Enhancing the user experience for this process means lowering user friction, which in turn will drive more users to use this application in the future.

Two key points were focused&nbsp;:

Reducing the number of steps needed to book a parking slot.

Allowing users to see their bookings and make changes accordingly.

I asked my users to complete the entire booking process to know how much time it would take an average to make them a successful booking.

Time taken&nbsp;: The average time to make a booking was 1 min 3 sec

Places where this can implemented :

Commercial areas, airports, hospitals, schools and public gathering places

The business will be totally based on comission between business provider and owner’s of parking spaces. Ceratin percantage distribution can be decided which would be the revenue generated from the PARKED app.

When there is efficient parking management, parking issues will be totally avoided or swiftly attended to. To avoid constant parking struggles, it is crucial to invest in trusted and efficient parking management quickly. It also saves time and gives comfort to every user. It also will help to protect environment by reducing smoke emissions from the car due to driving around trying to find a space.

Working on an individual concept project was a challenge for me. It limited me from intensive research but I did just the right amount of research to make an app which would impact the users daily lives. The problem which I chose is a part of people’s life today in one way or the other.

Real-time parking availability, navigation to your spot, and faster entry/exit – designed to reduce uncertainty in an already stressful moment.

User surveys (Quantitative research) & User interviews (qualitative research)

"To preview additional screens of the app, kindly click on this link 

. Unfortunately, I can't display them here due to some animated elements."

 The average time to make a booking was 1 min 3 sec

The Fear of Taking Your Car Somewhere New.

I am genuinely curious about people – how they think, what they need, why they give up on things. I travel when I can, talk to strangers more than most, and spend probably too much time noticing where everyday experiences break down.

Once I spent 45 minutes trying to book a teleconsultation on an app – not because the tech failed, but because nobody had thought about what a nervous first-time user actually needs to see. That frustration stayed with me. It's probably why I ended up designing exactly that kind of flow at Onsurity.

Good design, for me, is when someone gets through a hard moment without realising the product was even there.

1.5M members. Three disconnected booking systems. Result: a unified consultation flow – 40+ edge cases resolved, zero complexity visible to the user.

A Slot That Vanishes Mid-Payment Isn't a UX Problem. It's a Trust Problem.

IHX’s claims platform buried critical information behind complexity. Redesigned it so hospital staff could process claims without fighting the interface.

The Dashboard Nobody Wanted to Open.

AI Design Copilot that turns product problems into connected UX deliverables from personas and user flows to usability and accessibility reviews.

Instead of asking AI to generate isolated artifacts one prompt at a time, the Copilot uses the project context as a shared source of truth.


Designers provide the problem, users, goals and constraints once. AI then generates a connected UX foundation that can be reviewed and refined.

Instead of scattering UX work across separate AI conversations and documents, the Copilot brings the entire UX foundation into one project workspace.


Each artifact stays connected to the original product context and can be reviewed or refined as the project evolves.

Instead of treating personas as static documents, the Copilot turns shared product context into structured user archetypes that can guide early design decisions.


Designers can review, edit, and accept AI-generated starting points while keeping research validation at the center of the process.

Personas describe who we're designing for, but they don't directly tell us what users are trying to accomplish.


The Copilot translates each archetype into functional and emotional jobs, desired outcomes, and priorities. This creates a clearer bridge from user context to product requirements.


Designers can filter jobs by persona or job type, review AI-generated starting points, edit them, and decide which jobs should move forward into user stories.

The generated jobs describe what users are trying to accomplish. I mapped those jobs across the checkout experience to understand where friction appears and where the product can intervene.

The first three stages focus on discovery, product evaluation, and building confidence before checkout.


Discover - Find a relevant product without unnecessary friction
Browse - Understand product, delivery, and availability information
Evaluate - Compare price, delivery, and offers before committing

The second half of the journey exposes the moments that have the greatest impact on conversion and trust.


Checkout introduces friction around account creation, payment, and unexpected costs. After purchase, clear confirmation and easy access to order information become important for maintaining confidence.

Checkout - Complete payment without unnecessary steps
Confirmation - Understand that the order was successful and what happens next
Post-purchase - Track delivery and resolve issues without additional friction

AI Design Copilot - From Problem to UX Foundation

Onsurity had 8+ benefits across health, wellness, and pharmacy – all invisible to members. I designed a unified wallet that made entitlements visible and auto-applied at checkout.

 All validated results are from controlled usability testing. Live metrics will be added post-ship.

One platform. Three user types. Zero prior reference.

When I joined this project, there was no wallet. Not a bad wallet – no wallet at all. The mandate: build a unified wallet platform that could represent any current or future benefit, drive member journeys, power flex benefits, and give ops complete control – without touching backend code.

Benefits are invisible and therefore unused

Before designing a single screen, I had to map the full surface area of the problem.

Benefits existed in the backend but there was no user-facing experience for them at all.

In research sessions, 7 out of 10 users couldn't name a single benefit on their primary card within 60 seconds. Not because the feature was hard to use. Because it simply didn't exist yet.

This was a true 0→1 problem. No existing UI, no patterns to reference, no prior attempts to learn from. The business had 40+ benefit types across multiple backend programmes. Users had effectively paid for these benefits but had no clear way to view, understand, or use them.

The result: low utilisation, confusion at checkout, and frequent support queries often as basic as "Do I even have this benefit?"

The PRD told me what the system could do. The users told me how they actually think. Those were two completely different models. The taxonomy I built bridged them – it wasn't in the requirements.

I spent the first two weeks not designing. Here's what changed when I did.

I spent the first two weeks interviewing – cardholders, customer support agents, product managers, and card programme owners. Each group had a completely different mental model of how the benefits system worked.

This wasn't a UI problem – it was a systems problem

Before drawing a single screen, I mapped every constraint the system imposed on the UI.

I mapped the system constraints before drawing anything. A single transaction could hit multiple wallets at once, and even the product team didn't know which wallet would win. Benefits had category caps, monthly resets, co-pay structures, and merchant-level restrictions that varied per card programme. I was designing for a system that didn't fully exist yet.

The hardest constraint wasn't technical. It was definitional. Engineering called a benefit an "entitlement record." Product called it a "card feature." Card programme owners called it a "contractual obligation." Before any interface could be designed, those three definitions had to become one.

The easiest version of wallet combinability was a single toggle per wallet – combinable or not. We built that in week two. It broke immediately. A wallet might be combinable for doctor consults but exclusive for a specific health check package. The rule had to live at the benefit level, not the wallet level. That single architectural decision added three weeks to the engineering timeline and was completely invisible in the final screen.

My first call: don't open Figma. I spent the first two weeks creating the product's first-ever benefit taxonomy – not screens.

Because this feature had never existed before, there was no shared language for what a "benefit" even was. I built a benefit taxonomy document that became the architectural foundation for everything downstream. It grouped 40+ benefit types into 6 life categories, defined eligibility rules in plain language, and gave engineering a data schema they could implement directly.

This single artefact cut two rounds of design review

 – because everyone was reacting to the same model for the first time. The taxonomy was later adopted as the baseline by two other product squads before a single screen shipped.

The first architectural call – moving combinability to benefit level – came directly from this constraint mapping, not from the design process.

Senior design is about the decisions that don't make it into the final screens.

These decisions weren't about UI. They were about handling real-world system complexity, financial correctness, and operational realities. Most of them were heavily debated.

Each feature framed by the question a member is actually asking

The problem before it, what I designed, and what we observed in testing.

Chose to lead with wallet source because members needed to understand ownership before they could trust the balance. Showing just a number without context created confusion – "whose money is this?" was the first question every time.

What can I use this for? – Benefit Detail

Chose plain language coverage rules over showing config parameters. "Wallet pays 80%, up to ₹500" required me to define a reusable plain language format for all 40+ benefit types before a single screen was designed.

How much will I actually pay? – SKU Browse

This is the screen where the wallet system and the ranking algorithm converge. The effective price shown here – ₹349 instead of ₹499 is computed from both systems in real time. Neither system alone produces this number.

Chose to show wallet savings inline on the SKU page rather than waiting for checkout. Members were dropping off before cart because they couldn't verify affordability. Surfacing "You save ₹349" at browse moves the confidence moment two steps earlier.

Multi-Wallet Auto-Application – Checkout

Chose to show the running balance after every transaction rather than just the amount. Every entry answering "what is my balance right now, and why" was the design goal – not just "what did I spend.

I led the wallet listing page with balance as the primary information. In early testing, members froze – "whose money is this?" was the first question every time. They needed to understand ownership before they could trust the number. I moved wallet source to the primary visual hierarchy. The number didn't change. The trust did.

I assumed benefit rules could be shown inline at browse time. They couldn't – 40+ benefit types with different cap structures, co-pay rules, and redemption modes can't be surfaced at browse without overwhelming the member. I had to design a progressive disclosure system that answered the question the member was actually asking at that moment.

The product is defined by edge cases, not the happy path

Most designers show the happy path and call it done. In a financial product, the edge cases are the product. Vague rules quickly turn into real-world errors – and real-world errors in fintech erode trust permanently.

The hardest case: a user holds two wallets covering the same benefit with different monthly caps and different merchant eligibility rules. Which wallet applies? In what order? What if the first wallet's cap is partially exhausted?

 designed a clear "benefit conflict" empty state, scoped full conflict resolution to Q2 as a concrete roadmap anchor. That boundary was a product decision, not a design shortcut.

Benefits Existed. Members Had Paid for Them. Nobody Knew.

Ankit stands out for his speed and systems thinking. He took ownership of complex B2B healthcare workflows from research to launch and helped simplify problems.

Pravesh Rawat (VP of Product)

Ankit has an exceptional ability to take complex, multi-stakeholder workflows and turn them into experiences that feel effortless. At IHX, he consistently delivered high-quality designs faster than anyone I'd worked with - without ever compromising on the thinking behind them. What stood out most was how deeply he understood the product problem before touching Figma.

Aswini Puppala (Product Manager)

He is a dedicated worker. He carried out all of his obligations and responsibilities in a dignified manner.
He is constantly up for new challenges, and has delivered great outcomes in majority of his projects.
He is constantly eager to acquire new skills and put them to practice.

Jagdish Belwal (CEO)

Ankit was a good addition to our team, where he took a proactive role in creating the UI screens for our
source-to-pay product which is aimed at optimizing the procurement journey for global SMEs.

The Fear of Taking Your Car Somewhere New.

Ankit Vatsa