The wind behind a turbine is ruined wind

A wind farm is a row of machines taking turns with the same air. The first turbine takes the clean wind; everything behind it gets what is left: slower and turbulent, “messy,” sometimes hundreds of metres downstream. I still find that strange. It is also why this entry exists: before I could design a page about it, I had to understand it.

I had to learn kilowatts from kilowatt-hours

Power versus energy. Turbulence. How curtailment is calculated. Why the angle of the nacelle drifting from the angle of the wind heats the machine and loses production. Every page started with the physics, because you cannot choose a chart for a quantity you don't understand.

I drew the power curve as a bell. It's an S.

The first page, Wind Analysis, was built on the power curve: a scatter of wind speed against output, compared with the manufacturer's ideal. I assumed a bell. It is an S with a plateau: nothing below cut-in, a climb, then rated power, and past a certain speed the turbine shuts down to protect itself. Too little wind is bad; too much is bad too. The draft didn't survive the correction. The page did.

A strip for the executive. The charts for the engineer.

Two readers share every page. An asset manager asks why an hour earned less than it should have; a performance engineer asks which turbine is off its curve. So every page opens with a KPI strip (the page above opens with one too) and then the charts, two or three per screen, with room between them. Experts don't hate simplification. They hate missing information.

A developer was right about the nacelle. Then we replaced it anyway.

My first Yaw Deviation page was one chart: date against angle. A developer asked why I wasn't showing the nacelle turning. I thought it was unnecessary, then agreed: we added a wind rose with the nacelle drawn inside it. After launch that rose was redone again. The nacelle drawing came out, and the rose now shows every wind angle in the chosen window. Corrected twice, better both times.

Two weeks became two or three days

The first page took one to two weeks, most of it learning. Later pages took two to three days, because the loop changed: I brief Claude, it builds a prototype already on the design system, writes it into Figma through MCP, I do the fine pass in Figma, and it reads that back into the HTML. Two artefacts, same fidelity, and the HTML shows the error and loading states that Figma hides.

When data is missing, we leave the gap

If a turbine stops reporting, the chart shows a blank and the page says the connection dropped. We don't invent data. Not a smoothed line, not an interpolated guess.

What analysis looked like before

Before Farsight, these analyses lived in an older desktop tool as many small, separate reports. There was no quick way to move from one to another to compare them, and a client often needed someone from BaxEnergy beside them to explain what an analysis was saying.

The underlying work was math: complex equations that return a number, sometimes only a number. My job was to turn those raw results into charts a client could read on their own, and ideally into charts that could be read together, so that two of them add up to a third insight neither shows alone.

Who asked, and who reads

Everybody asked. Clients expect this kind of analysis from a platform like this. Sales uses it to sell and to generate reports. And the math already existed: the CEO knew what he wanted computed, and the Business Intelligence team owned the data. The chart choices and the page design were mine; BI checked that the data behind them was right.

Two kinds of reader use the same page:

• The asset manager thinks in revenue: this hour should have earned X, and it earned Y. They spot the outlier, then bring in analysts to find out why.
• The performance engineer thinks in machines: which turbine is off its expected curve, and by how much.

Learning the domain

Some of it sounds trivial and isn't: the difference between kilowatts and kilowatt-hours, between power and energy. Some of it is engineering: what turbulence is, how curtailment is calculated, how wind is distributed by speed and why engineers model that with Rayleigh and Weibull curves, how a wind rose works.

And some of it is mechanical. When a nacelle points a few degrees away from the wind, the turbine produces less and wears more: friction, heat, load. When a turbine's idea of north is a few degrees off true north, every direction it reports is wrong. When the first turbine in a row takes the wind, every turbine behind it breathes its wake.

The first page, end to end

The first page was Wind Analysis, in late 2025. It was also the hardest to learn, because it was the first: the power curve, the distribution of wind by speed against frequency, and the wind rose, all at once. Claude and Figma through MCP didn't exist for me yet. It was hand work.

A turbine manufacturer publishes an ideal power curve, what the machine should produce under perfect conditions: strong, steady, non-turbulent wind. The real world never delivers that. Plotted as a scatter against the ideal, the real readings show you what is wrong with a turbine.

My mistake: I had it in my head as a bell curve. It's an S, with a plateau. Below cut-in, nothing. Then a steep climb. Then rated power, flat, and above a certain speed the turbine shuts down, because producing that fast risks breaking the machine. The best production sits in a middle band, not too little wind and not too much. That band is where this page's title comes from.

I never work on this alone. A rough draft goes to the team early: engineers, the people who own the numbers. Most of those one to two weeks were spent getting it right with them. It was slow, and it is also where most of what I know about wind, solar and storage comes from.

Choosing the chart: a table that should have been a heatmap

North Azimuth Offset measures how far a turbine's idea of north is from true north. A few degrees of offset and every direction the turbine reports is wrong, which can hide problems like wake losses.

To compare turbines, I proposed a plain table. The Product Owner and the client saw it differently: they wanted a heatmap, where the redder a cell, the worse the offset. They were right. A table makes you read every number; a heatmap shows you the bad turbine before you have read anything.

