The redesign that almost did not happen — and why it did anyway
A product team convinced themselves they needed new features. A single user interview changed the direction entirely. What followed was a redesign nobody had planned for.
The original brief
The client came to us with a clear scope: add three new features to their project management tool. Bulk actions, a calendar view, and an export function. They had already scoped the work, written the specs, and pushed back a launch date twice. They just needed someone to build it.
Before starting any design work, we asked for one thing: three user interviews. Not to slow things down. Just to make sure the features would land. The client agreed, probably expecting confirmation that the spec was correct.
The most dangerous brief is one that has already decided on the solution. It leaves no room for the problem.
The interview that changed it
The first two interviews were fine. Users confirmed they wanted the features. They also mentioned — almost in passing, as if it were obvious — that they found the main navigation confusing and spent the first few minutes of every session reorienting themselves.
The third interview was different. A power user who had been on the platform for two years opened a screen share and showed us how she worked. She had built an elaborate system of browser bookmarks to jump to the parts of the app she actually used — because the navigation made it faster to bypass the app entirely than to use it as designed. She was not complaining. She had adapted.
We took this back to the client. The conversation was uncomfortable. We were not telling them their features were bad — we were telling them there was a bigger problem that would make the features irrelevant if they shipped first. To their credit, they listened.
What we actually built
We redesigned the information architecture first — a full restructure of the navigation, a consolidated sidebar, and a new top-level view that surfaced the content users cared about without requiring three clicks to find it. Then we built the features into the new structure.
Documented patterns from three user interviews. Mapped current navigation against actual usage paths. Identified six orphaned sections nobody visited.
Collapsed seven top-level navigation items to four. Merged three redundant views into one. Tested new structure with two of the original interview participants.
Bulk actions, calendar view, and export — now built into the new structure. The calendar view took half the time because the new IA gave it a logical home.
Beta with 12 existing users. The power user from interview three tried it without prompting. She deleted her bookmark folder after the first session.
The result
Session depth — the average number of core actions taken per login — increased 38% in the first month after launch. Support tickets related to "can not find" queries dropped by over half. The three original features were used. But more importantly, they were used without confusion, because the thing around them finally made sense.
The client now opens every new project with a research phase. Not because we insisted. Because they saw what happens when you do.
Features do not fail because they are built badly. They fail because they are built into a structure that was already broken.