Case Study · 2024

One canvas for the wind & the field.

Aeris is a cloud workspace that unifies configuration management, sector mapping and NDVI intelligence for Apex Renewables — one hosted instance serving teams across Germany and multiple global sites, replacing spreadsheets, tribal knowledge and a tangle of disconnected desktop tools.

↓ Download PDF Read the case study Jump to designs

Role: Lead Product Designer
Timeline: 14 weeks
Team: 2 PM · 3 Eng · 1 Research
Platforms: Web · Tablet
NPI cycle: −38% time
Sources of truth: 7 → 1

Aeris Wind Farm Monitoring dashboard on a curved desktop monitor

This case study covers the end-to-end UX redesign of Aeris — a cloud platform that unifies wind-turbine configuration and precision-agriculture operations in one browser workspace. Multi-tenant, role-scoped and live for every site, it spans research, information architecture, interaction design and a design system that replaced seven disconnected desktop tools and spreadsheets with a single, always-current source of truth.

Problem Statements & How We Overcame Them

Six blockers.
Six breakthroughs.

These were the real obstacles discovered during research — and the design moves that removed them.

Seven disconnected tools with no shared truth

How we overcame it: Collapsed into one canvas where configuration, sector mapping and NDVI intelligence live together — one query, one answer.

Configuration data re-entered across NPI, MLA and wind-farm teams

How we overcame it: A single, auditable source of truth with role-based CRUD so every team writes to the same record without overwriting.

Three versions of the same spreadsheet — no one knew which was current

How we overcame it: Versioning and provenance built in: every value is traceable to PLM, SDM, MLA or human approval with a timestamped trail.

Field intelligence (NDVI, soil, weather) separated from asset data

How we overcame it: Agritech lenses overlaid directly on the configuration canvas — a blade-load change and a crop-stress anomaly can be reasoned about in one viewport.

Tribal knowledge trapped in one engineer's macros

How we overcame it: Loads envelopes, approval rules and notification triggers turned into documented, accessible workflows owned by the system, not a person.

Land owners and engineers lack AI-driven site feasibility analysis

How we overcame it: Unified AI site intelligence that evaluates land topography, wind potential, water tables and environmental constraints in one canvas — turning weeks of manual assessment into minutes of data-driven insight.

AI Site Feasibility Workflow

From a parcel drop
to a bankable report.

A land owner offers a plot. An engineer needs to know if it can carry turbines — safely, profitably, and inside every environmental line. The AI workflow collapses weeks of siloed assessment into minutes of grounded, cited insight.

Inputs — four data domains ingested in parallel, each with provenance.

Pipeline — five deterministic stages, every step auditable.

Output — one feasibility report the developer, financier and regulator can all read.

Inputs

Signal layers

Land

·Cadastral boundary (GeoJSON)
·LiDAR / DEM elevation
·Slope & aspect
·Soil bearing capacity
·Access roads & grid proximity

Wind

·ERA5 reanalysis (10y)
·Mesoscale WRF simulation
·Hub-height wind shear
·Turbulence intensity (TI)
·Extreme gust (IEC class)

Water

·Watershed & drainage basins
·Water table depth
·Flood return period (100y)
·Wetland & riparian buffers
·Runoff coefficient

Environment

·NDVI vegetation index
·Protected species overlays
·Noise receptor distance
·Shadow-flicker envelope
·Airspace & radar clearance

Pipeline

Ingest → Report

01
Ingest
Land owner drops a KML / parcel ID. Engineer connects data sources. Pipeline pulls satellite, ERA5 wind, hydrology and cadastral layers in parallel.
02
Normalize
Rasters resampled to a 30m grid, reprojected to a shared CRS, and gaps filled with kriging. Every value carries a provenance token.
03
Model
AGL wind extrapolation, wake losses, flood inundation, glare and NDVI seasonality models run as a DAG — each cell scored independently.
04
Score
Weighted composite: Wind (35%) · Land (25%) · Water/Flood (20%) · Environment (20%). Sensitivity sliders let the engineer re-weight live.
05
Report
One-click site feasibility PDF: AEP forecast, LCOE band, buildable-area polygon, risk register, permit checklist, and comparable-site references.

Feasibility Report

One artifact · all stakeholders

AEP

142 GWh / yr

Annual energy production, P50

Capacity Factor

38.4%

Class II wind regime

Buildable Area

68% of parcel

After setbacks & exclusions

Flood Risk

Low

100y return outside pad zones

LCOE Band

€42–48 / MWh

Merchant + PPA blend

Permit Confidence

High

No protected-species conflicts

Every figure links back to the source layer, model version, and confidence band — so a reviewer can trace an AEP number down to the exact wind cell and reanalysis timestamp behind it.

