Sketch Brahma — Portfolio Round

"What is this and what problem does it solve?"

It's an AI-powered proposal-management platform I designed and front-end built, live at proposal.dhrumilkherde.com. Handles proposal generation, CRM workflows, analytics, approvals, pitch-deck creation, document sharing — the whole loop an agency runs from lead to signed proposal.

"What was your role exactly?"

I owned design AND front-end engineering — React, TypeScript, Vite, Tailwind, Cloudflare Workers. Designed it and built it, using Claude Code and Codex to move fast without a separate dev handoff.

"Walk me through one decision, beyond the split-panel one."

March 2026 analytics redesign: the view was cluttered, too much competing for attention. Fixed the spacing hierarchy, restructured the table, simplified the engagement view, across desktop and mobile.

"Why design AND build it yourself?"

Speed of iteration. When I can prototype and ship changes myself, feedback loops go from days to hours — that's the actual value of AI-assisted design right now, not waiting on a dev queue to test if a decision works.

"How do you use AI tools in your process, concretely?"

Used Figma Make and Claude Code to build interactive prototypes for stakeholder feedback before any engineering touched it, then shipped the production UI in React/TypeScript myself.

"Tell me about this project."

Enterprise risk-management SaaS, a module inside a project management platform. Co-led design 5+ months — stakeholder research through wireframes to high-fidelity UI across multi-level workflows, analytics dashboards, reporting.

"Show me a screen and explain a tradeoff."

Pick one dense dashboard screen. Name the decision first — "I grouped by risk severity, not by project, because that's how the reviewer actually scans" — then show it. Don't narrate the screen before naming the decision.

"How is this different from a typical SaaS dashboard?"

Data-heavy and multi-level by nature — approval flows, stakeholder reporting, several user roles. The challenge was reducing cognitive load without hiding complexity the domain genuinely requires.

"What's this one, and why show it?"

Personal project — a pickleball rankings and match-logging app for weekly games. Shown because it's the opposite of Riskabilitie: playful identity, mobile-first, I directed the full build including a custom Elo rating engine.

"What did you actually design vs. direct?"

Designed the full identity — retro athletic-club meets arcade scoreboard — and all 5 mobile screens. Directed Claude to build the rating logic: 2v2 team Elo with margin-of-victory scaling and a contribution-split mechanic, generated the mascot art with AI.

"Why does this matter for an agency role?"

Range. Enterprise risk dashboards one day, a playful consumer PWA the next — that range is what agency work actually demands.

My process has changed a lot since AI tools became part of my workflow — it's more rigorous now, not less.

It starts with a brief. First thing I do is document everything — requirements, constraints, open questions, key decisions and why. That gets stress-tested with AI before I commit to a direction. From that I produce a PRD, which as a designer I own myself — having that document forces clarity before any visual work begins.

Then I map the full user flow and validate it with AI, checking edge cases and missing states. Wireframing is a smaller step now, because complex flows are already resolved during the PRD/flow phase.

Then I settle on a direction, experiment with one or two visual approaches, share for approval. Once locked, I bring it into Figma — I use Figma MCP, which lets AI read the documentation and generate designs directly in Figma, to produce a medium-fidelity working prototype. That goes to the client. After approval, hi-fi, test, ship to developers.

The biggest shift: documentation and clarity upfront is now the most important phase. Visual design is downstream of that.

Situation: At Codebuddy, working on CreatorCheck — a flow where a brand manager enters multiple creator emails, system auto-calculates content rates to package and send to brands.

Task: Very tight deadline, design due next day. My manager always expected working prototypes, not just screens.

Action: Because of the time crunch I skipped the prototype and submitted screens directly. My manager flagged flow issues — unclear step transitions, missing edge cases. Instead of waiting till morning, I stayed up, went through the entire flow, fixed everything, built a complete clickable prototype, delivered before the next day started.

Result: Manager approved immediately. Client signed off in a single round, no revision feedback.

I don't wait for research to start designing. First I talk to the people closest to the problem — PM, customer support, developers — they carry informal knowledge about user behavior that's never written down.

Then I use Mobbin to study how similar products solved comparable flows — not copying, looking for patterns already validated in the real world.

I map the full flow in FigJam and explicitly write down my assumptions, so the team can challenge my reasoning before I get deep into designing. I design with flexibility built in, because the first version will need iteration — the goal is a smart starting point, not a perfect one upfront.

"What's the difference between UX and UI, in your own words?"

UI is the surface — what it looks like, the visual system. UX is whether the thing actually works for the person using it — the flow, the decisions, whether it reduces friction or adds it. You need both; a beautiful UI on a broken flow still fails.

"How do you run a usability test with limited time or budget?"

