;

The Folder Structure for your remote team.

Featured Image

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

Order

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 

(Business)

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

(Design)

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

(Development)

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 

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 

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Product Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to define teams of 01, 10, and 100, and 1% supported by Grid Magazine and Supply section, where we bring more insights weekly on how to become a design leader in your Agentic Organisation

Author's Name

AVATAR

inResearch

42

inWriting

77

Released

230
EMT

Related.

Featured Image
The tech industry, and design within it, often perpetuates a comfortable myth that every designer needs a single, seasoned mentor to navigate their career in constant change. That is why thousands of designers turn …
 · 
2021-08-01
 · 
6 min read
Featured Image
Welcome to the Design at Scale Method series. Today’s article has no more minor ambition than to connect, empower and unify all product designers under a simple Manifesto, which easily translates the value of …
 · 
2021-02-17
 · 
3 min read
Featured Image
Welcome to the Design at Scale Method articles. Today we’ll be looking at combined Methods that help Design and Scale deliver value in complex propositions and thrive in environments of constant change.  While both …
 · 
2021-02-10
 · 
4 min read
Featured Image
Welcome to Design at Scale – this article will focus on the mindset and how adopting it can make a difference in Product Design Delivery. To understand the mindset definition, let’s borrow the description …
 · 
2021-02-03
 · 
3 min read
Featured Image
Welcome to Design at Scale. This article will focus on the values that every designer who scales design propositions embodies and masters while delivering incremental value to the team and the business – not …
 · 
2021-02-03
 · 
4 min read
Featured Image
Welcome to the Das™ Method articles – today, we’ll be looking at the Principles behind the Design and Scale. Most articles describe how to write great principles – be specific, direct, and focus on …
 · 
2021-01-27
 · 
5 min read
Featured Image
Historically, design was defined as the stage-gate iterative process. To paint a portrait, wall, or cathedral, we all understand the task and what can be measured, sized, and calculated in some ways. They require …
 · 
2021-01-20
 · 
4 min read
Featured Image
We start with a clean sheet of paper and a pencil.  That’s where all designers begin.  For centuries, creatives across many different disciplines have always been a piece of paper and a pencil that …
 · 
2021-01-13
 · 
2 min read
Featured Image
Thank you for stopping by and dedicating your time to learning something new about design. Design at Scale™ is an ambition to unify all designers under the umbrella, offering clarity, stability and transparency for …
 · 
2021-01-06
 · 
3 min read

GRID Magazine

Explore OUR 
Articles

Every week we bring set of stories reflecting on communication, operation and technology.

Newsletter

Subscribe.

We share our 20 years of experience in creating, managing and scaling products and services that allow individuals to shape organisations through design.

Design at Scale™

LINE_MAGENTA_050_301

Categories

LINE_MAGENTA_050_301

Data

LINE_MAGENTA_050_301

Share

Internal

Collaborate

Resources

IBM PlexSan
Regular
Charcoal

Design at Scale™ is defined by three models, which form the Method. Each model operates in a different part of the business and collects and informs parties on design and engineering decisions that have a direct impact on the delivery.

All brands and trademarks presented on the Design at Scale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners. Do not copy or publish any of the projects shown here without written approval from Design at Scale™ (alternatively GIVE™, 9V™) and/or relevant companies and agencies.

SOC_Twitter
SON_LinkedIn
SON_Instagram
SOC_-Medium
View