01 — Overview

One cloud source of truth for teams that design the same thing in different languages.

Aeris began as a desktop configuration tool for NPI engineers and was rebuilt as a cloud operations workspace covering sector mapping, health scoring and component-level approvals — one hosted instance, role-scoped, reachable from an office, a site office or a turbine platform without a single file being emailed.

Voice of the customer: “If we're all designing the same wind turbine, why do we all speak different languages?”

01b — Where the cloud does the work

Cloud-native by design

Six places the cloud changed the design.

Moving from seven desktop tools to one hosted workspace wasn't a hosting decision — it changed what each screen could promise. These are the points where the cloud model is visible in the product.

Field & satellite feeds

streamed

Hosted pipeline & models

normalised · scored

Single source of truth

versioned · auditable

Every role, live

web · tablet

Hosted ingestion

Site data lands in the cloud, not on a laptop

Wind, soil, water and satellite feeds stream into one hosted pipeline. No nightly exports, no local copies drifting apart.

Multi-tenant

One instance, many operators and sites

Every turbine park and farm sector is scoped to its own tenant, so shared components stay global while data stays isolated.

Live truth

Configuration revisions sync in real time

A blade-load change made in Germany is visible to the crew on site seconds later, with explicit last-synced and connection states.

Role-scoped access

Cloud CRUD matrix instead of file permissions

Roles — not people, not folders — own the truth. Certification fields are writable by certification engineers only.

Elastic compute

Feasibility analysis runs server-side

Terrain, wind-yield and NDVI models run on hosted compute, so a full site study finishes in a browser tab rather than an overnight desktop job.

Browser-native

Office, site office or turbine base

Nothing to install. The same URL, the same record, the same vocabulary — on desktop in the office and tablet in the field.

02 — The Problem

Seven local tools. Zero agreement.

Configuration lived in PRD matrices, LC databases, FlexModel parameter files and WT_conf_master spreadsheets — all on individual machines and shared drives. Engineers re-keyed the same data across hand-offs, and no one could agree on the latest blade load envelope.

Manual rework

Component data re-entered across NPI, MLA and wind-farm teams.

No version truth

Three answers to one question depending on whose local file you opened.

Slow time-to-market

Configuration changes took weeks to reach simulation owners.

Field teams cut off

Site crews had no access to the tools at all — only printouts and phone calls.

“I'm an RCA engineer — what's the original blade load envelope? The latest controller updates for this config? No idea. Wtconfmaster#??? I only speak in PRD#!!!”

— Engineer interview, discovery phase

03 — Discovery

We mapped the chaos before we touched a pixel.

14 stakeholder interviews across NPI, MLA, certification, PLM and wind-farm engineering. Two AS-IS journey maps, one TO-BE journey, a persona–data–process matrix and a pain-point catalogue per role.

14Stakeholder interviews across 6 disciplines
7Disconnected systems audited end-to-end
32Pain points mapped by persona × dataset
1Unified TO-BE journey signed off by all teams

04 — Decision Frame

How the call was made.

Four questions framed every design move — how the problem was defined, why this shape over the alternatives, what was traded away, and why the result doesn’t look like anything else in the category.

How I defined the problem

Not ‘too many tools’ — no shared source of truth

Stakeholders described the pain as ‘seven systems.’ Discovery reframed it: the real problem was that no two local systems agreed on the current configuration. I rewrote the brief from ‘consolidate tools’ to ‘establish one cloud-hosted, auditable source of truth that every persona can write to within their access.’ That reframe unlocked the entire IA.

Why this solution over alternatives

One cloud canvas, not a portal of portals

We weighed three options: (a) an integration layer that left the seven desktop UIs intact, (b) a dashboard-only ‘viewer’ over the existing tools, (c) a single cloud canvas that owned configuration and surfaced field intelligence side-by-side. We chose (c) because the engineer’s real job is a decision, not a lookup — and only one hosted canvas let configuration changes and field outcomes inform each other in real time, for every site at once.

The trade-offs I made

Cloud-only v1, narrower roles, opinionated schema

Owning the schema meant three legacy reports had to be rewritten and four teams gave up bespoke spreadsheets. The CRUD matrix is intentionally narrow — Loads Engineers cannot edit certification fields, even though the old Excel let them. And v1 shipped online-only: syncing a configuration source of truth offline would have undermined the very trust the cloud model was there to build, so instead we designed explicit connection and last-synced states.

How it’s different from other tools

Configuration and field intelligence in one browser tab

