Design, in the same language engineering speaks

IBWT builds systems where failure is expensive: high-load trading platforms, real-time services, enterprise CRM and ERP under NDA. The engineering bar is deliberately high — no juniors, everyone middle and up, Laravel, Java, Go, Vue, AWS.

What they did not have was design. Not a bad design process — none, and no product-management layer either. Interfaces emerged from whoever was closest to the ticket, which on data-dense screens produces exactly what you would expect.

Hiring a designer into an organisation like that usually goes one of two ways. Either the designer becomes a picture service, drawing screens engineering reinterprets, or they try to impose a process the engineers experience as tax. I wanted neither. More than two years in, the design function is still one person — me — and what it consists of is what I set up: review, handoff, component ownership, and the rule for where AI is allowed to act and where it is not. Everything below was built in direct conversation with the engineers who ship it, because there was nobody in between.

The conventional flow is Figma → handoff → implementation, and it leaks at every step: the file drifts from what shipped, the spec never covers the states nobody thought about, and the design review happens after the code is written.

The design system is a hand-built kit on shadcn-style semantic tokens — no Tailwind, no component dependency, so nothing in it is inherited rather than decided. A new component is written as code first, published to Storybook with its states, and only then documented in Figma for people who need to look at it rather than use it. The source of truth is the component that actually ships.

Three things follow from that. Handoff stops being a translation step, because there is nothing to translate. Design review moves earlier, since a prototype is real and can be poked at. And the Figma file stops lying, because it is downstream of the code rather than upstream of it.

Downstream does not mean careless. The Figma file is what a squad of senior engineers reads, so it is held to the same rule as the code. A component set’s variant count is the product of its axes — the input set is 42 variants because three types, two sizes and seven states make 42, and a gap in that grid is a state an engineer ends up improvising. Colour is one variable collection resolved per mode, so light and dark are the same file rather than two. And because “downstream of the code” is a slogan until something writes into the file, I wrote the thing that does: a Figma plugin and a local relay that componentise frames from the terminal, assemble variant sets from Prop=Value names, bind fills to variables instead of hex, and run each batch as one undo step. The plugin is described behind the password, with the screens and the nine ways it can fail.

Claude Code, Codex and Cursor are in the daily loop, not in an experiment. Together with the code-first pipeline they collapsed concept-to-production-ready interface to a fraction of the design-then-handoff cycle they replaced — and I will say plainly that this is an estimate from running both, not a measurement: nothing in the repository timed it, so treat any multiplier you have seen on a portfolio, including one of mine, as the guess it is.

The honest part: generation is excellent at the parts that are tedious and known — component scaffolding, state permutations, responsive variants, repetitive production work. It is confidently wrong about the parts that require knowing the domain. It will produce a plausible order-entry screen that would lose someone money.

So the standard I set for the team was simple. AI writes what we can verify quickly. It does not decide business rules, and it never touches an edge case nobody has thought through yet.

The automation I built that acts on a file rather than suggests — the bridge that pushes components into Figma from the terminal — runs on a rule of the same kind. Writes are typed commands, never evaluated code, and a batch is a single undo step, so a wrong run is one Cmd+Z rather than an archaeology exercise.

On a trading platform the interface is the last problem, not the first. Before opening anything visual I map business logic, data constraints and edge cases with stakeholders — what happens when the feed lags, when an order partially fills, when a value is stale but not yet wrong.

The canvas is where you find out you misunderstood the rules. Better to find out on a whiteboard.

The same rules carried over to the other system on the engagement: an enterprise CRM that is multi-tenant and permission-heavy, operated all day by people who know it cold. Two decisions from it travel to any operations tool. The column that tells an operator what needs doing does not show a date to compare against today; it encodes the comparison — overdue, due today, future, and an explicit no next step for the rows quietly rotting — so finding work in a long table is a colour scan rather than arithmetic. And every status of every entity — leads, deals, clients, activities, users and teams, integrations, bulk jobs, platform administration — is rendered on one Storybook page with its literal data key under each chip, so a reviewer can see at a glance which keys have no visual and which visuals have no key.

On the terminal side the equivalent is the disconnect. Over mobile data a lost connection is routine, not an edge case, so it is a designed screen with one action rather than a spinner that never resolves — and when an asset stops trading, the buy and sell controls stay visible and legibly disabled instead of vanishing at the moment the user is most alert.

• The client and the systems — the trading platform and the CRM behind it
• The component kit and its Storybook — 387 stories, and the three gates that judge the components behind them
• What the 30+ engagements were, by domain

It lives at alex.zhovnir.com/work/ibwt, behind a password — client agreements, not theatre. Send me a note and I’ll open it: alex@zhovnir.com.