03 · Application Design
Designing the Shell:
UX Architecture for a
Desktop Publication Tool
An internal publication tool built in the 1980s had reached its limit. Designers created layouts in InDesign; production staff manually recreated them by hand. I led the architecture decisions that would finally bridge that gap — for 1,000+ languages.
The Problem
A 40-year gap between design and production
The internal publication tool at the center of this project was built in the 1980s. Its information architecture had been stretched and patched for decades — locked in an era before modern design workflows existed. The organization had reached the limit of what it could ask the tool to do.
The actual workflow looked like this: designers created publication layouts in InDesign, then handed them off to production staff, who manually recreated every layout inside the internal tool — applying custom settings to print correctly across 1,000+ languages and dialects. Every design change meant another full manual reproduction cycle.
The goal was to build a modern, web-based replacement. More than that, it was to eliminate the duplication of work happening between design and production — a gap that had existed for decades.
My scope: I designed the overall application shell, the canvas model, the panel architecture, and the spatial anchor system. Two other UX designers built out the component details and UI within that framework. The case study covers the system — not every screen.
A cross-functional team. High architectural stakes. The biggest risk wasn’t getting the components wrong — it was making an early decision that would permanently limit what the product could become.
Canvas Architecture
The decision that locked in flexibility
Before any panel was designed or component was built, the team had to answer one question: what kind of canvas does this tool live on?
Two options were on the table. The divided pasteboard model splits the canvas into two fixed halves — one zone per page spread. It’s how InDesign does it, and it’s a known, legible pattern. The infinite pasteboard model gives users a single, unbounded canvas where documents and elements can be placed freely.
The divided model would have been the safer, faster choice. It mirrors InDesign closely, reducing migration friction. But it would have permanently closed off one category of use case: interactive and non-print documents. Any content that needed to exist outside a fixed page spread — interactive elements, embedded media, multi-orientation layouts — would require a fundamentally different product architecture to support later.
I proposed the infinite pasteboard. The key argument wasn’t that we needed interactive use cases now — it was that we shouldn’t make a 2–3 year decision that permanently ruled them out. An infinite canvas can be constrained to behave like a divided one. The inverse is not true.
An infinite canvas can be made to feel like a divided one. A divided canvas can never become infinite without a rewrite.
The divided model mirrors InDesign — but permanently closes off interactive use cases
Panel System & Spatial Anchors
Four states, full workspace control
A publication tool lives or dies by how much it gets out of the user’s way. The panel architecture had to work for a 24″ desktop and a small laptop in the same session.
Four panel states — drag the handle to undock; click the rail to collapse. Each state is independently persistent.
Staying oriented on an infinite canvas
An infinite pasteboard introduces a real usability challenge: users can lose their place. A canvas with no boundaries needs anchors — reference points that let users understand where they are relative to their document at any zoom level.
The spatial anchor system has three components working together. Rulers show metric position along both axes, updating as the user scrolls or zooms. The origin indicator at the ruler intersection marks the document’s zero point — a fixed reference even when the document itself is scrolled far off-screen. The page panel shows a miniature overview of all pages, grouped into sections, with the current viewport highlighted — so users always know where they are in the full document structure.
Rulers + origin indicator + page panel — three systems that keep users grounded on an unbounded canvas
Print production clarity at a glance
Desktop publishing has a vocabulary. Designers working in print need to see all four production zones simultaneously: where content must live, where backgrounds should extend, and what the printer needs to grip. The guide system uses color to make all four visible without competing for attention.
Margins (blue) · Safe Zone (green) · Bleed (pink) · Slug (yellow) — four nested zones, all visible at once
Impact
A system, not a collection of screens
What this work actually is
The publication tool is designed to eliminate manual, per-branch document recreation across 1,000+ languages and dialects. That’s the scope. The architecture decisions documented here are what make that scale possible without locking the product into a path it can’t evolve from.
My contribution was the shell: the canvas model, the panel architecture, the spatial anchor system, the design system, layer behavior, text pouring behavior, and more. Two other designers built the component detail and UI within that framework. The work I did is what makes every screen coherent.
The process followed the double diamond: discovery (understanding InDesign migration patterns, scale constraints, and technical boundaries), definition (architectural options and tradeoffs), development (panel states, anchor system, guide system), and delivery (the shell handed off for component build-out).
The right architecture decision isn’t the one that’s easiest to explain now. It’s the one that’s still right in three years.
What I’d do differently
The canvas decision was right, but the argument for it took too long to land. I leaned on the technical case (interactive use cases, future flexibility) when the stronger argument was the simpler one: an infinite canvas can be constrained to behave like a divided one. The reverse isn’t true. That sentence would have saved two meetings.
I’d also have pushed harder for a shared decision log early in the project. When three designers are working on different layers of the same product, the assumptions that each person is carrying are invisible until they collide. A written record of what was decided and why would have surfaced those collisions earlier.
Case study 01
AI-Assisted Design Documentation Platform →