Building a System Inside a Tool Never Meant for One

Proof a system doesn't need the right tool to start working.

Six teams building digital products independently, each with their own way of doing things, and no centralised reference point for any of it. My job was to build one… inside Confluence.

Confluence is (obviously) not a design system tool, it's a wiki. No component support, no variant logic, no visual documentation out of the box. Everything had to be structured manually: how components were categorised, how they connected to each other, how layout rules were documented, how updates would be communicated. Every decision about the system's architecture was mine to make, and then mine to maintain. The alternative was waiting for better tooling. I didn't think that was the right call as the teams were building inconsistently every day the system didn't exist, and a tooling conversation could take months with no guarantee of landing anywhere (trust me, I gave it a little shot). Better to build now, in what was available, and start delivering value.

I ran it on sprints. Audited what existed across all six teams first: components, patterns, where things clashed. After the first few weeks, and having all available outcomes, I then built the documentation architecture and got stakeholder buy-in on the structure before filling it. I also presented the structure to the various teams, as they were my main primary target and had a chat with them to understand their most urgent needs. With the research done, the structure defined, and everyone on board, I moved to document section by section, following the priority levels that were setup.

Cross-team inconsistencies dropped 16% while the project was running. Then budget cuts came. Company-wide, nothing to do with the work, and the project closed with around 30% of components and 60% of layouts documented. Not finished. But working, and already making a difference.