Mapping a business that existed
only in people's heads

When I joined the company, there wasn't a document explaining how a new store opening worked. Design requests arrived as individual tasks, often detached from the conversations that generated them. I knew what needed to be designed, but not how each task related to the wider business.

Instead of waiting until I understood everything, I started recording everything. From my first day, every task was added to my work log. At first it was simply a personal reference. I wasn't trying to document the business. I was trying to understand it.

As the weeks passed, those notes became more than a record of completed work. Patterns began to emerge.

Rather than treating every task independently, I started comparing them. Not asking what needed to be designed, but asking why it appeared at that particular moment.

Each completed project became another reference point. Repeated requests gradually revealed recurring relationships. Some deliverables consistently followed construction drawings. Some only appeared after menu approvals. Certain production work repeatedly required longer supplier lead times than others.

Instead of documenting individual tasks, I started documenting their relationships.

The first outcome was a simple checklist. It wasn't intended to become company documentation. It was a working model that helped me understand what normally happened next.

Before relying on it, I reviewed the structure with our junior designer, who had previously participated in an earlier store opening. The discussion helped distinguish existing practice from my own assumptions before the checklist became the foundation for future openings.

As the checklist became more detailed, it also began solving a different problem. Many of the workflows weren't actually missing. They already existed across conversations, habits and individual experience. The difficulty was that different teams often understood different parts of the same process.

This is common in rapidly growing businesses where processes evolve faster than documentation. As new roles, suppliers and locations are added, work is often coordinated through conversations rather than written systems. Everyone understands their own part of the process, but the boundaries between teams gradually become less visible.

A website update, for example, isn't a single task. Creating the page, assigning the URL, publishing it and preparing search metadata may belong to different people. If those steps are grouped together as "update the website", each team can reasonably assume that someone else has completed the remaining work.

The purpose of documenting these workflows wasn't to create more paperwork. It was to make ownership, handovers and completion criteria explicit before work fell between teams.

As more openings were completed, the relationships became increasingly predictable. Instead of responding to requests one by one, I began working backwards.

If an opening date had already been confirmed, I could estimate when each design stage needed to begin by tracing supplier lead times backwards from launch. If only construction drawings had arrived, I could estimate how far the project was from opening by comparing them with previous openings.

Each completed project either reinforced the model or revealed an exception. Every exception refined the framework.

As the framework matured, individual documents naturally evolved for different purposes. Some helped forecast future work. Others organised recurring deliverables across brands.

Together they externalised knowledge that had previously existed only through experience.

None of these documents were the objective. The checklist. The timeline. The planning references. They were simply evidence of a way of working.

Looking back, I realised I wasn't trying to create a process. I was trying to understand one well enough that it no longer depended on memory, assumptions or informal conversations.