Density without a data dump

Showing every chart at once causes more problems than it solves. The answer was rhythm, a fixed order to every page:

• A header that switches analyses. You change pages from the title, so the side menu can stay collapsed and the charts get the width.
• A KPI strip of four or so headline numbers, for the reader who won't open a chart.
• Then the charts, two or three to a screen, depending on its size, with negative space between them so they read one at a time. Some are small, some large, some carry two measures at once.

People assume experts hate simplification. They don't; they hate being told less than there is. Better too much information than too little, as long as it arrives in an order you can follow.

The template emerged. It wasn't designed.

When I built Wind Analysis there were no other analyses to design for, so it had no reason to be a template. The second page was Turbulence Intensity, and it came with the request for many more. That is when I moved analysis switching into the page header and added the KPI strip. Every page after Turbulence inherited both.

The hardest page: Dynamic Yaw Deviation

Yaw deviation is the gap between where the wind comes from and where the nacelle is pointing. The gap creates turbulence, friction and heat, and the turbine produces less than it should. The page ended up with seven visualizations, each harder than the last.

Version 1 · one chart

Then a developer came over: You're only showing the angle? Isn't that too little? Why not show the nacelle turning? I didn't think it was necessary. We talked it through and I changed my mind.

Version 2 · the nacelle, turning

In this case, the developer was right.Me, in the recording for this page

Version 2 launched, and then the rose had to be rebuilt. The nacelle drawing was the nice part, and it was also the limit: it showed one moment. We took it out, and the rose now shows every wind angle in the chosen window, as mean deviation per wind sector. The page became much more robust, and more interesting to read.

Version 3 · every angle

Nothing on this page was cancelled, and none of the seventeen pages failed to ship. But this one shipped wrong once, in a way only use could reveal, and was fixed in public. I would rather show that than pretend the first version was the last.

Missing data: leave the gap

When data doesn't arrive, because the connection between a turbine and Farsight dropped somewhere, the chart shows a blank where it should be, and wherever possible the page says why. We don't invent data. No smoothed line across the hole, no interpolated guess drawn in the same colour as the truth.

From two weeks to two or three days

I had designed a lot of pages and the whole design system directly in Figma, so I knew how pages should be built. What Figma kept hiding was everything that isn't the happy path: the error state, the page that fails to load, the user who isn't allowed to see this analysis. Once the design system existed in code, in Storybook, the loop changed:

1. BriefWritten with the concepts I understand, and Claude explains the ones I don't yet.
2. PrototypeClaude builds it in HTML, already on the design system. Close, not perfect.
3. Into FigmaClaude writes the screen into Figma through MCP.
4. Fine passI adjust in Figma by hand: spacing, hierarchy, a button.
5. Back to codeClaude reads the Figma frame and corrects the HTML.
6. Two artefactsHTML and Figma at the same fidelity. Easy to present; the front end is more than halfway built.

Charts were the slowest part of the Figma step, all auto layout and padding. Once Claude was drawing them the way I wanted, on my tokens, I wrote a chart-builder skill so I'd stop repeating the same prompt. It starts by asking what I want before it draws anything:

## Step 0: Always Start by Clarifying

Before writing any code, clarify:
1. What page in the Figma file should the chart land on?
2. What chart type is needed? (bar, line, area,
   histogram, wind rose/polar, etc.)
3. What data should it show?
4. What color represents the data?
5. What title should the chart have?

Forgetting the border is the most common mistake.

A second skill writes the user stories and epics the pages are built from. Together they took a page from one to two weeks to two or three days. Those numbers are my recollection, not a time log, and the first page's weeks were also learning time the later pages didn't need.

What shipped

The fifteen analyses were already on the roadmap. A client asked for them sooner, and I was put in charge of designing all of them, as fast as possible, alongside the Business Intelligence team. Most are wind: Wind Sector Analysis and its revision, Turbulence Intensity, Wake Effect, Wind Curtailment, Yaw Deviation and Dynamic Yaw Deviation, North Azimuth Offset, Nacelle Transfer Function, Pitch Curve Analysis, AA Power Curves, Wind Farm KPI Summary and Active Energy Budget. Shading and Soiling Summaries cover solar. All of them are live, and the client stayed.

The change I can stand behind: clients read these analyses themselves. They no longer need a BaxEnergy engineer to explain what they are looking at. I heard that from the people who sit with them.

The numbers, with their provenance

• 17Pages live: 15 analyses, Wind Analysis, the Analysis Hub. My count.
• ~45 daysTo design the 15 analyses, March–July 2026. My recollection of the push.
• 1–2 wk → 2–3 dPer page, first vs. with the Claude–Figma loop. Recalled, not logged.
• 7Visualizations on Dynamic Yaw Deviation. Counted from the page.
• –Clients read analyses without a BaxEnergy engineer. Heard directly; not measured.
• noneUsage metrics, test results, customer quotes. Not available to me.