OpenTreatment, a healthcare app that shows prices upfront
Most self-pay patients only find out what care costs at the billing counter. OpenTreatment lets them compare verified doctors, hospitals and labs, with the full bill, before they book.
Scope of work
End-to-end product design, 0 → 1, from research to developer handoff
Patient app: discovery, comparison, booking, payments and tracking
Provider platform: onboarding, listings and price management
Design system: 10 component sets, 77 variants, WCAG AA
AI-assisted workflow with Claude and Figma MCP
Partnered with founders and engineers on healthcare workflows
stuff I’ve made · 02Focusoft HQUX redesign
RCFeed, helping hobbyists find their corner
An RC hobby community where new visitors couldn’t find builds for their kind of craft, and left. I restructured the experience around what hobbyists come to do.
Scope of work
Led the UX redesign: information architecture, flows, UI and handoff
New structure: Builds, Parts, Marketplace and Discuss
A 0 → 1 patient app for comparing verified doctors, hospitals and labs on price, quality and availability, plus the design system that holds the whole platform together.
Role
Founding designer, end to end
When
Jan 2026 to now
Scope
Patient app, provider platform, ops panel, design system
Status
Built and running on Android with test data, pre-launch in Delhi NCR
Tools
Figma, FigJam, Claude with Figma MCP, ChatGPT
the short version
Self-pay patients usually find out what care costs at the billing counter. OpenTreatment shows the price, the full bill and the alternatives before they book.
I designed both sides of the marketplace and one design system for the patient app, provider platform and internal ops panel.
Price is one signal, not the only one: the app helps you compare on cost, rating and the soonest slot, then books in one sheet for anyone in your family.
1
The problem
the bill is the surprise
For people paying out of pocket, the hardest part of seeing a doctor often isn’t the doctor. It’s not knowing what the visit will cost, whether the doctor is genuine, and whether there was a better option two kilometres away.
OpenTreatment’s promise is simple: honest prices, verified providers, no surprises at the counter. My job was to turn that promise into an app people trust enough to book through, and keep it true on every screen.
Show the whole billFees, platform fee and GST each get their own line, before payment.
No race to the bottomThe default sort is a weighted recommendation, never cheapest-first. Price sits next to quality.
Self-pay firstInsurance is shown as information, not as a checkout path. We don’t promise what we can’t deliver.
2
Who I designed for
three people, three tests
Before any screens, I wrote three personas. Each one exists to force specific design decisions, so every screen could be checked against a real person instead of an opinion. They are hypothesis personas, and the plan is to validate them in the first month after launch.
Anita, the default user → ≤3 taps to bookRamesh, the trust & accessibility test → big type, verified badgesPriya, the caregiver test → one login, the whole family
what we’re not designing for yet
First-time digital health users in tier 2 and 3 cities, who need vernacular, low-data, high-trust flows. This needs on-ground research first.
Paediatric caregivers, emergency and SOS users, and providers booking on a patient’s behalf. Each needs its own persona work and its own flow.
Writing down what v1 would not do was as useful as the personas. It stopped scope creep before it started.
3
Key decisions
four moments that build trust
decision 01
Compare, don’t just list
A list of 248 doctors is overwhelming. Patients can pick up to three doctors straight from the results, then swipe through them side by side.
Instead of ranking by price alone, each attribute gets a tag: Cheapest, Top rated, Soonest. The patient sees the trade-off and makes the call.
whyCheapest-first sorting would push providers to undercut each other and teach patients that price is the only thing that matters. Tags keep price honest without making it the whole story.
decision 02
The full bill, before you pay
The payment summary breaks the total into consultation fee, platform fee and GST, each on its own line, with the total in the largest type on the screen.
UPI comes first because it’s what people already use every day, and Pay at clinic is always there for anyone who isn’t ready to pay online.
whyThis is the brand promise in one card. If any fee only appears at the counter, the product has broken its word. Ramesh is nervous about paying online, so he gets a familiar method first and an offline way out.
Ramesh: UPI-firstno hidden fees
decision 03
One sheet to book, for anyone
Booking happens in a single bottom sheet over the doctor’s profile: in-person or video with the price on each option, then a date, a time, and who it’s for.
“Who is this for?” sits inside the booking flow, not hidden in settings, so booking for a parent takes one tap.
whyAnita wants to book in seconds. Priya books for her mother, her husband and herself. The same sheet covers both without extra screens.
Anita: ≤3 tapsPriya: book for family
decision 04
Design the unhappy paths too
Demos show the happy path. Real patients hit wrong OTPs, expired codes, closed cancellation windows and dropped connections.
When it’s too late to cancel, the sheet explains the rule in plain words and offers the next best thing: reschedule at no charge. No dead ends.
whyTrust is won or lost on bad days. I built 4 reusable patterns (empty, loading skeleton, toast, offline banner) and 10 state variants and applied them to real screens, not a separate sticker sheet.
4
One design system, three products
the part nobody sees
The patient app, the provider platform and the internal ops panel all needed to feel like one company. I built one Figma design system for all three, with usage rules written for engineers, not just a component library.
10component sets
77variants
3products, one system
“Never two Primaries on a screen. If you think you need to, you have two screens.”a usage rule from the button docs
AI audited it for accessibility
Ramesh reads slowly with his phone font set to Large. So I audited the system against WCAG AA: 15 text-on-background pairs, 4 failed. I fixed them by darkening the colour tokens at the source, so every screen inherited the fix at once.
Token
Before
After
Where it shows up
color/text/subtle
1.56 : 1
4.74 : 1
Placeholder hints. Was barely visible.
color/text/muted
3.01 : 1
5.67 : 1
Every helper and metadata label. The highest-impact fix.
color/status/warning
3.03 : 1
4.95 : 1
“Running low” chips and overdue states.
Touch targets
Comfortable button 56pt, for page-level actions
Default button 48pt, meets Material’s 48dp
Compact 40pt, only inside fully tappable cards
Back chevron 40pt, flagged to grow to 48pt in v2
Still to test on real devices
VoiceOver and TalkBack sweep of every screen
Dynamic type at 150%, 200% and 300%
Outdoor glare and low-vision sessions
Colour-only signals: 3 spots found, fixes queued
5
Where it stands
honest status
The patient app is built and running on Android with test data, ahead of launch in Delhi NCR. There are no launch numbers yet, so here is what I’ll measure to know whether the design is working:
Signals I’ll watch
Taps from opening the app to a confirmed booking
How often comparing leads to booking
Share of bookings made for a family member
Drop-off on the payment summary
Late cancels saved by “reschedule instead”
Personas are most useful when each one forces a decision you can point to on a screen.
Fix accessibility in the tokens, not screen by screen. One change, every screen better.
case study 02 · community
RCFeed: helping hobbyists find their corner
A UX redesign of an RC hobby community. New structure, new navigation and photo-first build cards cut the bounce rate by 26%.
Role
Product designer, led the redesign
Where
Focusoft HQ
Scope
Information architecture, navigation, interaction flows, UI
Result
−26% bounce rate, more engaged sessions
the short version
RCFeed is where radio-control hobbyists share builds, find parts, buy and sell, and talk shop.
New visitors landed, couldn’t find builds for their kind of craft, and left.
I rebuilt the structure around what people come to do and how the hobby is organised. Bounce rate dropped 26%.
1
The problem
a drone flyer doesn’t care about boats
The RC hobby isn’t one hobby. It’s planes, cars, helicopters, multirotors and boats, and each crowd has its own language and gear. Someone who flies 3-inch quads wants to see quads, fast.
When everything is mixed together, a first-time visitor can’t tell in a few seconds whether the site is for them. So they leave. That was the bounce problem.
2
What I changed
structure first, pixels second
ANavigation built around jobs
Four destinations, one for each reason people visit: Builds Feed to get inspired, Parts Feed to research gear, RC Marketplace to buy and sell, and Discuss to ask questions.
BFilter by craft first
The filters follow how hobbyists already think: Aircraft, Landcraft, Rotorcraft, Watercraft, each opening into sub-types like Warbirds, Cars, Helicopters, Multi Rotor or Scale, plus a Build Type filter. One tap and the feed becomes your corner of the hobby.
CPhoto-first build cards
1234
Craft tags on the photo. You know what it is before reading a word.
Full Build or Build Log badge. Finished project or work in progress, at a glance.
Author and likes. A real person and some social proof, so it feels like a community, not a catalogue.
Title, views and age. What’s popular and what’s fresh, without opening the post.
And one clear action on every feed: a red New Build button, so sharing your own build is always one click away.
3
The result
−26%
lower bounce rate after the redesign, with longer, more engaged sessions.
4
What I took away
Bounce is usually a findability problem before it’s a visual one. Fix the structure first.
Use the words your users already use. “Rotorcraft” and “Full Build” beat any label I could invent.
