The Redesign That Doubled Adoption

The portal wasn't broken. Every feature worked. Every integration was solid. From a technical standpoint, the build had been executed well. But nobody had asked the users what their day actually looked like.

The primary users were field assessors. They worked on tablets in environments with unreliable connectivity. The portal had been designed for desktop. Forms that worked fine on a 24-inch monitor were unusable on a 10-inch screen. Navigation that made sense with a mouse was frustrating with a finger. Data entry that required constant server validation failed silently when the connection dropped.

The assessors had adapted. They'd built workarounds using paper forms and a shared email inbox. The workarounds were slower and created data quality issues, but they were reliable. They worked every time, in every environment, without a loading spinner.

We didn't rebuild the system. The backend was solid. The integrations worked. The problem was entirely in the interface and the interaction design.

Before we designed anything, we spent two weeks with the assessors. Not in a meeting room. In the field. In their vehicles. At assessment sites. We watched them try to use the portal on a tablet while holding a clipboard in the rain. We watched them give up after the third failed form submission and pull out a paper form instead.

That fieldwork changed everything we thought we knew about the project.

The constraint was connectivity. Everything else followed from that. We restructured the portal around offline-capable forms. Data synced when connectivity was available but never blocked the user from working. Forms were redesigned for touch input with larger targets and fewer fields per screen. The assessment workflow was broken into steps that matched how assessors actually moved through a site, not how the database expected data to arrive.

The original portal had 47 menu items. We reduced it to 12. Not by removing features, but by reorganising them around tasks rather than system functions. "Submit Assessment" instead of navigating through three menus to find the right form type. "My Queue" instead of a filtered table view with 15 columns.

The assessors didn't need a full-featured enterprise portal. They needed a tool that let them do their job without fighting the interface.

Three months after the redesign launched, portal usage went from 23% to 61%. Six months in, it hit 78%. The assessors weren't being forced to use it. They were choosing to use it because it was faster than the paper workaround.

The client's operations team reported that data quality improved dramatically. Assessments that used to arrive days later via email were now in the system within hours. The reporting that had been unreliable because half the data was missing started working properly for the first time.

The original portal had been built by a capable team. Good developers. Solid architecture. But they'd never watched an assessor try to use the system in the field. The entire build was based on assumptions about how the work happened, and those assumptions were wrong.

This project reinforced something I keep coming back to: the interface isn't a layer on top of the system. For the people using it every day, the interface is the system. If it doesn't work for them, in their environment, with their constraints, it doesn't matter how good the code underneath is.

Good design isn't about making things look nice. It's about understanding the context well enough to make things work. That understanding only comes from being in the room with the people doing the work. Or in this case, in the field.