ecoPortal is a configurable enterprise software company that provides a centralized platform to support workplace health, safety, and environmental risk management.
ecoPortal is a configurable enterprise software company that provides a centralized platform to support workplace health, safety, and environmental risk management.
Report Pages Redesign
A redesign of ecoPortal's main reporting feature on mobile, reframed from "make mobile look like web" into building the best mobile reporting experience. Shipped in January after roughly three months of design and development.
Company
ecoPortal
My role
Product designer
Tools
Figma, Maze and Claude Code
Context and process
Report pages are the core of ecoPortal's mobile app. They are where frontline health and safety workers log incidents, hazards, and audits in real time from the field, and they are the record their managers review to decide what safety action to take. If reporting is slow or confusing on mobile, the whole safety loop slows down. The project shipped in January after about three months of design and development, owned end to end.
Research
Interviews, two client health and safety teams
Assumptions need open conversation, not a form. This round covered the whole mobile app and surfaced report pages as the urgent priority, setting the roadmap as well as the design.
Questionnaire, a wider set of clients
Depth from a few people wasn't what was missing, importance rankings across many were. Clients rated what mattered most, segmented by system knowledge and user type.
Prototype questionnaire
Once there were designs, a third round checked whether the interactions made sense. Mostly positive, and it produced one specific ask that changed the work.
What the research told
Two audiences, not one
Managers know the system considerably better than field workers do, so the same screen is being read by two very different levels of familiarity.
Field workers want out fast
The dominant field behaviour is to report something and close the app as quickly as possible. Anything that adds a step is a tax on the person with the least time.
A feature half of users couldn't find
Half of users did not know they could add comments and actions to a field at all. The capability existed, the affordance did not.
The AI features were buried
The existing AI features were effectively hidden in the interface and needed real promotion to be discovered, let alone used.
Page titles stop earning their space
The page title matters on arrival, then stops being important the moment someone is working inside the page. It was holding prime screen space for no ongoing benefit.
Stage and current task do matter
Always knowing which stage you are on mattered consistently, and so did a clearer view of the current task. Existing error validation navigation was already landing as a genuine win.
Research changed the design
Three places where a finding, not a preference, decided what shipped
A header that changes with the context
Finding
Research showed the page title stops being important once someone is filling the page, while always knowing the current stage does matter.
Change
The title is cut on scroll, giving the space back to the fields and a progress indicator, so the header keeps working while the page is being filled.
"Submitted" was not enough
Before
Finding
In the prototype round, users asked the post-submit screen to tell them what actually happens next, rather than confirming the submission and stopping there.
After
Change
It was rebuilt to show the next stage, the assignee, and the due date, so finishing a page hands you the state of the work instead of a dead end.
Making every field reliably tappable
Old
Finding
Half of users did not know they could add comments and actions. The tap target was the label text, too small to meet the WCAG target size guidance, and people missed it or missed that fields were interactive at all.
New
Change
Every field now sits in its own frame, and the top of that frame is the tap target. It clears the size guideline, and as a side effect it makes the divisions between fields far clearer.
Design question
How might we make safety report creation feel as natural on mobile as it does at a desk, while respecting the field worker's context?
Before and after
What changed and why
Highlighting the main design changes and reasons why
Context without cost
The header was redesigned to show progress and stage context clearly, then collapse into a slim persistent bar on scroll, keeping critical context visible without eating screen real estate while filling fields.
Distinct inputs for distinct interactions
Text, date, selection, and multi-value fields were given differentiated visual treatments so the affordance, what to do, is clear before a user taps anything.
Responsive, not just scaled
Rather than stretching the mobile layout to fit tablet screens, a distinct two-column arrangement and sticky-condensed header behavior were designed for the wider canvas.
What I owned after launch
The work continued past the ship date, not just up to it.
Design QA on every build
I went through what the developers had implemented on each build and flagged where it drifted from the design, on spacing, states, and behavior.
Continued field and tablet iteration
I kept designing field improvements, starting with the ones simplified for the MVP, and kept iterating the tablet layouts, which still had room in them.
Tested against real client data
I worked directly with the QA engineer to check designs against real client data scenarios rather than tidy test data, because report pages break in interesting ways when a real client's messy configuration hits them. Bug-fix cases were designed as they came up.