Table Editing System
Enterprise SaaS · Confidential, visuals abstracted · 2025
From inherited controls to predictable behaviour.
Inherited icon toolbar. Scope is invisible until you click, and rows split at the page boundary.
Scoped, labelled controls. Each names the unit it affects, and structure inserts at the true boundary.
Tables were breaking at the point of final production.
Professional teams use the editor to produce complex, presentation-ready documents. Their tables need to hold together across pages and columns, not just look correct in a simple example.
Teams had started working around the product: moving final formatting into other tools or avoiding complex tables in the editor altogether. The content was supported. The production workflow was not.
The bugs shared one cause: the table model was incomplete.
Tables overflowed at page and column boundaries, lost structure after common editing actions, and sometimes misaligned after resizing. Each issue looked separate. Underneath, the product had no consistent rule for how tables should behave across editing paths.
The control menu had the same problem. It inherited icon-based controls with limited labelling and grouping, so users could not tell the scope of an action until after clicking.
The inherited controls used unlabelled icons with limited grouping. The redesign introduced labelled groups that make action scope clearer before the user commits.
The redesigned control system shown in product. Surrounding chrome is reconstructed and neutralised; the focus is the scoped menu and the boundary-insert affordance. The icon-only default it replaced is shown in Fig. 1.
I worked from behaviour rules, not a list of bugs.
Over three months, I defined table behaviour across the main editing paths and redesigned the control menu with a cross-functional product team. Fixing the visible defects one by one would have created new inconsistencies elsewhere. The team needed a shared model first.
Three decisions set the direction.
Use a scoped menu instead of extending the inherited controls
Extending the inherited controls would have been faster. We could have regrouped the icons, added tooltips, and shipped with less engineering work.
I pushed for a custom menu because tooltips did not solve the underlying problem. The new structure groups actions by scope and labels the unit affected. The trade-off was maintenance cost. The benefit was knowing what a control would do before committing a change.
Preserve continuation across pages and columns
One proposal was to stop tables from continuing across columns and pages. That would have removed the most visible breakage and reduced the implementation scope.
I pushed to preserve continuation because long tables are part of the workflow. Forcing them into a single page or column would have changed the document model rather than fixed it. We kept continuation and defined how the table behaves at each boundary.
Document edge cases before implementation
The instability appeared across resizing, added content, combined cells, external content, and reuse patterns. Fixing only the reported defects would have left the other paths undefined.
I created an edge-case matrix mapping each input condition to an expected outcome. Engineering and I used it as the reference for implementation and review.
| Editing action | Continuationacross layouts | Structurerelationships preserved | Alignmentto layout grid |
|---|---|---|---|
| Resize layoutuser adjusts a boundary | Reflow, preserve continuation | Preserved | Re-align to grid |
| Add contentfrom an external source | Continue predictably | Normalise structure | Fit layout, prevent overflow |
| Combine cellsacross a region | Keep region intact | Recalculate relationships | Preserve alignment |
| Bring in external contentfrom another source | Continue if needed | Map to native structure | Fit to available space |
| Reuse existing contentwithin a new context | Re-evaluate at boundaries | Preserve structure | Adapt to context |
Representative extract of the framework. Editing actions sit on the vertical axis, with behaviour across continuation, structure, and alignment defined horizontally. The matrix became the reference for table work across the product.
Tables should break between rows, never through them.
The rule was simple to state: break only at row boundaries, repeat the header on the continuation, and preserve structure across the split. Defining that rule gave engineering a stable basis for the harder edge cases.
Before, a row could split across the boundary with no header on the continuation. After, the table breaks at the nearest row, repeats the header, and preserves structural state.
For reporting teams, consistency mattered more than novelty.
The team left with a control system and a shared table model.
The work produced three outputs:
- Stable continuation across columns and pages, aligned with the editor's broader layout behaviour.
- A redesigned menu with scoped, labelled controls that replaced the inherited default and aligned with adjacent product patterns.
- An edge-case matrix that gave design and engineering a shared reference for future table behaviour.
The release was later deferred behind other roadmap priorities. When the work resumed, the framework remained the reference. The design was useful beyond the original release plan.
Migration was part of the design.
The redesigned menu was easy to validate in isolation. The harder problem was supporting people who already used the product every day. Many could find common actions from memory, despite the limits of the old structure. Replacing it outright risked making a better architecture feel like a regression.
The final approach had to account for both the target design and the path to adoption. In a mature product, migration is not a rollout detail. It is a design constraint.