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.
The problem I was handed, and the one I found
The ticket
Bring the mobile report pages closer to the web version, which had been redesigned in early 2025. Mobile had fallen behind on interface, experience, and accessibility, mobile usage was climbing, and the business wanted to push mobile harder. In effect, the ask was: make mobile look like web.
The real problem
Matching web would have ported a desktop experience onto a phone. The real problem was how to make the best mobile reporting experience: borrow enough from web that it stays familiar and continuous, and use the things a phone is actually good at. That reframing is where the rest of the work came from.
Validating the reframe
The reframe wasn't asserted on taste. It went into research as a set of open questions about what the header needs to show, whether progress matters, and how people actually move through a report, so the direction could be confirmed or corrected before any screens were committed to.
Research
Before committing to any design there was a set of questions the work needed answered. What does the header need to show for full context before a page is started? Do users want a sense of progress while filling one? Is it clear which page, and which stage, they are on? Do they need the current task, its assignee and due date? How hard is it to tell a field has a comment or action attached, and to reach it? And once a page is submitted, do they know what happens next? Research ran in three passes, each method chosen for what it could actually answer.
Interviews, two client health and safety teams
Interviews were the right tool here because the work was testing assumptions, and assumptions need open conversation rather than a form. This round covered the whole mobile app, not just report pages, and it is what surfaced report pages as the urgent priority. Those two conversations set the roadmap as well as the design.
Questionnaire, a wider set of clients
By this point depth from a few people wasn't what was missing, importance rankings across many were. A questionnaire went out asking clients to rate how much things mattered: page and stage titles while working, a progress indicator, detail on the current task, and how often they used the AI summary, segmented by system knowledge and user type.
Prototype questionnaire
Once there were proposed designs, a third round put prototypes in front of users to check whether the actual interactions made sense. Feedback was mostly positive, the old designs were poor enough that the new ones surprised people, and it produced one clear, 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
After
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.
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
New
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.
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.
Results and business impact
Accessibility went from failing to passing
This is the part measurable directly from the work. The old tap targets failed the WCAG target size guidance; every field now clears it. Text and control contrast that was missing the AA thresholds now meets them. These were checked against the guidelines during design rather than through a formal external audit, but they are real, verifiable numbers rather than estimates.
A hidden feature became a visible one
Half of users did not know they could add comments and actions on a field at all. Turning every field into its own framed, tappable surface, with comment and action states visible on the field itself, converts a capability people were not finding into one they can actually see.
What I can't claim, and what I'd instrument
I left ecoPortal shortly after launch, so I don't have long-run adoption numbers and won't invent any. If I owned this today the first thing I'd instrument is the gap between web and mobile: completion rate and time to complete a report on each, tracked across the months after launch, plus how many field workers discover comments and actions now that they're no longer buried.