The sidebar was a different colour than the app

The navigation rail rendered in dark mode. Everything it navigated to rendered in light. There was no spacing grid, no rule about what should be bold, and a typeface that could not carry right-to-left scripts. Every page in the product had its own face.

Nobody was worried about it

My job was module strategy and user experience. The system was nobody's. So I built mockups and carried them up the chain asking for permission, until the head of R&D bought in, and later became CTO, which is the only reason the work survived.

I could never block a release. What I had was the right to define the system, and the standing to negotiate: ship the simplified version now, apply the system after.

Ant Design is built to sell things

It comes out of Alibaba, and it is tuned to fill a shopping page: generous buttons, wide corners, type sized to be inviting. Farsight runs on control-room video walls, where a module gets one screen out of a bank of them.

Ant's chrome takes up too much space relative to the content.

I did not argue that the mess was costing us deals. It wasn't: the product was pre-sale, a handful of screens, still being built. I argued the engine was wrong for the room.

I didn't write a manifesto. I built the screens.

Month one was components made the way I thought they should be (tighter buttons, slightly smaller type) and then real screens built out of them, to demonstrate that the new system fit more information on a screen while being easier to read, not less.

By month three I was selling it upward. By month six the whole system existed in Figma and the first real changes landed in the code.

An hour a day with the door open

Design Hour is a standing open room on Teams. Developers drop in with whatever design question is blocking them. It is not office hours for politeness; it is the single mechanism that got the system adopted, and it works because of who else is in the room:

While one asked a question, the other listened. And then each one saw the problem they had, and I helped solve it.

The same hour is where the most experienced front-end engineers check my work: not how it looks, but whether the states, the accordions and the focus rings actually behave. It is my only structural check on myself, and I am the only designer.

The blue failed its own test

I picked the palette with a contrast checker that turned out to be wrong. Two better tools disagreed with it, and the primary action colour, the most-used colour in the product, did not clear the bar I had claimed it cleared.

Changing it meant asking permission and interrupting engineers to repaint a live system. Users never noticed. The system changed underneath them.

4.70 and 4.51 land just past the line and not one step further: a colour moved until it cleared a standard, not one picked and then measured. Two pairs still fail. They are open findings in a live product, and they are on this page for the same reason the fix is: the audit is only worth something if it includes the part that is still wrong.

They stopped asking me what colour to use

That is the outcome I can actually point at. Alarm severities, the colours for wind, solar and battery, the spacing steps: all specified, so the questions stopped coming. I no longer build components; I assemble them, and the time that frees goes into deciding what a page should do rather than what its corners should measure.

The system was adopted as a language before it was adopted as code. The Figma library is how the product is designed today. The front-end rollout is still going, component by component, and every change of management means selling the continuation again.

The product I walked into

Farsight was a beta running a near-stock installation of Ant Design. The single clearest symptom, and the one I still use to describe it: the main navigation rail was in dark mode while every page it opened was in light mode. Not a considered contrast, an unresolved one.

Underneath that, there was no grid for spacing or margins, no rule governing what carried weight, and a typeface that could not be extended across the scripts the product needed; it broke under right-to-left reading. The asset-management screens were the worst of it: misaligned, mixed type sizes, arbitrary emphasis.

The impression it left was the diagnosis: every page of the software had its own unique face, and none of them agreed.

The request came from the R&D director. Early test users could not work out how to make the product do things. The cause was a house principle I inherited too: that no part of the screen should be left empty. Everything had to be occupied. The result was dense in the bad way: full, and unreadable.

The authority I did not have

I was not hired for this. My role was the strategy of the modules and screens and the experience of using them, not the design system. Ant Design worked, in the sense that it rendered, and nobody was worried about it.

So I took it. I built mockups on my own time inside the work, and went up the management chain presenting possibilities until one of them stuck. The head of research and development bought in, and later became CTO. That single promotion did more for the design system than any argument I made.

What I could actually do was narrower than the story usually told about design leadership. I could never block a release. Not once. I could define the system as I judged best, and I could negotiate: argue for the shape of a release, get a simplified version shipped, then bring it into line afterwards.

Everything else was advisory, and I chose to make that the point rather than the limitation:

Every design team only becomes mature when everyone starts to understand more about design. So I always tried to be a consultant and an adviser on every project I entered.

The hardest resistance came from the product owner, who did not want to spend my time or the developers' on customising Ant to the point of becoming a near-proprietary system. His objection was that a design system is an aesthetic project. That is the argument I had to win, and it is not won with a mood board:

It was never about aesthetics. It was about the trust the system would generate in the user by having something consistent behind it.

Why Ant Design was the wrong engine

I want to be precise about the business case, because the honest version is unusual: there wasn't one yet. When I arrived the product was still being built, only a few screens existed, and it was not being sold at any scale. I cannot claim the mess cost us deals, lengthened onboarding or generated support load, because at that point it had not had the chance to.

