WindSense
Replacing a legacy desktop tool with a modern monitoring dashboard for wind turbine vibration experts
| PLATFORM | Web Dashboard |
| TEAM | Design Lead (me), 1 UI Designer, Product Manager, Engineering team |
| DOMAIN | Industrial IoT / Energy |
| METHODS | User interviews, stakeholder workshops, domain expert shadowing |
| TOOLS | Figma |
WindSense provides vibration monitoring services for wind turbine operators. Sensors mounted on turbines capture vibration data continuously, and monitoring experts analyze that data to detect early signs of mechanical failure before damage occurs.
The existing tool was a legacy Windows desktop application. Dense, color-heavy, and built without UX involvement. I led the design of a replacement web dashboard that would serve three user roles: monitoring experts who analyze data and flag risks, client maintenance managers who receive and act on those warnings, and monitoring engineers on the client side who track turbine health day to day.
The legacy application worked, but it punished every user who touched it. Three problems compounded each other.
- 01Information overload with no hierarchy
Multiple data modules shared a single screen with no visual priority. Every data point was presented at the same weight. Monitoring experts knew what to look for, but the interface did nothing to help them find it faster.
- 02Unreadable data visualization
Interface used color combinations that made trends difficult to distinguish. The interface relied on dense color-coding across the entire UI, creating readability problems that slowed analysis rather than supporting it.
- 03Manual, disconnected reporting workflow
When an expert identified a risk, they had to leave the application, open Outlook, manually draft an email, and send it to the client. There was no confirmation that the client received or read it, no way to track follow-up, and no connection between the alert and the action taken.
- 01Domain immersion
Ran multiple interview sessions with monitoring experts and the data engineering team to understand the domain. Wind turbine vibration monitoring is a specialist field with its own vocabulary, data types, and decision patterns. Spent time learning what the data meant, how experts read it, and what signals triggered action, before touching any design work.
- 02Legacy audit and role mapping
Audited the existing desktop application screen by screen. Mapped each data module to the user role that needed it and the decision it supported. This revealed that the interface treated all information as equally important because it had never been designed around user tasks, only around available data.
- 03Information architecture
Restructured the product around four core views: asset overview (fleet-level health at a glance), asset details (deep-dive into individual turbine data), issue overview (all flagged risks across clients), and issue creation with assessment workflow. Each view was scoped to the decisions made at that level, not the data available.
- 04Integrated reporting workflow
Designed an in-app issue-to-assessment flow that replaced the manual Outlook process. Experts flag an issue, attach relevant data, and escalate it to an assessment with recommended actions. Client-side users log into the same system to view details and respond, replacing the email chain with a shared, trackable workflow.
- 05Stakeholder alignment
Ran workshops with the product team and monitoring experts throughout. The experts had deep muscle memory with the old tool, so every simplification had to be validated against their real workflows. If removing a data point from a view meant the expert had to navigate elsewhere for a decision they currently made in one glance, that was a regression, not a simplification.
The legacy interface showed everything on one screen because experts said every data point mattered. Simplifying the UI risked hiding information that an expert might need for a specific diagnosis. But the current density was making the tool harder to learn and slower to scan, even for experienced users.
Replicate the data density in a modern UI. Keep all modules visible on one screen with better visual styling. Preserves the expert's current workflow but does not solve the core readability and hierarchy problem.
Reduce each view to only the most common data points and push everything else behind navigation. Cleaner interface, but risks forcing extra clicks for decisions that experts currently make in a single glance.
I structured each view around a single decision level (fleet health, individual asset, specific issue) and surfaced only the data relevant to that level's decisions. Data was not removed from the product, it was relocated to the view where it supported a specific action. I validated each reduction with monitoring experts in workshops: if an expert said they needed a data point at a particular stage of their workflow, it stayed. This was not a simplification exercise, it was a reorganization around how decisions actually flow.
The project was cancelled before launch due to business circumstances outside the product team's control. The design work delivered a complete, validated dashboard structure: four core views (asset overview, asset details, issue overview, issue-to-assessment workflow), an integrated reporting system replacing the manual Outlook process, and restructured data visualization across all views. The information architecture, built through repeated validation with domain experts, reorganized a dense legacy interface into task-oriented views without removing data the experts relied on. The approach of validating every simplification against real expert workflows proved essential in a domain where the designers were not the domain experts, and assumptions about what could be 'simplified' were frequently wrong.
This was the most technically complex domain I have worked in. The gap between what I assumed was unnecessary visual noise and what turned out to be critical diagnostic information was large, and it closed only through repeated conversations with the experts. The biggest lesson: in specialist tools, the users are the domain authority. The designer's job is to reorganize their knowledge into a usable structure, not to decide what knowledge matters.