PDF Printover redUX (2)

(redUX = redesign UX • re-do • ˌriːˈduː)

The tool still worked. That was still the problem.

Part 1 of this case study ended with an honest line: none of the designs made it into the live product. The redesign was presented, praised, and deprioritized — competing priorities, limited dev time, and a read that the pain only touched a small group of power users.

That calculus changed. The work got picked back up, and this time the question isn’t “what should PDF Printover look like” — it’s “does the shipped code actually match what we designed, field by field, pixel by pixel?”

Project overview

Where we picked up

The original design didn’t need rework — it needed a path to production that wouldn’t die the same way twice. The plan: break the whole redesign into ~16 small, independently reviewable branches, each stacked on the last, each tested live before moving on. No single giant PR for a reviewer to drown in; no six-month gap between “approved” and “shipped.”

• Split from one shared integration branch into 16+ standalone PRs — search, pages, field sections, signature cleanup, toolbar restructuring, and more, each with its own small diff instead of one unreviewable wall of changes.
• A recurring branch-dependency trap: a few branches (field search, field sections, page navigation) turned out to depend on earlier work the simple “based on branch X” notes hadn’t captured. Found and fixed by tracing real git history instead of trusting the plan.
• A standing rule emerged from that: every new split chains onto the tip of the latest branch already split out, never an older ancestor — a GitHub PR’s diff is computed against its own base regardless of how deep that base’s own history is, so this costs nothing in review size but means every branch, checked out alone, actually works.
• Locale hygiene audit, a standalone cross-cutting cleanup, after finding several branches had been adding translation keys to the wrong locale file.

Design process (this round)

Figma-fidelity passes, not just build-and-ship

Each finished branch gets checked against its Figma node directly — not “close enough,” but color values, spacing, component reuse pulled straight from the design file. Several real discrepancies only surfaced this way: a dialog header color that needed one setting (not custom CSS) to match exactly; a body background Figma showed but the shared dialog chrome didn’t provide, solved with a small, documented CSS trick instead of a one-off hack.

The Override All Styling dialog

The current branch in progress. Mass-applies font styling to every unlocked Text/Multiline field and resizes every unlocked Checkbox at once — closing a real support ticket (“Overarching Font colour setting for PDF Printover”) that Part 1’s research had already flagged as designable. Built out with the full style-button set (bold, italic, underline, strikethrough, highlight, reset), a live preview, and a warnings-styled notice block adapted from an existing component elsewhere in the app, revised twice against Marinet’s own Figma annotations before it matched.

Bugs implementation found that design review couldn’t

• A checkbox that rendered a single pixel tall in one view and fine in another — traced to a CSS animation corrupting a one-time size measurement, not a styling bug at all.
• A resize handle that visibly grew the field in the wrong direction — traced to the field’s stored anchor point, not the handle’s on-screen position; fixed by moving the handle to match the anchor rather than touching the anchor (which the printed PDF output depends on).
• Translated labels rendering as raw placeholder text (“fontsize” instead of “Font Size”) — traced to a dialog’s translation calls resolving against the wrong locale file entirely.
• Style buttons that looked right in the file list but wrong in the dialog — traced to the dialog rendering outside the component’s own CSS scope, a trap any future dialog built the same way will hit again.

None of these would have shown up in a design review. All of them shipped as fixes within the same day they were found.

The solution (so far)

• Split-panel layout, auto-named and organized fields, locate/sync between canvas and side panel — the structural backbone from Part 1, now running code.
• Field states (default, active, locked) and single-handle resize/move, extended to all five field types.
• Field search, page navigation, and collapsible sections — the organization layer the original flat list never had.
• Override All Styling — in progress, closing the styling-ticket backlog Part 1’s research surfaced.

Outcomes & where this stands

Unlike Part 1, this section isn’t a postmortem — the work is live in progress. What’s true right now: 15 branches built and confirmed working on real QA infrastructure, one more in active development, a locale-hygiene pass done cross-cutting, and a branch-splitting discipline that’s kept every single PR reviewable.

The plan going forward: finish most of the remaining planned branch work, test it with the internal SMEs (power users) and client user testers, make changes or bank them for the next iteration, and then start getting the branches reviewed and rolled out with clients.

The full branch-by-branch plan — status, PRs, test cases, and every decision made along the way — is tracked live here: PDF Printover redUX — Phase 1 plan

What I learned, round two: a Figma file can be pixel-perfect and still be wrong once it’s running — design review and implementation review catch two different kinds of mistakes, and skipping either one just moves the bug further downstream.

(No working prototype is available since it is a live web app.)