Building the system

I joined Wildeye as someone who drew screens and handed them over. Three years on, the most useful thing about me is that I don’t stop at the drawing. I commit to the front-end repositories. Not prototypes in a sandbox, the production Vue that customers use, reviewed like anyone else’s.

That changes what a design conversation is. Instead of arguing about whether something is feasible, I go and find out, then come back with either the component or the reason it doesn’t work.

The mobile app. React Native, sharing no code with the web product, only the token layer. Same colours, type scale and spacing, scrolling its own card stack.

What that bought the company is a cycle time. A demo or a feature release used to mean several critique sessions with a developer to get the spacing right, then the fonts, then the small things, all of it soaking up the software team’s hours. Custom work for one large customer was a bespoke build and a month of design. Now it is an assembly job with about a week of thinking on top, and the thinking happens while the building is already underway.

Anyone can build features now. That is what changed while I was learning to ship. What stayed scarce is someone who keeps a product coherent while several people build into it at once: watching for UI drift, paying down UI debt, holding the thing together from the marketing side and the software side at once. That is the job I grew into and the one I want next.

The line I’d lead with if I only had one: I can hold the brand and the codebase in my head at the same time. Most teams have someone who protects the visual language and someone who protects the architecture, and a lot of what gets lost is lost between them. I’m useful in that gap. Sixty-five components, documented →

And something got worse, because something always does. I lean on my own drawing less than I used to. When a tool puts six variations in front of you in a minute, the habit of sitting with one and working it through gets easy to skip. I still make the first version myself, on paper, before anything else touches it, but most of my thinking now goes into architecture rather than into individual screens. Being the person who draws well is worth less than it was, and I would rather say that bothers me than pretend I planned it. Where I have landed is that the value moved to judgement: which of the six is right, why, and what it costs to maintain.

Wildeye builds the instrumentation that tells people what their water is doing. Loggers in the ground and on the pipe, measuring level, flow, pressure, soil moisture and weather, reporting to the cloud around the clock. Four markets: agricultural monitoring, irrigation districts, water utilities, and environmental and geotech work. Three countries. When a Californian district bills a grower for water, or a council answers for a consent, the number they use comes off this hardware.

The hardware was good. The software you looked at it through was two products that had grown up separately: a web app and a React Native mobile app, sharing a customer list and not much else. Different navigation, different buttons, different words for the same thing. A lot of the older web screens were .NET pages rendered inside an iframe, written in 2008. I joined in 2023, out of university, as the first designer they’d hired.

The team was small. A lead engineer and a senior engineer, one mid-weight who started the same week I did, one dedicated tester, and me. Above us, a rotation of CTOs, most of whom did not stay long. Anything I wanted to change, I had to change with those five people, and the person setting direction kept being a different person.

My first instinct was the obvious one. I started redrawing screens, because that’s what a new designer does and it’s the part of the job that feels most like the job. I got good at it. The files looked excellent.

It took a few months to see the problem. I could redraw every screen in the product and the next one anyone built would still be wrong, because a mockup only fixes the screen it’s a mockup of. There was no shared idea of what good looked like underneath it. Not a bad one. None at all. When a feature needed a dropdown, whoever built it decided what a dropdown was that day.

It was worse than ordinary inconsistency, too, because Wildeye sells through resellers. Other companies put their own logo on this product, so the drift was never private. Every reseller saw it, and their opinions arrived as support tickets.

By this point the system was specified properly in Figma. Components, states, spacing, the lot, with dev mode on so every measurement was a click away. I’d done the thing I was taught to do and I’d done it well.

What I hadn’t accounted for is that a spec only works if the person receiving it is comfortable in the tool it lives in. The developers on this product had been writing software for decades, most of it back-end, and they’d never worked in Figma. Not reluctant, just unfamiliar. Opening a file, finding the component, reading the panel, knowing which number mattered: all of that was new, and none of it was their job as they understood it.

So the file didn’t get opened much. Screens got built from a screenshot and a memory of what it should look like, and the result was close. Close, repeatedly, across a whole product.

What the spec described. Active, Pending and Invite in one place. Click around: invite who, to what, as which role, and the invites land in Pending. Built from the design system’s own components.

Nobody was at fault here, and that took me a while to accept. I came out of university assuming a Figma design system was simply how software gets made, because everywhere I’d worked, it was. This was a gap between how I’d been trained and how this team actually worked, and I was the one who’d turned up expecting the other side to have moved.

The lesson is the one I’d give anyone joining their first team. Doing everything right doesn’t guarantee it works, and when it doesn’t, the thing that has to change is you. Not the standard, and not the people. The method.

Two options and I didn’t like either. Keep writing specs for a team that read them as suggestions, or learn production Vue well enough to ship the components myself. The second was right and it was also about a year of work I didn’t have.