PLM tools (AssetVault, TeamVault) own configuration but ignore the field. Precision-ag tools (FieldSense, CropMind) own the field but ignore the asset. Aeris is the only hosted surface where a blade-load envelope change and an NDVI anomaly can be reasoned about in the same workspace, by an engineer in Germany and a crew on site — because for this operator, they are the same decision.

04 — Design Principles

Four principles guided every screen.

One canvas, many lenses

Configuration, sectors and loads share the same surface — never a separate tool.

Status before detail

Every card answers: is this healthy, who owns it, what changed?

Decisions need provenance

Every value is traceable to its source — PLM, SDM, MLA or human approval.

Quiet by default

Alerts only when an action is required. No dashboards-as-noise.

05 — Information Architecture

The IA mirrors how engineers actually work.

A login lands in a configuration dashboard; from there, every path (Details, Plant, Task, Device, Activity) maps to a microservice and an owner. Notifications follow the work, not the role.

1Login → Intermediate screen
2Intermediate → Dashboard · Pre-config list
3Dashboard → Configuration details
4Configuration → Component revision
5Component → Approval & notification

06 — Personas

Six personas. One shared vocabulary.

Each role writes to the same record — but only within the scope of their access. Roles, not people, own the truth.

Configuration Owner

Create · Update · Approve

Owns the source of truth for a config revision.

NPI Engineer

View · Compose

Builds new configs from certified components.

MLA Engineer

Create · Update

Runs loads simulations against a config revision.

Certification Team

View · Sign-off

Validates loads envelope and operability.

PBM Owner

View · Feedback

Validates loads against physical components.

PLM

Sync · Notify

Pushes BOM changes upstream into simulations.

07 — The TO-BE Journey

From spreadsheets to a single thread.

01
Define
Configuration Owner spins up a revision; PLM data flows in.
02
Compose
NPI selects components; constraints validate live.
03
Simulate
MLA runs loads against the revision in SDM.
04
Approve
Certification signs off; envelope locks.
05
Hand-off
PBM owners validate loads against physical components.

08 — The Designs

Five screens, one calm system.

Each surface is a window onto the same underlying data — sectors, plants, devices, loads — viewed through the lens that matters now.

Sector Details — full canvas

A split view pairs structured sector data with a live aerial scene. The Section 3 popover surfaces health, soil, humidity and a 7-day trend without leaving the map.

Sector Details — content-fit framing

The same canvas tuned for embedded contexts: chrome shrinks, content stays. One layout, two densities — proof the system scales without redrawing.

NDVI Indicator overlay

A precision-agriculture lens on top of the configuration canvas. NDVI zones (healthy · moderate · stressed) read at a glance; the legend is the explanation.

Sector Map Area — list & timeline

Every map area is a card with location, land area and coordinates. A date strip and metrics chart anchor the temporal view — soil moisture, precip, humidity, growth.

New Sector Map Area

A focused dialog with progressive disclosure: name first, then boundary file, then coordinates. The Create button stays disabled until the area is geometrically valid.

09 — Design System

An earthy, instrument-grade palette.

Greens grounded in soil and leaf, accented by warning amber and a quiet sky blue. Fraunces sets the editorial tone; Inter carries the data; JetBrains Mono for coordinates and IDs.

Leaf

Primary

Soil

Sky

Accent

Foreground

Muted

Background

Fraunces

Display · editorial headings

Inter

UI · body · data labels

JetBrains Mono

Coordinates · IDs · code

Process Artifacts

The thinking behind the screens

Architecture maps, journey flows, the product roadmap, and the persona-access matrix that shaped Aeris before pixels were pushed.

Enterprise Architecture
Mapping every system that touched a turbine
Before a single screen was drawn, we mapped the full Apex Cloud ecosystem — Configurator, WindHub, Studio Canvas, FlexModel, LeaseCalc, FlowMap — and the data exchanges between them. This artifact gave the team a shared vocabulary and made the integration seams (PLM, CRM Core, Wind Data Engine) impossible to ignore.

Journey Map
End-to-end configuration flow across six personas
From the PLL Team's request for a new config, through Loads Engineer, PBM Owner, Operability Engineer, and on to Certification — with the drilled-down tooling (FLEX 5, SDM, Matrix Creator, Envelope tools) called out at each step. Access policy and notification triggers are surfaced as cross-cutting concerns.

Product Roadmap & Data Model
Tenets, schemas, and the Persona–Data–Process matrix
The proposed architecture tenets (seamless UX, microservices, scaling existing component DB) sit alongside the turbine configuration DB, components subsystem, and a 15-step Process × Persona × Action matrix that became the backbone of every subsequent sprint.

Persona Access & Pain Points
Who can do what — and where it hurts today
A CRUD access matrix across PLL Team, Loads Engineer, PBM Owner, Controls, Operability, System Integration, Certification, Performance, and MLA engineers — paired with a Data / Actions / Pain-points table that captured the manual entry, version control gaps, and coordination overhead the new system had to eliminate.

