# Harshit Singh — Product Designer Complete portfolio context. Source: https://madebyhx.framer.website Every page of the site is included below, so you can answer questions about any project, case study or role without visiting the site. --- ## Home — https://madebyhx.framer.website/ Harshit Singh Product designer who studies first, designs second. Hand me a domain I know nothing about and I’ll learn it properly, then take it as far as it needs to go. The ideas are always mine. ## Work Monk CI · Product Design (https://madebyhx.framer.website/monk-ci) Atlas · Product Design (https://madebyhx.framer.website/atlas) ## Studies Cancel Flow An interaction study on making cancellation match its actual stakes. (https://madebyhx.framer.website/cancel-flow) Delight Cards Six single-card moments for the home screen of a countertop cooking robot. (https://madebyhx.framer.website/delight-cards) ## Experience Nov 2025 - Apr 2026 Founding Designer Monk CI First designer at a pre-seed CI/CD startup. Built brand and the full product experience. May 2025 — Jul 2025 Freelance 3D Animator VR Theme Park Anamorphic screen ad built in After Effects and Blender, concept through final render. Oct 2024 — Jan 2025 Freelance Motion Designer Second Education 2D motion explainer for a yoga school, scripted and animated end to end. Oct 2024 — Dec 2024 Product Design Intern Repello AI Rebuilt core dashboard interfaces so users knew where they were and what to do next. (NDA) ## About Me IIT Roorkee · Founding Designer · 2x Inter-IIT Gold I’m Harshit Singh, a product designer. Engineer by degree, designer by choice. Founding designer at a pre-seed startup, head of design at a tech club, and a stack of self-initiated projects in fields I had no business being in yet. I keep picking up things that make me learn something new from scratch. I make films, the whole thing: I write the scripts, run the camera, shoot, and cut. I designed a service intervention for traditional cooking stoves in the mountains of Uttarakhand, a world I knew nothing about until I went looking. Different every time, same reason: I want to make something I haven’t made before. one of the best treks A silent and serene lake, best to reflect on yourself :) ~Kareri Lake somewhere in manali were you expecting something? --- ## Work index — https://madebyhx.framer.website/projects # Recent Works Monk CI · Product Design (https://madebyhx.framer.website/monk-ci) Atlas · Product Design (https://madebyhx.framer.website/atlas) --- ## Case study: Monk CI — https://madebyhx.framer.website/monk-ci # Monk CI TL;DR Monk CI is a CI/CD platform that runs automated checks on every commit and shows teams what passed, what failed, and what it cost. I joined as founding designer with no brand and no product, made a flow decision that got reversed, and learned the hard way that being right isn’t the same as being convincing. Services Product Design Branding and Motion Year 2026 ## What is Monk CI, and what did I have to learn? When engineers push code, automated checks run to confirm nothing broke. Those checks run on machines called runners, which cost time and money. Monk CI builds fast runners and a dashboard for the teams using them developers watch what failed and why, managers watch speed and cost. I'd never worked in this domain before. Before I touched a screen I had to figure out what a run actually is, what failure looks like from a developer's side, and how people live inside GitHub day to day. Docs, competitor walkthroughs, sitting with the founder until it clicked. It got me far enough to catch a problem the team had missed. ## The decision that taught me the rest The first flow connected your GitHub account, had you create a project, then connect your org from inside it. I argued the org was in the wrong place, repos, permissions, and runner options all come from the org, so putting it last meant building an empty project around the one thing it depended on. I was right. I just couldn't make the case well enough at the time, so it shipped anyway and we reversed it a few weeks later. ## Why the org had to come first The org is Monk CI's source of truth. Repos sync from it, permissions inherit from it, runner options unlock from it. A project connected to nothing is a project that can do nothing, which is exactly what the old order produced. Connect the org first, and the project inherits everything the moment it exists. ## Brand, before the product existed The founder needed something to show investors within days, so I started with the brand, logo, color, type. Instrument Sans for display, Geist for body and interface, a green built to feel fast without being cold. I'd planned Lottie animations for the feature sections, but free-plan limits killed that and I fell back to SVG. Site shipped on time. The launch video got built in After Effects and then just sat there, because launch kept slipping. ## How do you design one dashboard for two audiences? Developers live in Run History and Cache. Managers live in Analytics and Billing. Every screen had to earn its place against three questions: where am I, what is this page for, what do I do first. Three decisions show how that played out. - ### Defended by page-job Analytics started as five charts, all equal weight, all just showing current numbers. I rebuilt it around one question: is this failing more than usual? Run History doesn't have a concept of normal. Analytics is entirely about deviation from it. Failure rate became the hero, total time moved to Billing, and everything else had to justify itself against that one job. - ### Defended by reference I confirmed which fields a cache entry should show by checking GitHub Actions docs, Blacksmith, and Depot, and cut the ones no user makes a decision from. Version was the clearest cut: an internal integrity hash that lives in the database, not in anyone's mental model. - ### Defended by arithmetic 8vCPU runners are 40% of minutes but 57% of spend, because they cost double per minute. That inversion is why the cost story lives in Billing, not Analytics: it is the only place in the product where minutes resolve into money. Every figure reconciles, repo and runner spend both sum to $3,628. ## What would I do differently? A defensible decision is one whose reasoning is portable: a constraint, a reference, or arithmetic. The defense stays the same. What changes is the decision itself. The onboarding flow would have survived if I had defended it that way the first time. That is the habit I left with. Next case Atlas (https://madebyhx.framer.website/atlas) Atlas --- ## Case study: Atlas — https://madebyhx.framer.website/atlas # Atlas TL;DR Atlas is a concept for planning group trips that everyone actually agrees on. Every other trip app is a single-planner tool with an invite button; I designed the screen where the group actually disagrees. Services Product Design Interaction Design Year 2026 ## The group chat that never becomes a trip Someone drops six reels. Three people react. Two weeks pass, and the trip either dies or one person plans it alone. Nobody's short on ideas. Four people's ideas just don't become one plan on their own. Before designing anything, I used the tools that claim to fix this. ## What did I find testing Wanderlog and Mindtrip end to end? Two things. I typed my preferences into Mindtrip's onboarding chat and they never reached the trip. Its AI runs on a separate database and can't read what you save. Wanderlog's is a bolted-on chatbot you can only paste answers back from. But the real gap: neither has any idea what to do when a group disagrees. Their "group" is an invite button and a shared list. The one screen a group actually needs, the moment two people want incompatible things, doesn't exist in either. They're single-planner tools wearing group clothing. So I stopped designing a planner and designed the disagreement. ## The default answer is a vote, and a vote is the wrong tool The obvious move when a group chooses is to vote. It feels fair, but it gives you one winner and three losers. The café person loses and quietly resents a plan they said yes to. I didn't want a fairer vote. I wanted a plan nobody has to lose. Before everyone’s saved places and the constraints they arrive with, grouped by person. ## The day splits instead of picking a winner This is the screen it's all built around. Most of a trip is uncontested. The clash is narrow: Day 2, Aarav saved a steep trek, Dev's knee can't do it. Dev taps "not for me." The trek doesn't disappear. It stays and loses Dev's avatar, so it now carries only Aarav's face. Meera and Dev keep the place they added. The day didn't pick a winner, it split. I kept the place and dropped the avatar instead of removing it, because removing it deletes the person who wanted it. The face on the block is the whole mechanic: you see who's where, and nobody lost. ## The AI flags, it doesn’t decide Every other tool's AI resolves the conflict, which makes it a fourth opinion nobody asked for. Mine names the clash out loud and stops. It can find a new place or suggest a new trip, but the group decides. And it works from the folders, your real saves, not a walled-off database. The contested day. The AI names the clash, flags the budget privately, and stops. ## Agreement makes the plan Everyone reacts on their own screen, as themselves, so no one loud voice speaks for the group. The plan doesn't exist until "I'm in, 1 of 3" becomes 3 of 3. That's the moment there's a trip. ## Dignity over data Budget is measured against the shared ₹9k, never anyone’s private limit. Dev’s tighter number stays on Dev’s screen, where he can act on it quietly instead of announcing it to the group. I didn’t want anyone’s limits on display to their friends. ## The itinerary knows about the split Day 2 forks on the timeline, then rejoins for dinner. One group with a solo stretch inside it, not two people ditching a third. Scattered → resolved → settled. Day 2 splits by face: Aarav treks, Meera and Dev take the cafés, everyone reconverges for dinner. ## What did I cut? Sync only, group decides live in one session. Async is a different product. No booking, that's transacting not deciding. No discovery feed, the problem is too many ideas, not too few. Previous case Monk CI (https://madebyhx.framer.website/monk-ci) Monk CI --- ## Study: Cancel Flow — https://madebyhx.framer.website/cancel-flow # Cancel Flow TL;DR An interaction study on making cancellation match its actual stakes. Two ride apps make you argue your way out of a booking no driver has even accepted yet. I rebuilt the cancel flow so pressing cancel cancels. Services Interaction Design Prototyping Year 2026 The Problem Drivers don’t reliably come to my area. So every morning my mum and I book across a few apps at once and cancel the ones that don’t win. Cancelling isn’t an edge case for us. It’s the daily cost of getting a ride at all. The Teardown The same two flows, side by side. Both mid-search, with no driver assigned yet. Uber: a reason list with a literal Skip, then a confirm that says the trip was already offered to a driver. Rapido runs the same reason list, then a confirm that says captains are near you, so please wait. The reason step is inert. On Uber, picking a reason and skipping it both land on the same confirm screen. A step that changes nothing isn’t a decision. It’s a toll. The friction doesn’t match the stakes. No driver is assigned and nothing is committed, yet both apps still insert a reason screen and a guilt-worded confirm. The weight is uniform. Same gauntlet whether nothing has happened or a driver is already on the way. ## Friction should scale with what’s actually at stake. When no driver is assigned, cancelling costs nothing, so it should cost the user nothing. The Solution The card collapses the moment you press, and an undo slides up to catch it. One reversible gesture, in place of the whole argument. Cancel commits the moment you press it. Nothing stands between the intent and the result. A brief undo toast catches accidents. The window drains inside the pill, and that safety net replaces the gate. The reason comes after, and it’s genuinely optional. Tap anywhere to dismiss it. There’s no skip button and no thank-you screen. LIVE PROTOTYPE · TAP THE TRIP CARD TO RUN IT PickupSector 14, Block C DropCyber Hub, DLF Ph. 2 What I Cut I didn’t build the multi-app orchestrator. That’s a coordination problem, not an interaction one, and it isn’t buildable as a real thing. The design stays inside a single app’s cancel flow, done properly. Showing one thing in depth beats showing everything. ## The honest response to cancelling a free action is to let the person go. --- ## Study: Delight Cards — https://madebyhx.framer.website/delight-cards # Delight Cards TL;DR Six single-card moments for the home screen of a countertop cooking robot. They show up when the app notices something about your cooking, and each one is paired here with the banner that teases it. This was a product designer assignment. Services Product Design Illustration Copywriting Year 2026 The System A banner appears on the home screen. One line, no picture, no hint of format. You tap it and a full-screen card opens with one observation and nothing else. The banner is one component with different copy. A banner that changes its design to match its card gives away the format before you tap. The cards themselves vary completely. Different ground, different palette, different illustration approach, but some underlying artstyle. What holds them together is the frame, the chrome, and the fact that none of them congratulate you. Six banners, one component. Only the copy changes. The Cards Banner on the left, the card it opens on the right. Same treatment six times. 01 · Ten meals 10th meal cooked Ten dishes on screen, so the copy never says ten. The first and the tenth sit inside the sentence that names them. The eight in between are literally in between. 02 · The poem Mostly Indian cooking The only card with no data on it. Type carries the whole thing. 03 · Money $346 not spent on delivery These users spent $1,750 on the machine. A savings figure played straight is slightly absurd to them, so the number converts into evenings instead. $346 over 22 orders is about $15.70 each, which survives someone doing the division. 04 · Protein Recent meals have 22% more protein than the first five Five dishes at the top, five at the bottom, cropped by the card edge. The card itself is the before and after. The observation isn’t that protein went up, it’s that nobody decided to make it go up. 05 · The one for one Single-portion cook, late The quiet one. The app never says late, never says alone. The reader supplies both. 06 · Green curry Same dish, four cooks, two stars every time Four bowls, four ratings, all two out of five. Rating a dish two stars prompts the company to ask why, so the behaviour is real. The card just declines to ask. Why This Direction These are collectibles, not one template with the numbers swapped. Six cards on the same layout read as one card you’ve seen six times. Stamps, trading cards, matchbook covers, the things people actually keep, vary completely in artwork and hold together structurally instead. So the ground, palette and illustration change every card. What doesn’t change is the frame, the type, and the chrome. Tone came from the client. Their CEO shared a review calling the robot weird and idiotic, and noted the reviewer still uses it every Sunday. Not a company fishing for applause. So these don’t congratulate. They just notice. Print, not app UI. Flat colour, no gradients, no progress bars. The button says Save as print, because that’s what you’re saving. (I wanted them printed as fridge magnets, until I read that the outer shell is aluminium.) ## The data goes in the layout, so the copy can say what data can’t. The milestone card never says ten meals, because ten dishes are already on screen. It says the first one felt like an occasion and this one was just Tuesday. A count can’t tell you that. Idea to Pixels Wrote all the copy first, before I opened Figma. That’s how I found out which cards had something to say and which were a mechanic looking for content. The test for every line was whether it’d make you think, how did it know that. If anyone could work it out, it’s a statistic. The app has a moment nobody designs for. Cook running, you’re watching a slowly updating photo of your own pot with a timer going. Twenty minutes, phone already in your hand. These belong there. What I Cut A card built from the stirring arm across many camera frames, arranged into a puzzle. I couldn’t find a payoff rooted in the user’s own data rather than just being a trick, so it’s out. Also a card built around a funny face spotted in the pan, but the yellow handle sits across the middle of every frame, so that one had to go too. ## The best thing a card like this can do is notice something and then leave you alone. --- ## Playground / archives — https://madebyhx.framer.website/archives Game Design Project Figma Plugin Ride Cancellation Problem Delight Cards