What closed that gap was AI-assisted development, and the useful part wasn’t code generation. The system already existed in Figma as a proper token structure. Wiring the Figma MCP into my editor meant the file stopped being a picture of the system and became a source I could query while writing code. I could pull the real value of a token, the real spacing, the real states, straight into a Vue component in the actual repository, without transcribing anything by hand.

That’s what changed the job. Not the speed, though it was faster. It was that the translation step, the one place the system had been losing fidelity for a year, stopped being a person retyping numbers between two tools.

Then I made the mistake that taught me how to work with engineers. I built the design-first branch as a showcase: around sixty hand-built components plus whole pages assembled out of them, put up for review in one go. I thought I was demonstrating value. What I had actually done was hand two engineers a review containing sixty new components, at a time when none of it could be checked automatically. It had to be read by hand. Nobody was going to merge that, and they were right not to.

Small and fast is how I work now. One component, or one fix, reviewed and merged, then the next. It is slower to describe and much faster in practice, and the difference between those two things is most of what I learned in three years. Every new feature release is built on the library now. Some things still have to be bespoke, but everything that can be systemised is.

Components in a repository still need somewhere people can see them without reading source. Storybook became that, and it’s the point the system stopped being mine. Every component, every state, every prop, in the tool the engineers already had open. Getting it wrong now took more effort than getting it right, which is the only version of a design system that survives a deadline.

That period was uncomfortable. I was slower at writing Vue than the engineers and better than them at knowing what the component should be, so everything took longer than it would have taken either of us alone. My title didn’t change for another year. The job did. The arguments got much shorter, because I wasn’t describing a component to someone who then had to rebuild it from the description.

A flow meter, a rain gauge, a soil moisture probe and a vaccine fridge are all sensors, and none of them wants to be drawn the same way. Thirty-three widget designs, and the dashboard at the top of this page is where a component library either holds or turns into thirty-three special cases.

The five I’m most pleased with are bespoke instruments: a Delta-T gauge for spray conditions, a soil moisture gauge with the refill and full points marked, a wind compass, a fire danger index, a barometric trend. Each is a reading a grower acts on, so none of them could be a generic chart. They’re documented individually →

Then the harder test. The mobile app is React Native, so it shares no code with the web product at all. It shares the token layer, which turned out to be the part that mattered. Same colours, same type scale, same spacing rhythm, rebuilt in a different framework by a different person, and nobody had to compare screenshots.

The same app, before and after the token layer reached it. The right-hand phone is running, not a screenshot. Count the header rows on the left, then look at what a reading became on the right: a card with a title, a period, a number and a change against the last one. Nothing here was redrawn twice. The mobile team read the same tokens the web team did.

Sign in and settings, rebuilt on the same token layer as the dashboard above. Two frameworks, one set of colours, one type scale, one spacing rhythm.

None of this was for its own sake. Wildeye sells hardware, and everyone in the market sells hardware. The sale is whether a customer believes the software will still be good in five years.

The clearest example is Arvin-Edison Water Storage District, a California water district in the San Joaquin Valley with more than 500 metered turnouts. Reading those meters by hand took eight to twelve hours a month, and billing disputes came out of readings nobody could verify. Their operations manager put the old problem better than I can: “We are supposed to rely on trust that people turn on and off when they say they do.”

It started as a pilot with a few board members and some of the younger growers. It became a full rollout across all 500 turnouts, and the district recovered the cost inside two years.

Part of what made that case was a compliance map: live flow laid over the water orders from Latis, the district’s own ordering system, so an operator could see at a glance who was taking what against what they had ordered. Continuous readings rather than the single daily snapshot the old meters gave.

The decision I’d defend hardest: tolerance isn’t one number. Half a foot over inside a booked window is a rounding error. Any flow at all outside one is unauthorised, however small. Treat those the same and the screen either cries wolf every afternoon or misses the thing it exists to catch. The status vocabulary it uses →

I designed that map with a senior engineer who built the data side. I’m not claiming the deployment. Hardware, installation, integration and a lot of field work closed that deal. What I’ll claim is the design and product thinking behind the screen that made the value legible in a room, and it’s the first time I watched something I designed change how the business grew rather than just how it looked.

What it looked like from their side once it was running: “We gave access to one of our growers, and he immediately started catching issues with his irrigators.”

That’s what the system was for. Not consistency for its own sake. Before it, a screen like this was a bespoke build and a month of design. Now it’s an assembly job with a week of thinking on top.

Every Arvin-Edison figure and quote here is from Wildeye’s own published case study, including the 500-turnout count, which is the company’s figure and not mine. My contribution was the design and product thinking on the compliance map, with engineering.