The argument I made instead was about fitness. Ant Design comes out of Alibaba, an e-commerce company, and it is built for e-commerce: to occupy screen space and attract attention. Buttons are loose, corners are wide, type is set large and inviting.

Farsight is the opposite problem. It is read by engineers in control rooms, on banks of screens where one module fills one display, and on tablets in the field. Every pixel Ant spends on being welcoming is a pixel not spent on data.

Ant's chrome takes up too much space relative to the content.

That sentence is the whole case, and it is the one that finally moved people, because it is falsifiable. You can measure chrome. You can count the rows that fit.

Order of operations

• Month 1Proof, not proposal. Built the components the way I believed they should be (compact buttons, slightly smaller type), then built real screens out of them. The screens were the argument: more information on the page, better organised, and visibly not an e-commerce look.
• Month 3Selling upward. Taking the system to management with the screens as evidence. By this point some of the developers had already bought in, which mattered more than it sounds; see below.
• Month 6The system exists, and the code starts moving. The whole system built in Figma first. Then the first real customisations to Ant: background and action colours, type sizes, and the typeface switched to Inter for its coverage across the languages the product ships in.
• TodayStill rolling out. Some components implemented, more going in. Ant is customised far enough that it no longer reads as Ant, but it is still the engine underneath.

The order matters. I did not start with tokens and work outward to a manifesto; I started with something a sceptical product owner could look at and compare against what he already had.

What the direction actually is

Four commitments, all of them downstream of one fact about the room the product is used in.

Contrast, because the room is unpredictable

The same module renders on a video wall in a darkened control room and on a tablet in direct light. Raising contrast is not a style preference; it is the only way one palette survives both.

Compact, because the screen is the constraint

More information per screen is the point of the product. Farsight is deliberately not mobile-first: it exists on mobile, but desktop is the case it is designed for, and pretending otherwise would cost the density that makes it useful.

Negative space, because compact without it is unreadable

This is the commitment that had to be defended hardest, because it looks like the opposite of the previous one. Density without breathing room is the state I inherited. The system encodes the resolution in the names of its own spacing steps:

• space-micro4
• space-compact8
• space-cozy12
• space-default16

space-compact and space-cozy sitting next to each other in one scale is the argument made structural. The system does not have a "tight" mode and a "roomy" mode fighting each other. It has one ladder, and the names say what each rung is for.

The same ladder is documented a second time, in the language the team actually uses for it:

I would defend this table over any other page of the system. Spacing is the rule engineers break most, and they break it because the correct value is arbitrary and has to be looked up. A metaphor does not have to be looked up. Nobody has ever had to ask me whether two elements are best friends.

Progressive disclosure, because two audiences read the same page

Every page opens with what a C-level reader needs and descends into what an engineer or analyst needs. Nobody gets a separate view; they get different depths of the same one.

Functional competition

"Bloomberg meets Spotify" is shorthand I used, and the idea underneath it is the reason people bought the direction. The competition that sets a user's expectations is not your direct competitor. It is every other piece of software they use.

I expect Spotify to look the same on every device I open it on, and that expectation is why I can use it without thinking. Farsight inherits the same obligation, and it gets to inherit the solutions too. Drawers that open the way PowerPoint's do. Density and table behaviour borrowed from financial terminals. Interaction patterns from Excel, Photoshop, Figma.

I'm not reinventing the wheel. I'm using the best possible wheel to make my car run.

This turned out to be the most effective persuasion technique I had. Arguing for a pattern on its merits is a debate. Pointing at a pattern already settled in software everyone in the room uses daily is not a debate. It moved decisions in minutes that would otherwise have taken weeks.

How it got adopted

This is the question I would ask, so here is the specific answer.

Evangelists before documentation

Before any of it was written down, I recruited a few engineers into the making of it. I checked spacing decisions with them, asked which colour options they preferred, asked what they thought of the look. Some of that was genuine consultation and some of it was deliberate: people defend what they helped build. It produced a more cohesive group before it produced a system.

Documentation in two places, for two audiences

Figma holds the system as designed: every component, every variant. Storybook holds it as built, so developers can copy and paste rather than interpret. And a DESIGN.md holds the rules in the form an AI coding agent can apply, so pages generated that way come out already speaking the language.

Design Hour

A standing daily hour on Teams, open door, anyone can come. Developers bring whatever design question is blocking them. It solved the support problem, but that is not why it worked:

While one asked a question, the other listened. And then each one saw the problem they had, and I helped solve it.

Question 10: how the system got adopted

One recurring meeting ended up carrying four jobs. It unblocks the person asking. It broadcasts the answer to people who had not yet formed the question. It is where I got to know the team well enough to sell them anything. And (question sixteen, the one about who checks the only designer in the building) it is where the senior front-end engineers check my work. Not the aesthetics: whether the states behave, whether the accordions and the focus handling actually work when built.

I have no design manager and no design peer above me. Design Hour is the structure I built to replace one.

The Storybook I had to build myself

The second-hardest problem was people, and I lost it:

Convincing the engineers to help me: I never got it, because of time.