Screens · Problem & Solution

Five screens, five decisions

For each core screen — what we observed in research, and the design move that resolved it.

01
Greenhouse Monitoring Dashboard
The Problem
Farm managers jumped between 4–5 tools to see weather, sensors, camera feeds and daily tasks. Critical signals — a humidity sensor going offline, a watering window closing — were buried in separate dashboards, so problems were caught late.
How We Solved It
Collapsed the operational picture into one screen organised by mental model, not data source: field context on the left, device health in the middle, live camera and today's tasks on the right. A single Plant Health score acts as the at-a-glance verdict, and inline 'Signal issue since 08:02 AM' badges surface faults where they're relevant.
02
Alerts Summary
The Problem
The legacy system fired every alert with the same red urgency — a low battery looked identical to three sick plants. Managers learned to ignore the bell, and real issues slipped through.
How We Solved It
Alerts grouped by domain (Plant Health, Environmental, Soil, System) and triaged into three columns — Optimal, Fair, Error. Each card carries a status chip and a recommended Action, so severity and next step read in the same glance.
03
NDVI Map — Field Health
The Problem
Agronomists received raw NDVI exports as CSV or PDF. Interpreting them meant matching coordinates to plots by hand, and stressed zones were often identified days after the damage was done.
How We Solved It
Rendered NDVI directly on the satellite view with a three-band legend (Healthy / Moderate / Stressed) and per-area overlays. Selecting a zone reveals coordinates, size and average index in a side panel — a 2-second read instead of a spreadsheet exercise.
04
Soil Moisture Trend
The Problem
Irrigation decisions were made on a single current reading. Without context, teams over-watered on cool days and under-watered after heatwaves — both hurt yield.
How We Solved It
A 7-day band chart plots moisture against the optimal range and precipitation, with a gauge for the current reading. Four supporting tiles make the recommendation defensible: irrigate, hold, or reduce — with the evidence visible.
05
Water Usage Analytics
The Problem
Water was the largest operating cost, but usage data lived in the irrigation controller and cost data lived in finance. No one could answer 'which zone is leaking' without a half-day investigation.
How We Solved It
Consumption, efficiency score, per-plant average and irrigation duration sit above a per-day distribution chart. An Anomaly Detection card flags deviations and the Water Usage Report lists offending zones with a one-line cause.

10 — Outcomes

Less rework. Faster decisions. One vocabulary.

−38%

NPI configuration cycle time

7 → 1

Tools collapsed into one canvas

+42%

Cross-team approval velocity

Spreadsheet-of-truth dependencies

10b — My role, decisions & impact

What I owned, what I traded away, what it moved.

My role

Lead Product Designer — sole designer across 14 weeks, embedded with 2 PMs, 3 engineers and 1 researcher.
Owned discovery: 11 stakeholder interviews, artefact audit of seven tools, persona–data–process matrix.
Owned IA, interaction design, the CRUD/permission model and the design system handover.
Ran weekly design critique with engineering and paired directly on the cloud data model.

Decisions I made

Reframed the brief from ‘consolidate seven tools’ to ‘establish one hosted source of truth’.
Chose a single cloud canvas over an integration layer or a read-only dashboard.
Made roles — not people — the owners of each field, encoded in an explicit CRUD matrix.
Kept configuration and field intelligence on the same surface instead of splitting products.

Constraints I designed within

Cloud-only v1 — no offline write path, so connection and last-synced states had to be explicit.
Legacy PLM and CRM systems stayed the upstream record for components and customers.
Certification data is regulated: narrower edit rights than the spreadsheets teams were used to.
Site connectivity is unreliable, so every long-running analysis had to be resumable.

What shipped

Hosted configuration workspace with revision history and role-scoped CRUD.
Sector mapping and NDVI intelligence in the same workspace as the asset record.
AI-assisted site feasibility flow: land, wind and water inputs → one feasibility report.
Design system: tokens, 40+ components, state and edge-case catalogue, handover kit.

−38%

NPI configuration cycle time

7 → 1

Tools collapsed into one hosted canvas

+42%

Cross-team approval velocity

Spreadsheet-of-truth dependencies left

Measured across the 12-week pilot against the pre-launch baseline.

11 — Reflection

What I'd do differently.

The hardest part wasn't the UI — it was getting six disciplines to commit to one vocabulary. Next time, I'd run the persona–data–process workshop in week one, not week six.

Bringing the NDVI layer into the same canvas late in the project paid off; it proved the system could absorb adjacent products without breaking. That argument unlocked the next funding round.