Client
Hitachi Energy
Role
Product Designer, lead on Field Planner
Year
2022 - 2023
Focus
Product design, User research, Design systems, iPad apps
Hitachi
How do you move a paper-based wildfire prevention process into three connected apps?
3
connected apps, desktop and iPad
0
paper forms left in the process
1
design system across desktop and iPad
CONTEXT
Hitachi Energy builds tools for companies that maintain power lines. When a plant grows into a line, it can start a wildfire, so the vegetation around every line has to be tracked and cut back in time.
Until this project, that work ran on paper. Findings were written up in the field, sent to a patrol to confirm, then passed to the crews doing the work, and papers got lost along the way.
We replaced it with three connected apps. Vegetation Manager, on desktop, lets office teams run satellite imagery over their lines. An LLM identifies plant species and estimates how long each one has before it becomes a risk. Field Patrol, on iPad, is used by patrols flying over the lines in a helicopter to record infringements. Field Planner, also on iPad, is for the contractors who do the work. They receive a work order from Vegetation Manager with everything the job needs.
CHALLENGE
Field Planner didn't exist yet. The client had ideas and a list of features, but not the process that connected the three apps, from spotting a risk in Vegetation Manager to closing a work order in the field.
Hitachi Energy's ideas were broad, so the hard part was choosing what to build without burying the developers in features. The budget was fixed with no room to move. The client chose satellite imagery while lidar was the popular option, so the apps had to prove useful and stay affordable for potential customers.
There was no design system, and the existing screens weren't built with auto layout. Each app served a different persona, so every flow needed testing and user feedback before it could ship.
Hitachi Energy put me in touch with the people who would actually use the apps. I started each session with a casual chat about their work, then handed them the app and watched. The feature list told me what the apps should do. The sessions showed me how the people using them actually worked, and a lot of my decisions came from what I saw and heard there.
RESEARCH
Four roles, all on paper
A lot of people did this work, split into four roles. I learned how each one worked from Hitachi Energy and in meetings with the users themselves: what slowed them down and where the process could get better. The common thread was paper. Every plan, check and job ran on it.
Office / desktop planner
Vegetation manager
Plans all the work, makes the work orders and keeps every span in check. Technical and at home on a computer, but used to running the whole plan on paper.
On the lines / patrol app
Ranger
Knows the trees. Checks the spans and lines for infringements and can tell when a tree will grow into a line. If there are more findings, the work order is corrected.
Field / Field Planner
Worker team
A crew of workers plus one person who gathers permission before they start. Gets the work order with the ranger's findings, does the job, adds all the costs and sends it back to the vegetation manager.
Field / Q/C app
QC auditor
Checks finished work and documents anything that needs rework.
What we found
What we saw
Plans reached the field late. Paper had to travel from the office to the crews.
What changed
Work orders now land straight in Field Planner.
What we saw
Vegetation managers could not see what was done until the paper came back.
What changed
The planner shows the status of every span and work order.
What we saw
What rangers knew about tree growth lived in their heads and notes.
What changed
The patrol app logs infringements on the map and attaches them to the work order.
What we saw
Workers were not always sure where to start or what to do.
What changed
Each work order opens zoomed to its span, with clear steps and big buttons.
THE WHOLE PROCESS
One work order, four roles
Who touches a work order, and in which app. Pick a role to see only their part, or open the full process for every step and decision.
USER FLOW
From work order to finished job
One work order passes through three roles: the vegetation manager on desktop, the ranger on patrol and the worker in the field, then back to the manager.
KEY DECISIONS
Why it works this way
01
One work order, three apps
The same work order moves from the vegetation manager to the ranger and the worker, and back. Each app shows only what that role needs, so nothing is copied over by hand.
02
Map first, everywhere
Spans and lines are places, so every app starts from the map, not from a table.
03
iPad for the field roles
Big enough for maps and forms, still easy to carry along a line.
04
Big buttons and voice notes
Tagging on patrol has to be quick out on the line, so the common actions are one big tap and notes can be spoken.
APPROACH
Building an atomic design system first
With no system in place and screens that weren't built with auto layout, every new screen meant redrawing components or hunting for them in Figma. Across three apps, that would have slowed every feature down.
So I built an atomic design system before designing new features, and every feature after that was assembled from parts that already existed. The same system covered the desktop and iPad apps, which kept them consistent. That mattered because a single job crosses all three: it starts as a finding in Vegetation Manager and ends as a closed work order in Field Planner.
Organising files for designers and developers
The team changed during the project. I started with two other designers, carried the work alone for a while, and later worked alongside one more. Each change meant someone new had to find their way around three apps' worth of files.
I set up a clear structure so designers and developers could find what they needed without asking around, and so the project never depended on who happened to be on it that month.
Designing to Hitachi Energy's standard
Hitachi Energy has standards its products must meet, so a bare-minimum version was never an option. The fixed budget and tight deadlines pulled toward cutting corners, and the standards pulled the other way.
That tension shaped how I scoped the work: fewer features, each one done properly. The client's input was useful throughout and made me think harder about each decision.
Deciding what goes into the MVP
Deadlines were tight, and taking every feature through the full process wasn't always possible. I decided what belonged in the MVP and what could wait for later releases. With three very different personas, keeping each app simple mattered more than adding features.
The user sessions showed how different those personas were. Office teams using Vegetation Manager were comfortable with digital tools. Field Planner's users spend their day out in the field and needed a much simpler interface to understand how the app works.
So Field Planner got its own, simpler UI instead of reusing what worked for the office teams.
OUTCOME
All three apps shipped, and the process no longer runs on paper. Findings move from Vegetation Manager to the patrols and the crews inside the apps, so they no longer get lost between hands.
Work is easier to delegate, and companies can catch vegetation risks before they turn into wildfires.
INDEX
CONTACT
Send me an email