Qinaps

THE REAL CHALLENGE

Real improvement, without touching the foundations

The product worked, but it didn't feel like one coherent tool. Spacing and colours were inconsistent from page to page, the same kind of element was shown two different ways, and several important actions were buried in right-click menus or only appeared on hover. Users couldn't always tell which view they were in.

I couldn't fix any of that by restructuring it. So the whole challenge was leverage: finding the small, front-end-only changes that would add up to a product that feels consistent and legible, and making sure every change I recommended was actually worth building.

Key decisions

Audit the whole journey before changing anything

I went through the product end to end as a user, then built an experience map across its four main phases: initialising a document, managing sub-sets, managing requirements, and collaborating. For each phase I laid out the user's goals, their actions, the emotional highs and lows, what already worked, and where it broke. That turned a vague "make it better" into a concrete, ordered map of exactly where the experience was failing and why.

Separate the two kinds of problem, and prioritise each

Not all the issues were the same shape. Some were ergonomic and structural: hidden actions, no way to tell which view you were in, awkward navigation. Others were visual: inconsistent spacing, an incoherent set of icons, colours that weren't systematised, two different modal styles. I split the recommendations into UX/ergonomics and UI, and prioritised within each, so the client could see the difference between "this confuses people" and "this looks unfinished."

Weigh every recommendation with the developer

This was the decision the constraint forced, and the one I'm most happy with. A list of improvements is useless if half of them are too expensive to build. So I ran a working session with the developer and weighed each recommendation on three things: how important it was to users, its priority, and how much it would cost to implement on the front end. That session is what turned a wishlist into a realistic, ranked plan that respected the no-structural-change rule.

Spend the budget on high-leverage, low-cost wins

With the plan agreed, I focused the changes where small effort bought real clarity. The main ones:

• Surfacing hidden actions. Important actions were only reachable on right-click or hover. I brought them into a visible toolbar per view so people could actually find them.
• Knowing where you are. I added a way to switch views clearly, a page title for the current view, and a breadcrumb for the workbook and viewpoint, so users stopped getting lost.
• Fixing the modals. There were two inconsistent modal styles. I unified them, corrected the confirm and cancel button order, and gave each one a title and proper spacing.
• A consistency pass. Systematised spacing across pages, a coherent SVG icon set chosen to match the subject, and rationalised primary, secondary, and utility colours.

None of these touched the architecture. Together they make the product feel like one tool instead of several.

What I'd do differently

I'd loop the developer in earlier, while still mapping the journey, instead of after drafting the full recommendation list, so cost constraints shaped the audit from the start.