Org design: surfacing versus manipulation

TeamForm's platform faced a strategic fork: surface org data as read-only insight, or let users manipulate org structure directly. Enterprise clients needed the second. Engineering capacity only supported the first. My job was to work out whether that fork was real, or whether it was an artefact of a legacy component being treated as a product-level constraint.

To ground the design direction in how enterprise clients actually ran org design, I facilitated a workshop with one of the big four banks, walking through their org design process end to end: how changes were proposed, modelled, costed, and signed off before reaching HR systems of record. It surfaced how much of that process still happened outside any tool, in spreadsheets and slide decks, and how much friction that created between the people proposing a change and the people who had to validate its cost and structural impact. The process was also split across multiple separate workspaces, different teams working from different versions of the org with no shared source of truth between them, which meant even a simple change had to be re-validated in each workspace before it could move forward. That gap, between exploring a change and committing to one, became the throughline for the design work that followed.

The manipulation surface sat on a planner table built years earlier, on old infrastructure. In-place editing on that table was genuinely hard to build cleanly. Internally, that difficulty was read as evidence that manipulation itself wasn't viable on the platform, which shaped both the roadmap and, eventually, the sales conversation with enterprise clients who wanted it.

As senior designer on this work, my first job wasn't to design a solution, it was to test whether the problem was correctly defined. I separated two claims that had been merged: "manipulation is hard on this table" versus "manipulation isn't feasible." The first was true and was an engineering and infrastructure problem. The second was an assumption that had hardened into product strategy without being tested independently of the table.

That distinction mattered because it changed what needed solving. Once manipulation and surfacing stopped being treated as competing product bets, the design question became: can canvas-style exploration and table-style precision operate as two lenses on the same structure, rather than two separate products? This connected directly back to what the bank workshop had surfaced: the real friction wasn't picking one mode over the other, it was the gap between exploring a change and committing to one.

I built a working prototype, independent of the legacy component, to test the reframe directly. Canvas mode sits above, table mode below, in a single window. Both surfaces are fully manipulative, and edits in one reflect instantly in the other. Removing the legacy table as a foundation let both lenses do the job they were always meant to: canvas for exploration and validation, table for clarity and precision, on the same data at the same time.

TeamForm later moved toward an agentic chat interface for surfacing org data, a real step forward in interface terms. I designed the chat function and selected the graphing package behind it. But the underlying manipulation question was carried forward unresolved, just wrapped in a newer surface, which confirmed the original reframe: the constraint was never the interface. It was whether the platform let users act on org structure directly, independent of what UI wrapped that action.

The value I added here wasn't the prototype, it was catching that a technical limitation had quietly become a product-strategy conclusion. Recognising that distinction, and being willing to test it independently of the assumed constraint, is the difference between designing within someone else's constraint and questioning whether the constraint is the right one to design within.