Welcome back; this article is part of the series called DaS™ – Naming convention.

The previous article explored the history and mental models behind sorting information in digital space. This article will discuss how our research impacted folder structures for remote product teams. One place, one location, and one language contribute to better transparency across the team and the business. 

Figute02: Structure 

The Structure

The structure below, in essence, represents the mental model of the product team. Instead of being biassed and having 27+ different folders describing brief, org-chart, or god knows what, we have surveyed 1k+ people about what folder structure they use while delivering the product or service. [001↘︎]

With hundreds of answers from the different business functions, we’ve settled on a product design structure that any designer can adopt from day one.

Company Name

The same (or similar) as the file structure in the previous article, I tend to create the following mental pattern where the “The Company Name” becomes “TCN” (for the purpose of this article). The TCN becomes an abbreviation of any sub-folder or files I create within. 

Please note: if you have been working for one single company for more than fifty years like my father, skip this point – there is no point in repeating the name of the company you dedicated your life to. 

If not, the advantage of this activity is that whenever you type in Apple Spotlight Search or any other alternative cloud drive can reach the file you are looking for in less than two clicks – simply search for it.

Figute03: Business, Design and Development


We all like the specific order. I have already spelt some secrets in this article[002↘︎], so feel free to dive into even more details if you wish. In general, I define the structure for every business startup or corporation in the following way:

Business (Strategy and Vision)
Experience (Design)
Technology (Engineering)

I’ve been successfully operating for more than a decade and a half within this model:

Figute04: Structure

Name of the Company 


1.0 — TCN* Hello
2.0 — TCN* Business
3.0 — TCN* Research


4.0 — TCN* Content
5.0 — TCN* Experience
6.0 — TCN* Design


7.0 — TCN* Development
8.0 — TCN* Releases
9.0 — TCN* Integrations

*As you can see from the structure above, the numbers define the order, the brand defines the logical group, and sections decide the function related to the product.     

The Function

Each folder has a specific set of correlated data with the desired output—for example, the PID – Project Identification Document[003↘︎] is in the Business folder. The research folder [004↘︎] compiles all competitive, design, behavioural, and user landscape analyses reused (or referred to) in the following folders: experience, design or development, etc.

The reason behind that is quite simple. If we refer to research, we should have everything in one place. Then if we build something on these findings, the desired behaviour = 5.0 Experience[005↘︎], particular visual treatment = 6.0 Design[006↘︎], or perhaps inevitable functionality = 7.0 Development[007↘︎], in a specific timeframe = 8.0 Release[008↘︎]. 

Figute04: Application 


The team of one

As a team of one, you are the queen, king or both in your kingdom. You set up, challenge and maintain the structure as you wish. Even if you start creating the shared files, you can still control your network and keep it tidy. 

If you make it suitable (according to research), you save yourself 23% of your time; if not, you waste almost 40% of your time finding stuff. [009↘︎]

One Team

That brings us to the team of many. You might ask why this structure is not in the group of many, too – actually, it is as it becomes scalable from a “one to many” mental model.

Over the last 1000+ implementations, I’ve asked everyone how they found it. We discussed, amended and implemented with little to no changes. The departments and functions focused on the delivery adopted quickly, whereas the departments focused on individual outputs like the insights team need a bit of tweaking. 

Here are the differences: 

A product has specific needs compared to a department, research or insight function within these departments. That dictates the adjustment for the purpose. 

Surprisingly enough, the structures that we adopted in 2006-8 are still in place and spread across the entire 3000-plus employee business as a natural response to the need for – clarity, transparency and accessibility. 

Team of Teams 

That brings us to the final advantage … and perhaps the more relevant one in the current era.
Literally, all organisations currently scale their propositions and call for “staff on-demand” integration. Having the corporate “product-based structure” aligned allows BA, UX, UI, researchers or copywriters to find relevant information every time they move from one team to another in the same business unit is even more crucial.  

The calculated waste of time finding the latest information in a corporation of 1k+ people is more than 40% of productive time. Let’s translate this to a 20-day month – eight days will be wasted on finding existing stuff. 

(the number above includes – a journey from login, opening up and adequate resources and search for a specific piece of information in the digital structure)

Remote Teams

That brings us to the latest and most relevant point: remote teams. 

It’s no longer applicable to freelancers as every one of us works remotely. One of the most common daily questions is:

“Where can I find the latest design, presentation or prototype?” – Linked in Survey

We spend 16% of our productive time (over an hour a day or 3.2 days a month on Slack) rather than creating a flexible structure that works wide cross-company. By polluting our conversation about where the stuff is, we lose the touch of making things. Concentrating on communication makes everyone busy with zero impact on our users.

Figute05: Where Next 

Where next 

The folder structure will not save the communication challenges for your company. Yet, very soon, you might recover some of your time and sanity regarding your productivity. You can read the other two days if you are more productive and work only 6 hours a day. 

Here are some considerations that help me with my thinking; yours might be different.

1/ How do you run the project? 

– Jira, Confluence, Trello Asana, Miro?
– MS 365, Google Drive or DropBox?
– Or both and more?

2/ Is there a hierarchy/dependency?

– Do you know where you are by looking at the specific folder or piece of information?

3/ How deep can you go?

– 3x3 goes only three levels.
– That still gives you 243 places to put and organise your work around one project (never use more than 90, even in the most complex proposition)

4/ Does your text replicate the operational structure of your local folder or your structure in the work folder?
(for the purpose of this article)

– My files
IN – From Client
WORK – Work in progress
OUT – Delivered
LIVE – Signed Off
5/ What will happen in someone accidentally delete the folder?

– is there a backup/history?
– how far does the backup goes?
– is that important for the project? 

“Let’s help all product teams to see what we are creating by sharing the information in one common place – One Location.” – Jiri Mcc, Greenwich 

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm