Indian thrift didn't come from platforms like Depop, it grew on Instagram. Sellers build audiences through reels and drops. Buyers follow for the vibe as much as the clothes.

Drops go live → comments flood → DMs explode → sellers manually manage everything. It's chaotic. It's exhausting. And it works.

The challenge wasn't "how do we build an e-commerce app?" It was: how do we formalise this without killing what makes it work?

Sellers didn't need us, they already had functioning businesses. Contextual interviews, live drop observation, and competitor analysis confirmed it. That raised the bar immediately: any new platform had to make things meaningfully easier without breaking the behaviour that built their audiences.

Buyer needs: track drops across sellers without monitoring twenty accounts, get access through a fair process, and pay safely, not just a DM and a prayer.

Seller needs: schedule drops instead of managing real-time chaos, keep reels central, and handle high-value pieces with structure instead of first-DM-wins.

Before any screens were designed, the brand had to exist. Thrift My Drip isn't a neutral marketplace, it has a personality rooted in Indian Instagram drop culture: loud, playful, a little chaotic, and genuinely warm. The visual identity had to reflect that.

The colour palette, Statement Red, Golden Hour, Lemon Pop, Faded Tag, and Closet Black, was built around the energy of a drop moment. Statement Red carries urgency and excitement. Golden Hour and Lemon Pop bring the warmth of thrift-haul aesthetics. Faded Tag references worn labels and vintage provenance. Closet Black anchors everything.

Typography combines three typefaces: Newbery Sans Pro for headlines (structured but friendly), Lust for editorial moments (adds editorial tension), and Gopher for body text (legible and approachable). Together they create a system that can be loud when it needs to be and calm when clarity matters.

Supporting motifs, starbursts and elliptical patterns, were drawn from vintage sale signage and Indian bazaar aesthetics. Applied to social media templates, they give sellers a consistent visual vocabulary without constraining their individual voice. The system was designed to be handed off: sellers should be able to use it without a designer present.

The IA maps both user roles, Buyer and Seller, through their distinct flows. Shared authentication connects to parallel but separate navigation structures. The Seller dashboard is intentionally richer: analytics, drop scheduling, bid management, and shop admin. The Buyer flow keeps the homepage feed front and centre, with bids, orders, and profile as supporting tabs.

User anxiety wasn't about auctions. It was about missing information. Once that clicked, every decision became about closing gaps, not adding features.

Cultural specificity isn't decoration. The brand system had to feel native to Indian Instagram, not sanitised or globalised. Working with local visual references (bazaar signage, haul aesthetics, drop-culture energy) taught me that specificity is the difference between feels made for you and feels adapted for you.

If I continued building, the focus would be seller analytics, which reels drove engagement before a drop, which price points cleared fastest. Better data makes sellers better at their craft. Better sellers bring better inventory. The flywheel starts with the seller.

Status: In active development (2025). Freelance commercial project, brand system delivered and signed off, product design in build.

Cadis EziExpert connects a nurse wearing AR glasses to a remote doctor, real-time guided procedures from anywhere. The premise: expertise doesn't have to be in the room. It just has to be reachable in time.

I joined mid-project as the only UX designer on a dev-heavy team, no UX precedent, no clean slate. My job was to bring structure, clarity, and decision-making into something already moving, across four distinct user flows. It shipped. It's live.

AR Assistant (on-site nurse): hands-free, glanceable, zero tolerance for ambiguity. Cognitive load already at its limit.

Consultant (remote physician): needs annotation tools, session recording, and precision communication across distance, under potentially poor network conditions.

Org Admin: managing access and scheduling within a facility. Needs clarity and control without clinical complexity.

Super Admin: platform-level oversight across institutions. Compliance, accountability, data integrity.

These aren't roles with permissions. They're entirely different people, under entirely different pressures. One interface with permission toggles would have failed all four of them.

Each user role has a completely distinct IA, not a shared shell with permission toggles. The AR Assistant flow is the most minimal by design: one entry point, one active call screen, three actions. The Super Admin is the most expansive, managing organisations, subscriptions, and institutional data.

Joining mid-project meant the first research task was analytical rather than generative: understand what design decisions had already been made, why, and where the gaps were.

I started by researching the patient experience, which turned out to be the wrong starting point entirely. Patients in this system are not users of the platform. They're present during the procedure, but the platform is built for the people performing and supervising it. Recognising that mismatch early forced a sharper definition of who actually needed to be designed for: the nurse operating under procedural pressure, the remote physician guiding in real time, and the administrators managing access and accountability.

From there I ran a retrospective UX audit, mapping existing decisions against those user realities and clinical software heuristics. Secondary research covered AR in healthcare, telehealth UX patterns, and HIPAA compliance requirements, all used to pressure-test what was already built and identify where it fell short. I also spoke directly with nurses about performing procedures under verbal guidance alone, those conversations directly shaped two of the key feature decisions.

What the audit surfaced: the AR assistant flow was underdeveloped relative to the cognitive demands of the role. The consultant interface lacked annotation precision. The admin flows had no clear mental model separating org-level from platform-level oversight. These gaps became the brief I worked from.

The platform operates across two simultaneous environments, the AR glasses worn by the on-site assistant and the desktop dashboard used by the remote consultant. A single session requires both to be in sync at all times, with real-time video, annotation, and communication layered on top of a shared session state. Understanding how data moved between these surfaces was essential before any interface work could begin.

The admin layers sit above the session itself, managing access, permissions, and audit trails without ever intersecting with the live procedure flow. Separating these concerns structurally, so that administrative actions could never accidentally interrupt an active session, was one of the earliest and most important architectural decisions reflected in the design.

It was communication. Making design decisions legible to a manager without UX training, getting them respected through a developer review process, surviving handoff, that's a different skill from designing well in Figma. I was the only person in the room with a UX education.

Designing for degraded conditions was the most humbling part. The question isn't "does this work?", it's "does this still work when things go wrong?" You can't assume ideal circumstances.

Status: Shipped and live. Used across clinical sites. Specific deployment data is under NDA.

The project began as a brief to help autistic children in India. The gap was real and well-documented.

Primary research changed the direction entirely. Interviews with parents, guardians, and therapists made one thing clear: the children have limited agency over their own care. The people who needed better tools were the caregivers, present for twenty-three hours of every day the therapist only sees one of.

My thesis mentors confirmed it: following the evidence, even when it meant scrapping months of prior framing, was the right call. AutiMate became a caregiving tool, not a child-facing one.

Autism therapy in India typically means speech and occupational therapy sessions aimed at building reception, expression, and pragmatic skills. Progress is slow by design, therapists must build rapport with a child before meaningful work can begin. Parents want to see results. The gap between expectation and pace is one of the most consistent stressors caregivers face.

Meanwhile, parents educate themselves through YouTube, Facebook groups, and whatever they can find, often in English, a language many are not fully comfortable with. The information exists. It just wasn't designed for them.

9 interviews were conducted,6 with parents or guardians of autistic children, 3 with therapists. Competitor analysis covered 11 existing products. None combined therapy tracking, therapist collaboration, localised content, and peer community in a single application.

The therapist interviews surfaced a specific tension that shaped the collaboration flow significantly: therapists were protective of their clinical notes. They weren't unwilling to share, but clinical notes aren't written for non-clinical readers. They require context to interpret, and without that context they risk causing more anxiety than clarity.

This meant the design couldn't simply be a shared document. It had to be a structured translation layer.

The primary persona that emerged from research was Priya, a mother in her mid-thirties, living in a tier-2 Indian city, managing her son's therapy schedule alongside full-time domestic responsibilities. She is deeply invested in her child's progress but has no clinical background. She navigates between WhatsApp groups, YouTube videos, and therapist visits, stitching together information from sources that weren't designed for her.

Priya is not a passive user. She tracks everything, in notebooks, in voice notes, in her memory. What she lacks is a system that translates clinical progress into language she can act on, in a language she's fully comfortable with. She doesn't need more information. She needs the right information, structured around her role, her time constraints, and the emotional weight of what she's managing every day.

The IA challenge was building a structure that felt simple under cognitive load while housing genuinely complex functionality. Hub-and-spoke navigation with a persistent bottom nav: the most important features are always one tap away, regardless of where you are in the app.

The biggest decision on AutiMate wasn't a UI decision. It was letting research prove me wrong, and following it anyway. I stopped designing for the person I assumed needed help and started designing for the person the evidence said actually did.

That reframe, from child to caregiver, happened because I was willing to let primary research contradict my initial brief. It's the thing I'd point to first if someone asked what this project taught me about research-led design.

The community feature, though the most requested, is also the hardest to get right at scale. Moderation, ensuring the forum is safe, accurate, and genuinely supportive, is a product strategy problem, not a design problem. That's the next version of this project.

Status: Thesis project (2024). Not commercially launched, presented to a jury panel at Symbiosis Institute of Design.

TenderGenie is an AI tendering tool built for EPC and engineering teams, the people who spend their days reading 300-page RFPs, extracting scope, comparing revisions, and deciding whether a bid is worth pursuing. The problem isn't that they lack information. It's that the information is buried, inconsistent, and slow to process.

My role was research and interface design for an early-stage product at Datasmith AI. I joined when the product was still forming, before the interface had settled, and worked across user research and design to help shape what it became.

EPC (Engineering, Procurement, Construction) teams routinely respond to tenders that run into hundreds of pages. Scope extraction, revision comparison, and bid/no-bid decisions all happen under time pressure, often with multiple tenders running simultaneously.

Existing tools either automated the wrong things (document generation, not analysis) or required too much manual setup to be genuinely useful for the teams doing this work every day. The opportunity was to design something that fit into how procurement teams actually work, rather than asking them to change their workflow to fit the tool.

Research focused on understanding the tendering workflow end to end, where time was lost, where errors crept in, and where a well-placed intervention would actually change outcomes. Competitive analysis mapped where existing tools fell short for EPC specifically. Secondary research covered procurement workflows, RFP analysis patterns, and the specific constraints of engineering bid teams.

The clearest finding: the bottleneck wasn't writing the bid. It was reading and understanding the RFP accurately enough to make a good bid/no-bid call, and doing that fast enough to be competitive. Any interface had to serve that decision first.

The interface was designed around the core workflow: upload a tender document, get structured analysis out, scope extraction, revision comparisons, key clauses flagged. The visual language stayed dense and information-forward, matching how procurement professionals expect data tools to look and behave.

Design decisions prioritized legibility under cognitive load: consistent hierarchy, scannable outputs, and clear differentiation between AI-generated content and source document references, so users could trust what they were seeing and verify it quickly when needed.

The hardest design problem on this project wasn't the interface, it was trust. Procurement decisions carry real financial weight. An AI that confidently surfaces the wrong scope clause doesn't just create extra work, it creates liability. Every design decision had to account for that: how do you present AI analysis in a way that invites verification rather than blind acceptance?

Working embedded in a sales-cycle context, where the product was being demonstrated to potential clients while still being built, also shaped how I thought about early-stage product design. The interface had to work as a proof of concept before it worked as a shipped product.

Status: Commercial product, Datasmith AI. Live and in active use. Specific client data is confidential.