Not because they disagreed. Because engineering time was allocated to features, and a design system was never going to win that allocation. For a long stretch the system existed fully in Figma and only partially in the product, and there was no route between the two that did not require headcount I was not going to be given.

What changed it was AI coding tools reaching the point where I could build the bridge myself. I tested repeatedly until I had a version of the system in Storybook that was good enough for developers to actually use: real components, not a demo. Today every prototype I make already uses the React components from that system, which means a prototype is no longer a drawing of the product; it is made of the product.

There is a second thing AI does here that matters more than speed. Once a system gets large, one person cannot hold it:

Once the design system gets very big it's hard for one person to control everything: all the contrasts and spacings and interactions. So I started writing prompts that helped me check whether the design system was working or not.

The system audits itself now, against rules I wrote. That is the part I would take to any other organisation.

What "consistent" costs

I built the tokens before the components, in the order the dependencies run: primitive values first (the raw colours, the type sizes, the spacing steps), then semantic tokens that give those values a job, then component-level bindings. Getting that order wrong is how systems end up with a hundred colours nobody can rename.

Then the components, and then the screens made from them. Which is why I can say this now, and it is the real measure of whether a system took:

These days I basically don't make components any more. I only use what we already have.

What went wrong: the blue

I chose the palette using a contrast-checking tool that had problems. When I moved to a different one, and then tested against two more, the colours I had already shipped did not hold. The action colour, the accent, the most-used colour in the interface, did not have the contrast I had claimed for it.

The fix was small in appearance and large in system terms. The primary blue is the single most-referenced token in the product; changing it meant asking for authorization and pulling engineers off other work to repaint a live interface. Politically it was the most tedious thing in this project.

Users did not notice. That is the correct outcome, and it is also why it was hard to justify.

Here is where the palette sits today, computed from the published token values:

4.70 and 4.51. Both land just past the 4.5 threshold and no further. That is not a colour chosen by eye and then measured; it is a colour moved until it cleared a standard, which is exactly what happened.

And two pairs in the same palette do not clear it. White on the destructive red measures 3.65, and the action blue used as text on the canvas grey measures 4.31. Both sit under the 4.5:1 bar that governs normal-size text. The destructive pair does clear the 3:1 bar that governs a user-interface component's own boundary; it is the label sitting on top of it that fails.

I measured these while assembling this page, which means they are open findings in a product that is live, not a story with an ending. They are here because a case study arguing that its author audits his own system is worth very little if it only shows the audits that came back clean.

The page you are reading was built the same way. Its own text, accent and secondary colours were each chosen against a measured ratio on their own background rather than picked and hoped for; the accent clears AAA on both the light and dark grounds. A case study that argues for measured colour should be able to survive being measured.

What is different now

The clearest change is one I can hear rather than measure:

What the engineers stopped asking me was which colour to use where. It's all specified now: alarm severities, the colours for each energy type: wind, solar, battery. They stopped asking me about spacing.

Questions stopping is the honest signal that a system landed. Nobody files a ticket saying "I did not need to ask you anything today."

The rest, in things a person would notice: the product reads as one product rather than a collection of pages. Spacing hierarchy has been properly calibrated over the last year, and I have gone back and repaired older pages that were built against the earlier, inconsistent version. Clients tell us the interfaces are easy to use and that they can find the important numbers quickly, which is a report on one specific decision, the KPI strip that sits at the top of nearly every page.

And the effect on my own work is the one I would argue matters most:

Designing a page became assembling blocks instead of deciding whether this button's corner is rounded. What that frees, as a designer, is time to think about strategy.

The loop now runs: prototype in code with AI first, testing everything I want to see; rebuild it in Figma, where I refine the spacing and the component usage properly; then hand it back to refine the prototype. Each pass through makes the system a little more real.

In rollout, not shipped

I would also reverse a decision, if it were mine to reverse: continuing to customise Ant Design rather than building our own system. We have now customised it to the point where it does not look like Ant, which means we are carrying the cost of a proprietary system and the constraints of a third-party one at the same time. It is not my call to make.

The numbers, with their provenance

Every figure below says how it is known. Anything I could not stand behind is not on this page.

• 26Engineers I worked with Across five teams, all of whom I served. A headcount
• 5Teams building Farsight Not six. A headcount
• 30+Engineers guided since the project began Written stories and epics for them. An estimate
• 30+Modules in the product Distinct pages, distinct functions. Reported, not counted
• 15Clients running Farsight Running in trial. Some pay, some do not; these are not fifteen paying customers. Reported, not counted
• 168Variants of one component Seven types × four sizes × six states, counted in the file
• 49Variants of the status tag Seven colours × seven treatments, counted in the file
• 17Top-level entries in the navigation rail Counted off the sidebar component. Several open into sub-items, so this is a floor under the module count above, not a restatement of it

What I got out of it was not a title. It was scope and standing: because I rebuilt Farsight from the beginning, I know how every screen works, and I have become the person engineers go to when they need to understand a part of the system they did not build.