04 · Case study

Sizing a wind turbine, before anyone had to guess.

A tool that pulled five departments' knowledge into one place — so a wind farm project could be costed properly before it was accepted.

RoleUX & UI design, user testing ClientSiemens Gamesa EngagementExternal consultant, one of two designers Duration1 year SectorEnergy

The situation

Nobody complained.

Every time a new wind farm project came in, a team had to work out whether it made sense: which turbine, how tall, what foundation, what it would cost, what it would return. The answer decided whether the project was accepted at all.

It was done in Excel. Some of it, anyway — the rest was done in people's heads.

That's the part worth sitting with. A significant portion of the reasoning behind these decisions wasn't written down anywhere. It was expertise, accumulated over years, held by a handful of individuals. It worked, mostly, until someone was on holiday. And it would stop working entirely the day one of them left.

Nobody had raised this as a problem. There was no ticket, no complaint, no line item in a transformation roadmap. There was one engineer who had done it enough times to be sick of it, and who thought it could be better. He brought designers in to answer two questions: what should this look like, and how do you turn a complicated process into a streamlined one.

I came in as an external consultant. He was the reason the project existed at all.

The problem

It was never just a calculation.

There is good software for the wind part — modelling the resource, optimising turbine layout, calculating energy yield. That wasn't the gap.

The gap was everything around it. Before you can size a turbine for a specific site, you need to know:

  • What the land is like, from a field engineer who's been there.
  • Whether the route to the site can physically take a turbine — the roads, the bridges, the corners, the trucks required, the sea freight if it's crossing water. That's a shipping manager's judgement, not an engineer's.
  • What foundation the ground demands.
  • Which turbine models are viable, at what hub height, at what cost.

Five different kinds of expertise, held by five different people, none of whom shared a document. "Make this process more streamlined" actually meant: design a place where those five people can each contribute the part only they know, in the right order, and end up with one answer everyone trusts.

That's a service problem wearing a software problem's clothes.

The challenge

Turning undocumented expertise into a form field.

The core difficulty of this project wasn't visual and it wasn't technical. It was translation.

Each input on the platform represented a piece of specialist reasoning — often reasoning nobody had ever had to articulate, because they'd never needed to explain it to anyone outside their own discipline. Our job was to turn that into something a person from a different department could look at, understand, and answer correctly.

Which meant answering three questions for every single parameter:

What is this, in plain terms? Not the technical definition — the version that makes sense to someone whose expertise lies elsewhere.

Who is qualified to answer it? Getting this wrong doesn't just slow things down. It produces confident numbers from the wrong person, which is worse than no number at all.

When does it need to be known? Some inputs gate others. The sequence had to reflect how the work actually happens, not how the data model was structured.

Alongside that, the comparison problem: the point of the tool is choosing between options, so scenarios had to sit side by side and be legible at a glance. Dense technical data, presented so that a decision could be made from it quickly.

On making it good Tools like this are usually allowed to look like the spreadsheet they replaced — functional is considered enough. We made the case to management that clarity isn't decoration here: when the interface is confusing, people enter the wrong thing, and the output is a cost estimate someone will approve a project on. That argument was heard, and we were given the room to design it properly.

The work

A year, two designers, one platform.

I worked as one of two designers, each of us owning distinct areas of the platform and reviewing each other's work throughout.

  1. 01UX design — the multi-role flow, the input sequencing, the comparison model.
  2. 02UI design — dense technical data made legible, at the level of polish the decision deserved.
  3. 03User testing — with the engineers and specialists who would use it, including a full round before launch.

Some detail is confidential. What's shown here is deliberately partial.

Outcome

Handed over before launch.

My engagement ran to pre-launch. The platform was designed, built and tested with its users, and I completed a final round of user testing before handing over. I wasn't there for the launch itself, so I have no adoption figures or measured impact to report.

That's the shape of consulting work more often than portfolio pages admit. What I can point to is what the testing showed: specialists from different disciplines, working in the same tool, answering the questions that belonged to them.

Reflection

What I'd carry into the next one.

Design so it survives your leaving. As an external consultant you are, by definition, temporary. On a project whose entire premise was that critical knowledge shouldn't depend on one person, that lesson applies to the designer too: document the reasoning, not just the screens.

Some of the translation work is now automatable. A large part of that year went into extracting tacit knowledge from experts and structuring it. Today I'd use an LLM to accelerate that capture, and to give the tool a recommendation layer on top of the calculation — suggesting viable configurations rather than only evaluating the ones a user thinks to try.

The unglamorous input is the interesting one. The wind gets all the software. The bridge on the access road doesn't, and it can kill a project just as easily.