5 users surfaces most major issues. I'd rather get 5 real target users on a clickable prototype for 20 minutes each than wait for a "proper" study that never happens. Watch for where they hesitate or backtrack, not just where they fail outright.

"How do you decide what to design first with limited time?"

Whatever the user hits first in their critical path, and whatever has the highest cost if wrong. Nice-to-have screens can lag; the core flow that determines if the product works at all can't.

"How do you measure whether a design succeeded after it ships?"

Depends on the product. On N1 Care it was time-to-complete a clinician workflow (cut 75%). On Duggup it was DAU, session length, retention tracked in Amplitude from day one. Always prefer a number the product itself measures over a client's own estimate — I've been burned reporting a client-estimated number without instrumenting it myself.

"How do you think about accessibility?"

Contrast ratios, real focus states, tap targets sized for mobile, never color-alone for status (pair with icon/text). It's easiest to bake in at the design-token level so it's inherited everywhere rather than checked screen by screen at the end.

"How do you organize a Figma file so it's actually engineer-ready?"

Consistent component naming, explicit variant states (default/hover/active/error/empty/loading), tokens bound not hardcoded values, and annotations on anything non-obvious. The test is: can an engineer build it without pinging me first.

"Tell me about a design system you built."

N1 Care: 80+ components, 64 icons, 86 tokens, built solo across a healthcare platform with 10 modules. On Duggup, building one shared system across web and mobile before designing screens (not after) cut testing and redesign time roughly in half — the reason was shipping pace, every two weeks, with a small team.

"How do you handle a developer saying your design isn't feasible?"

Ask what specifically breaks — timeline, technical constraint, or a pattern they haven't built before. Usually there's a version that keeps the intent and drops the hardest 10%. If it's a real hard constraint, I'd rather know before I've designed five more screens on the same assumption.

"How do you stay current with design trends without just copying them?"

Mobbin for pattern research — not to copy, to see what's already been validated at scale, then adapt to the specific constraint in front of me. Trend-chasing without a reason is how portfolios start looking identical.

1. I am here to explain decisions, not to show screens.
2. Every time I stall, I go back to the user.
3. Slow is fine. Silence is fine. Rambling is not.

Opener

"N1 Care — clinical intelligence platform, sole designer for about 7 months, team of 23. A doctor gets a new patient, history arrives as a pile of PDFs — labs, scans, prescriptions, 30-40 pages, no order. We built a system that uses AI to pull structured data out, and the doctor reviews and edits before it becomes one clean report to the patient. The hard part: the output goes to a real patient about their own health, so AI can never be the last step. My job was designing the review layer between the AI and the patient."

What you rejected (highest-value beat)

Cut the original long-form narrative report down to structured tables + top-10 issues for MVP — reasoning: long-form text is exactly where an AI hallucination hides, a table you can verify at a glance. Also built two separate design systems (platform: teal/Inter/dense for the clinician; report: navy/Segoe/spacious for the patient) instead of one shared system, because they're different rooms — one is work, one is a patient reading possibly-bad news about their own body.

Proudest decision

Made review status a first-class object in the UI — every report visibly pending/in-review/reviewed, impossible to send an unreviewed report without seeing that it's unreviewed. Wrote a 28-point quality checklist across 7 categories that became the team's actual QA process. Not a beautiful screen — the decision that made the product safe to ship.

Outcome

Clinician report time down ~75% (client-reported, be straight that it's not self-instrumented). Built React templates via Claude Code + Figma MCP, cut dev implementation time ~50% (this one you watched happen, stand behind it more firmly). CTO said week one felt like a month of collaboration — because of 26 files of platform documentation you wrote that didn't exist before you joined.

What you'd do differently

Never talked to a clinician directly — everything came through the CTO and design director, reasoned rather than evidenced. Should have instrumented the 75% number in-product before shipping instead of accepting the client's estimate after.

Opener: Social platform for engineers, founding + only designer, 2 years. Shipped v1 in 5 months, 2,000 users first week.

Problem: Engineers learn in public but existing places are wrong for them — Quora too general, Stack Overflow is answers not conversation, LinkedIn is performance. Senior engineers want to teach and can't find engaged learners.

Decision: Built one design system across web and mobile before designing screens, not after — reason was shipping pace (every 2 weeks, small team), parity drift would've killed velocity. Cut testing/redesign time roughly in half.

Second decision: Engagement design — streaks, 7/14/30/100-day challenges, leaderboards, activity graph. The failure mode of a knowledge community isn't people hating it, it's people forgetting it exists. Tracked DAU, session length, retention in Amplitude from day one.

Differently: No primary research — all competitor analysis and forum reading. Should have talked to 20 engineers before designing anything, especially for a community product where the whole question is what makes people come back.