About
hi, i’m ritesh.
a product designer by role, and a systems owner by habit — design, engineering and a fair bit of product, all at once.
i grew up in kanpur — a city where everyone has a story for you, you just need to ask.
i wanted to study theoretical physics and ended up in mechanical engineering, where research found me instead. in my first year, my senior Er. Sanjay Lakshmi Narayana — an aerospace engineer who inspired me a lot — pulled me into the college’s undergraduate research society, and we published a paper on the computational analysis of winglet designs for light aircraft. that work is the reason i loved engineering. later i went to nit allahabad for short courses on python for industrial machine learning, multiphase flow and computational fluid dynamics.
then covid happened and i got pulled into politics and public policy. after graduating i gave the civil services exam two attempts. i didn’t clear it. it was the most humbling thing i’ve done, and i learned more from it than from most things i passed.
when i stepped back and looked honestly at what i wanted, a close friend from college — a product designer — told me to try design. he mentored me, wanderon gave me a chance, and design gave me the purpose and sense of achievement i’d been looking for. i learned to be a designer first. building came later, and now it’s just part of how i design.
how i work
i don’t design in a silo
the pm pulls me in when he wants a different view on a requirement. it doesn’t matter whether what i say ends up in the prd — i know our systems from years of working on them, and i’ll ask why we’re doing something the way we are. we argue over the product and the design, and both are better for it. when engineering or leadership want the full reasoning, i draft it and he builds on it. when a design needs defending, i’m usually the one presenting the case.
until eight months ago we didn’t have pms at all, so i did that part too: going team to team to gather requirements, designing, presenting to stakeholders, taking the feedback and iterating.
i’ve also worked as a developer on the wanderon website. design handoffs only cover the website, so the team works out the cms with me — what needs building and how. and i sit in a lot of backend and frontend discussions. that’s where my credibility on hard design calls comes from: engineers know i’m asking for something feasible, not telling stories.
i have one junior designer on my team. i ask her to chase the edge cases, to put her thinking on the table before mine, and to push back on my views when she disagrees.
- data first. when there’s no data, a thesis we can test and prove over time — built on literature, empirical studies and research.
- a design is only as good as the system under it. so i ask: what do we get back, how will we process it, how long until we ship, how much complexity does this add — and where could it fail?
- failures aren’t always predictable. but you can make them rarer, and design for the ones that happen.
- the transaction comes first. functional doesn’t have to be ugly, but beauty has to earn its place. fast, reliable, elegant — no compromises.
on building, and ai
building is how my design brain stretches
i build my own products — designing them and coding them. i won’t call it vibe coding. i use ai to write code, but i keep asking it what it built, what approach it took and why it chose that one. i can’t design a good system if i don’t know how it operates, and i can’t trust one if i don’t know what’s written under the hood.
every shortcut has a cost. i’d rather know what it is before i take it. how i actually use claude →
read before you run
from a wall at the ladakh marathon
take what you need for the road ahead.read before you run.
i started running last year. i’m an overthinker, and this line simplifies things for me. take only what helps you finish what you started — nothing less, nothing more.
and know yourself before you act. run without reading yourself and you won’t finish: you need to know when to pace up, when to slow down, when to rest. you don’t need a strategy for everything — you need to read the road and act on it. choose your battles.
right now
updated when something changes
- building
- an agentic design tool.
- details are under wraps — it’ll be out soon.
- learning
- how reasoning models are built, and how natural language shapes human behaviour.
- the list grows as i explore.
a few true things
no particular order
- i collect books faster than i finish them. here’s the evidence.
- i own 12 black outfits. 8 of them are identical.
- who says there’s an upper limit to how long one can sleep in a row?
- don’t leave your old electronics with me. i’ll try to service them, and they’ll die forever.
- afraid of: lizards. nothing else.
- off the clock: random sketches, anime, reading, my own product, friends and family.
- no fixed routine — a set of things i come back to and improvise daily: gym, walking or running, and quality time doing absolutely nothing.
things i try to live by
first principles
- always be humble. you don’t know the story on the other side.
- treat people the way you want to be treated.
- respect everyone, whoever they are.
- be true to yourself.
- it’s completely fine to fail. there’s no limit. just keep moving.
where i’ve been
one company, a few hats
- Current roleProduct Designer 2, WanderOn
booking, discovery and internal tools, with 2 pms, a team of 10 engineers and one junior designer. before the pms joined, i ran requirements too — and i've shipped code on the website.
- Nov 2025 — nowDesign system owner, WanderOn
i design and maintain the component library the product is built from.
- From Feb 2024Product Designer, WanderOn
joined full-time after the internship. customer-facing and internal products, from problem definition to shipped output.
- Dec 2023 — Feb 2024Design intern, WanderOn
remote. where the design system and most of my habits started.