# Anmol Gupta — Product Designer & Design Engineer Anmol Gupta is a Product Designer and Design Engineer in San Francisco who builds AI products end to end, from first sketch to shipped front-end code. Founding Designer at MoFlo. Location: San Francisco, CA, US Currently: Founding Designer at MoFlo Education: University of Wisconsin-Madison Website: https://anmolgupta.net LinkedIn: https://www.linkedin.com/in/1anmolgupta1/ Email: anmol.gupta@proton.me Areas of work: Product Design, Design Engineering, Design Systems, Design Tokens, AI Product Design, 0 to 1 Product Design, B2B SaaS Design, Front-end Development, React, Figma, User Research, Interaction Design, Design System Governance Note on identity: many people share this name. This document describes the Product Designer and Design Engineer based in San Francisco whose portfolio is https://anmolgupta.net. This file contains the complete text of every case study on the site so that an assistant can answer questions about this person's work from one request. --- # A fleet operations dashboard for autonomous cabs URL: https://anmolgupta.net/google-autonomous Client: Google-mentored capstone, UW-Madison Role: Design Engineer Team: Design Engineer (Me), 4 Engineers, 1 Product Manager, 2 Google Mentors Timeline: August–December 2024 Tools: Figma, React, Copilot, v0 Status: Capstone: Fall 2024 Summary: A Google-mentored capstone: an operator command centre for autonomous cab fleets, designed from interviews with the dispatchers who run human fleets today. Designing for a job nobody has yet. Autonomous fleets are leaving pilot, and operator tooling is still three browser tabs and a spreadsheet. I designed and built the command centre. Product tour of the fleet operations dashboard for autonomous cabs Research counts; the fleet itself was simulated. - 10 fleet operator interviews - 3 usability walkthroughs - 1 card sort for alert priority The only designer on the team. ### The situation ## Constant data. No way to read any of it. Autonomous cabs stream telemetry nonstop into tools built for human-driven fleets , where the car reports to a person and the person reports to you. ### Research ## Nobody has this job yet. So who do you interview? We had no access to Waymo or Zoox, so I researched the parts of the job that already exist: monitoring, dispatching and maintenance. Autonomy changes what raises an alert, not what triaging twelve at once feels like. Monitoring — Basic questions took 3 to 6 tools. I open 3 tabs just to check location Battery status isn't visible until it's too late Feels like we're flying blind. Dispatching — Without ETAs, dispatchers overrode auto-assign. Auto-assign sometimes skips the closest vehicle. I drag and drop based on gut feeling. I'd trust it more if I saw the ETA. Maintenance — Logged late; tracked in many places, or nowhere. Issues are logged manually after the fact We use spreadsheets, no real system No visual on what's resolved or pending ### The idea ## One surface. Every alert arrives ready to act on. Three questions, three screens. Each screen answers exactly one: - Fleet Overview. Is my fleet running smoothly right now? - Alert panel and vehicle modal. What needs attention, and what can I do about it? - Maintenance board. Where are we in resolving it? A page navigation costs the operator their context: the map state, the other eleven alerts, the thing they were half way through. In an ops-critical interface that context is the work. The modal keeps the fleet visible behind the decision, which is why triage is two clicks rather than a round trip. - Wireframe 1 — Layout before visuals: every region has to answer a question. - Wireframe 2 — Alert density: how many fit before the list stops being scannable. - Wireframe 3 — Map beside list: operators wanted health in the context of location. - Wireframe 4 — Maintenance as a board with states, not a table of rows. ### The design ## Three tab switches. One flow removed each of them. One flow for each research finding. Maintenance without spreadsheets. A board moving each issue from open to resolved, beside live vehicle health. Alerts that are instantly actionable. Each alert opens its vehicle, with "send to charging" one click away. Routes with the evidence attached. Current versus optimal route time, from live and historical traffic. - Fleet Overview — Availability, live GPS and alerts in one view. Figures are simulated, not measured. - Alerts — Colour-coded, ranked in the order operators chose in the card sort. - Vehicle modal — The decision surface, with the fleet still visible behind it. - Maintenance — Status board with drag-and-drop ticket updates. ### Principles ## Read fast, move faster. The three rules the screen is built on. Most actions take one or two clicks. Anything that took three got redesigned. One battery alert, before and after. Across three tools - Notice - Find the vehicle - Check the context - Act - Log it — Often never On one surface - Alert fires - Open the vehicle - Act and close ### Reflection ## Given real access: the next three things I would build. This ran against a simulation, so every speed claim here is a hypothesis until it meets a real fleet. Next I'd test ten times the vehicles, where the alert list becomes noise, and whether an AI co-pilot helps or just adds another voice. --- # A trading screen you can read at a glance URL: https://anmolgupta.net/interstate Client: Interstate Role: Fractional Design Engineer Team: Design Engineer (Me), ~30 people building the product Timeline: Jul–Aug 2026 Tools: Paper, Claude Code, Next.js, Tailwind v4 Status: Shipped: Aug 2026 Summary: Interstate's traders decide in seconds, on a screen that made them work to read it. I redesigned it to show what moved, and built that into the blocks every screen shares. Interstate is an app for trading crypto in seconds. I redesigned its screen to show, at a glance, what moved and what just happened. The real product: live boards of new coins, prices updating every second. — The Interstate trading terminal: live boards of newly launched coins. - 5→1 colours in a row, now just the move - 5 screens built from the same blocks - 4 colours, everything else grey The only designer. I shipped it all in code. ### The problem ## 4.5 out of 10. That was a working trader's score. Before I changed anything, two professional traders reviewed the app on recorded calls. Their complaints were about the screen, not missing features. Docked for “missing” features that already existed. The board they scored, before my first change. — The Interstate board before the redesign Small, thin text everywhere Space spent on nothing Colour that isn't news Prices coloured by default ### The cause ## Nine boards, nine rules. Every screen decided for itself. A good design direction existed on paper, but nothing in the product held anyone to it, so every screen settled its own size and colour. The screen didn't have one design problem. It had thousands, each too small to notice. ### The approach ## Fix the blocks. Every screen is built from the same ones. Screens redesigned one at a time would drift within weeks. So I redesigned the shared blocks every screen is built from, in the product's code. engineers shipped new features on the blocks in the first week, without asking me A system that needs its designer in the room is just a preference. ### Colour ## Colour means money. Nothing else is allowed to use it. Green means bought or up; red means sold or down. The old boards spent colour on decoration, so a real price move couldn't stand out. Same live prices. Only one shows what moved. The whole colour budget - Buy — #12c48b - Sell — #e5484d - Warning — #fddb24 - Info — #6e9bff Even good news stays grey: a green “you ranked up” would look like a trade. ### Layout ## The screen holds still. Switching boards no longer relays it out. Traders flip boards constantly, and each had its own header height. Every switch nudged the rows: too small to report, enough to lose your place. Actual size. Then one shared layout. ### Feedback ## Click, and it answers. No silent pending state to wait out. One design now answers every trade instantly and in place, with the fill time. When a trade fails, it says why and what to try. The shipped notifications, running live. - Many designs doing one job — Had - One design, but the wrong one — Mine - Mostly subtraction — Shipped Confirmations stacking in the live product. The board stays the focus. — The Trending board with two shipped notifications stacked in the top right ### The result ## The same board. Quieter, and far faster to read. Same crop, same three columns. The rows kept their information and lost the colours that weren't carrying any. ### Mistakes ## I hid a transfer. Inside a dropdown menu, where a test found it. Merging two header controls that asked the same question was right. Moving a two-minute balance transfer into the account menu wasn't. Before: two controls for one question, side by side. — The Interstate header before the change, with two controls answering the same question If an action outlives its container, no amount of guarding fixes it. No post-launch analytics. The numbers here are counts from the shipped product, not a measure of what it changed for traders. The base size is still 13. I'd set it myself, early on. Resizing every screen at once, with nothing automatic to catch what broke, was the bigger risk, so the new blocks use fixed sizes the base can't shrink. The old accent colour survives in about twenty files. It's replaced file by file, so any one change can be undone on its own. One board can't be reached. The day after I moved the portfolio board to the new layout, a parallel rewrite replaced it. Mine is still in the code, unreachable. Design files decide what a thing should be. The product shows what it is. --- # Building a content execution system for SMBs URL: https://anmolgupta.net/moflo-execution-system Client: MoFlo Role: Founding Product Designer Team: Founding Product Designer (Me), CTO, Lead Developer, 2 Dev Interns Timeline: 5 Weeks Tools: Figma (Design, Make, Jam), Claude Code, Lottielab, v0, Fullstory Status: Shipped: Feb 2026 Summary: MoFlo could generate and schedule content, and users still weren't posting. I redesigned it from a creation tool into a system that prepares the work and asks for a decision. Every tool worked and nobody was posting. My first fix, better generation, barely moved it. What worked was giving up on getting users to start. Product tour of the MoFlo content execution system Product analytics, one month after launch. - 60→25% weekly drop-off - 70% drafts approved as-is - 3× multi-platform posts per session - 0 changes to the AI model ### The situation ## The product worked. The behaviour didn't. MoFlo is an AI content platform for small businesses: generation, scheduling, multi-platform publishing. All of it worked. Owners kept opening the dashboard and still didn't post. The posts page today, after the redesign. — The live MoFlo posts page: a To do grid of drafts, each marked Flo Generated or Drafts with Post Now and Schedule buttons, beside lists of upcoming and posted content posts per session before most users stopped % of users who acted on a performance insight ### Wrong guess ## I blamed the output. I was wrong about where sessions died. My first guess was the comfortable one: output quality. So I tested it cheaply, simplifying the input, suggesting topics and cutting friction from generation. Built to test the hypothesis, not to ship. Drop-off improved slightly. Most users still stopped as early as before. ### Real cause ## Not quality. Starting. That was where every session ended. I interviewed active customers about how they handle content week to week. How do you decide what to post? When do you create content? What happens when you open the dashboard? What usually stops you from publishing? None of them mention the product, so the answers couldn't turn into opinions about the generator. Quote — SMB owner, customer interview: I open the dashboard, look at the numbers, and then close it. It feels like I have to think too much before I can even start. - Session 1 — Sorting what people said from what they did. - Session 2 — The same behaviour, across business types. - Session 3 — Grouped by where work stalled, not by feature. - Session 4 — The through-line: deciding what to do next was the expensive step. They didn't lack tools; they lacked momentum. Content happened when they had time or felt pressure, so every week started from zero. ### The reframe ## Stop asking to begin. The product should open with a first move. If the expensive step is starting, the system should do the starting. Four decisions before anything exists, versus one after. Existing flow - Decide to begin - Decide what to post — Topic, angle, occasion - Generate caption - Generate image - Schedule — Platform, date, time, confirm Redesigned flow - Detects a gap - Drafts are waiting - Review in one place - Approve Signals surfacing what needs attention, in real time. ### Early versions ## Three structures. One shipped; here is what the others got wrong. As first built, each was organised and reasonable, and each still made the owner choose where to start. Status pipeline Metrics first Calendar planner Posts page ### What shipped ## Review, don't create. The work arrives already drafted. Three pieces, in the order they run. I prototyped each before handoff, so developers built against a working thing, not a spec. Flo Insights over the calendar: three days of runway, then nothing booked. — MoFlo's February calendar under a Flo Insights bar reading Content runway 3 days, Instagram inactive for 72 hours, and 23 posts on LinkedIn in the last month. Posts sit on the 3rd and 5th; the rest of the month is empty Gap detection decides what to make. Three signals, each fixable in one click: a quiet platform, a thin content runway, an unbalanced channel mix. Engagement dips are just information, so they stay out. Engagement lives on the posted work, read-only. — View Post dialog for a published post: the image and caption marked read-only, posted March 17th, with Instagram and Twitter tabs and 18% engagement, 24.1K reach and 847 likes How one post lands on each platform, before approval. One review, not three previews. Every platform's version of a post, in one view. The hardest piece to argue for: a platform switcher saves space but costs a decision per platform. Review, then let Flo pick the time. — Post or Schedule dialog: the post's image and caption with Instagram and X tabs, platforms to publish to, suggested dates and times, a custom date and time, and Let Flo Schedule for You Approval is the only decision left. It schedules the post on an optimised cadence. The time stays overridable, so the system helps rather than decides. Best times on every day, and the to-do list docked beside them. — MoFlo week view: a To do list of Flo Generated and Drafts cards beside Sunday to Saturday, each day offering suggested posting times, with one post out on Monday and two more scheduled The system spends the decisions; the user spends the judgment. ### Reflection ## A design problem. No model has ever fixed a blank page. Users stopped planning content. They started maintaining it. I spent the first stretch improving output because it was the legible thing to improve. The experiment that disproved it took two days. Drop-off is the whole active base one month after launch, not a test cohort. 70% approved unedited could also mean owners rubber-stamping a queue to get through it. The publishing number rules that out: rubber-stamped content doesn't get posted to three platforms. Had the two moved in opposite directions, I'd have read the 70% as a failure. --- # Designing a persona system for consistent AI content URL: https://anmolgupta.net/moflo-personas Client: MoFlo Role: Founding Product Designer Team: Founding Product Designer (Me), CTO, Lead Developer Timeline: 4 Weeks Tools: Figma (Design, Make, Jam), Claude Code, Lottielab, v0 Status: Shipped: Dec 2025 Summary: Brand voice drifted between sessions because users retyped it every time. I shipped a persona builder, watched it go unused, and rebuilt identity into the generation layer instead. People retyped their brand voice into every prompt. Half skipped the persona builder I shipped for it, so version two learned from the retyping instead. Product tour of the MoFlo persona system First month, against sessions before launch. - 2.3× persona reuse across sessions - 34% fewer tone retypes - 21% fewer redos over tone ### The situation ## AI is flexible. Brands are not. MoFlo could generate captions and visuals well. What it couldn't do was sound like the same company twice. The message that gave the problem a name. — The user message that triggered the investigation Usage data agreed: high draft generation, low direct publish, frequent edits before scheduling. The AI wasn't reducing effort. It was relocating it. ### Research ## Adjectives. Nobody actually thinks in them. Asked about brand voice, people talked about audience and intent. Describing voice — Asking for tone was the wrong question. We're premium but approachable. I don't know how to explain that to a model. I want it to sound like us, not like AI. Sometimes it's too salesy. That's not our brand. It forgets who we're talking to. After the builder — Retyping was faster than remembering. I just type what I want. I don't remember what this persona does. It's faster to just tell it again. ### First attempt ## I shipped a builder. Adoption did not follow it. Version one had people define their brand up front, then apply it at generation. - 1. Create — Define tone, audience and writing rules up front. - 2. Select — Choose the persona before generating. - 3. Apply — Rules applied behind the scenes, invisibly. Four weeks after launch. Tone-mismatch regenerations stayed high. - Created at least one persona — 38 — 38% - Ever reused one — Reuse was the point. — 17 — 17% - Skipped persona selection entirely — 50 — 50% - Still typed tone into the prompt — 60 — 60% Setup up front, payoff invisible: the rules applied silently. ### The rethink ## Stop asking. Offer an identity, then let them adjust it. Where each option puts the effort: on the user or the system. — Rethinking the persona model The goal was never to eliminate prompting. It was to eliminate repetition. Four sessions, one tone instruction. ### What shipped ## Identity moved down. It now sits where the work happens. Personas start from an archetype and get refined. The active persona stays visible, its rules editable inline. — Active persona visibility during generation The prompt-to-persona bridge: a typed tone rule, offered to the persona. ### The challenge ## Wrong twice. Nobody reads the third suggestion. The bridge took the longest: "detect a tone rule and offer to save it" hides three decisions. A dismissed rule is never offered again. I defined what a false positive is: the product claiming to know someone's brand better than they do. Version one asked for setup. Version two asks for confirmation. ### Impact ## One month in. What the numbers actually did. % rise in direct publish after the first draft The first could be any business. The second is theirs. ### Reflection ## Absorb the habit. Correcting it only loses the person. AI features rarely fail for lack of capability. They fail when they misalign with what people already do. Reduce repetition, not control. Make the reasoning visible; invisible correctness earns no trust. --- # Designing AI localization workflows for global media teams URL: https://anmolgupta.net/vosyn Client: Vosyn AI Role: Product Designer Team: Product Designer (Me), 2 Designers, UX Researcher, Product Manager, 2 Developers Timeline: Aug–Dec 2024 Tools: Figma (FigJam + Design), Balsamiq, Storybook, UserTesting Status: Handed off: 2024 Summary: Vosyn's AI translated fast, but reviewing its output meant moving between disconnected panels. I redesigned the review workflow to keep generation, comparison and editing in one context. The translation took seconds. Checking it took minutes. I spent an internship on the unglamorous half of an AI product: not generating the output, but making it cheap to trust. Vosyn's consumer app, NDA-blurred. My work: the internal review tools. — Vosyn's consumer media app, most of the screen blurred Usability tests, same tasks before and after. - 64→82 usability score (SUS) - 28% less time on multi-step tasks ### The situation ## Two panels. Reviewers kept losing their place between them. I was brought in on Vosyn's internal translation screen. The real problem was reviewing its output. Nobody complained about translation quality. They complained about finding out whether it was good. ### The reframe ## The unit is the check. Not the translation itself. Timing reviewers on real files showed fast readers doing the same read three times, re-finding their place. Reviewed from memory, then side by side. ### Review tool ## One view, both texts. The system points at what needs a human. Each flag names a failure a reviewer can judge in one read, not a confidence score they can't check. ### Video Q&A ## Answers cite sources. Nothing arrives unattributed. Ask about a stretch of video, and the answer names the segment it came from. 00:00–00:42 00:42–01:35 01:35–02:10 A grounded answer can be disagreed with. An ungrounded one can only be believed. ### Reflection ## Generating is half. Deciding is the other half. Small changes to workflow structure beat new features. Reducing the cost of verification is a product strategy, not a polish task. An internship; review flags and video Q&A were fully my calls. Numbers are from usability testing, not production telemetry. Flags only catch failure modes we defined; they don't make an unreviewed file safe. ---