BLR IST

THE P.S., EXPANDED

PROCESS · METHODOLOGYRECRUITERFLOW · 2023 — ONGOING

P.S.

Designing in Claude Code

PHASE 1 — BUILDING A PROCESS

The first experiment was curiosity. I had been watching AI coding tools improve and wanted to know: could I design directly in the browser, skipping the Figma handoff entirely?

The answer was yes — but not by replacing design thinking. By compressing the loop between thinking and seeing. When the output of a design decision is working code rather than a picture of working code, feedback arrives faster and costs less to act on.

PHASE 2 — REPLACING IT

PHASE 1 — FIGMA HANDOFF

Annotated Figma screens handed to engineeringInteractions described in words, not shown in motionEdge cases discovered during build, not designResponsive behaviour assumed, not testedUI review rounds: three to five per featureDesign system maintained separately from product code

PHASE 2 — DESIGNING IN CODE

Interactions defined in working code, not describedEdge cases visible during design, not after buildAnimation curves exact — bezier, as writtenResponsive behaviour tested in the design itselfUI review almost issue-free — the designer built the UIComponent library + token system built in parallel

FIG. P.1 — WHAT THE HANDOFF COULD CARRY, BEFORE AND AFTER.

HOW IT STARTED

iThe POCOMNI SEARCH REVAMP — DESIGNED ENTIRELY IN CLAUDE CODE. NO FIGMA. JUST THE INTERFACE, AS WORKING CODE.

iiThe handoffHANDED DIRECTLY TO MANISH, FRONT-END ENGINEERING MANAGER. HIS VERDICT: NOT JUNIOR-DEVELOPER CODE. IT WASN'T WRITTEN BY A DEVELOPER AT ALL.

iiiThe resultIMPLEMENTED IN 6–8 HOURS. SHIPPED, NO ISSUES. A WEEK OF DEVELOPMENT AND REVIEW ROUNDS, DONE IN A WORKING DAY. AMRI WAS CONVINCED.

ivThe scale-upADOPTED FOR THE CANDIDATE PROFILE REVAMP — THE MOST COMPLEX PROJECT ON THE ROADMAP — WITH A COMPONENT SYSTEM AND TOKEN ARCHITECTURE BUILT IN PARALLEL.

FIG. P.2 — FROM CURIOSITY TO METHODOLOGY, IN FOUR STEPS.

THE SYSTEM

COMPONENTS

Buttons, inputs, selects — all variants, all statesData tables with sort, filter, paginationCards, modals, drawers, tooltipsNavigation patterns: tabs, sidebar, breadcrumbEmpty states and loading skeletons

DESIGN TOKENS

Color: semantic roles, not raw valuesTypography: scale, weight, line-height, trackingSpacing: 4px base grid, named stepsShadow, radius, border — each a decision, not a pickMotion: duration, easing, delay — per interaction type

WHAT ACTUALLY CHANGED

“Designing in code removed the last mile between what Prakash designs and what we ship. The review is now about logic, not pixels.”

— ASHUTOSH, CTO, ON THE DESIGN TEAM'S OUTPUT

The engineering team stopped spending review cycles correcting spacing, font weights, and hover states. Those were now correct by definition — the designer had set them, in code, before the build started.

What changed wasn't just speed. It was the nature of the conversation. Engineers could focus on architecture, data, and performance. Designers could focus on interaction and information. The handoff became a collaboration.

P.P.S. — this page, like the rest of the site, was designed the way it describes← BACK TO THE LETTER