Consumers Energy – UX for Internal Utility Planning App
Redesigned a GIS-based planning tool for Consumers Energy to improve usability, reduce training time, and streamline operations across forestry and field teams.
Project Details
Tags
Challenge
Consumers Energy plans service work across a service territory measured in counties. The planning itself ran on spreadsheets, specialist GIS tooling, and a quantity of knowledge that lived in the heads of a handful of senior planners.
That arrangement works until you need to hire. A new planner could not be productive without months of shadowing, because the tools assumed you already knew which layer mattered, what the fields meant, and which of several plausible-looking columns was the one people actually used. The bottleneck was not the software's capability. It was that capability was only reachable through expertise.
There were two user groups, and they did not think alike. Operations and Forestry planned different work, on different horizons, with different vocabulary for the same map. Any design that optimised for one would quietly tax the other.
Solution
I led the research and design. The work divided cleanly into finding out what people actually meant, and then rebuilding the interface around that rather than around the data model.
- Interviews across both groups and both experience levels. Senior planners and recent hires, Operations and Forestry — deliberately, because the gap between what an expert does and what a newcomer can find is the entire problem statement.
- Card sorting to settle the vocabulary. The labelling was the substance, not a polish pass. When two teams use one word for two things, no amount of layout fixes the confusion underneath.
- Personas built on technical depth, not demographics. The variable that predicted whether someone could complete a task was how much GIS knowledge they brought, so that is what the personas were organised around.
- Prototypes tested iteratively in Figma. Low fidelity through high, with clickable prototypes put in front of internal users rather than described to them in a review meeting.
- Design intent carried into implementation. I worked directly with the developers through sprint grooming and standups, which is the only reliable way the thing that ships resembles the thing that tested well.
What shipped was a map-based dashboard where a planner filters, routes, and updates field work along a visible path, with context-aware tooltips and forms that simplify themselves according to the job type being planned.
Decisions Worth Defending
- Guided, not simplified. The temptation with an expert tool is to hide the hard parts. That trades a newcomer problem for an expert problem. The guided path is a route through the same capability, not a reduced version of it — senior planners keep everything they had.
- Labels were treated as a research finding. Card sorting with both teams, before any layout work. Naming is the part of an enterprise interface that you cannot design your way out of later.
- Forms adapt to job type. Showing every field for every kind of work is what made the original feel like it required training. Conditioning the form on the job being planned removes the guesswork about which fields matter this time.
- The spreadsheet dependency was the metric. Not satisfaction scores — whether a lower-level planner could complete work that previously required a specialist. That is the outcome the business was actually buying.
Outcome
The redesign tested well with both experienced operators and less technical staff, and the reception from Forestry and Operations stakeholders was positive.
- Reduced training time before a new planner was productive
- Planning work that had required specialist staff became reachable by lower-level planners
- Faster, more accurate field planning decisions reported by users
- Design intent preserved through implementation via direct work with the development team in Agile
The durable lesson was that the barrier in enterprise software is rarely capability. It is that capability is reachable only by people who already know where it is. Most of the value here came from naming things the way users named them and making the sequence visible — neither of which shows up in a feature list.