Being part of a vast company represents, among other challenges, a considerable effort to understand tons of information, processes, actors, and roles. In my experience, one of the most significant issues I see is the lack of centralizing and organizing information with a purpose.

This disorganization of documents is not only a Big companies issue; small projects like start-ups may also face this problem significantly if they do not fully assimilate the concept of design ops. For example, I’ve been working for a year now on one project with a couple of friends, and one of the challenges we have is to figure how to put in a single place all the resources we have created so far to consult effectively. Although we are in a “genesis stage” of the project, creating an adequate documentation method will be crucial once the project grows.

Whether a big company or a small start-up, having information spread in too many sources increases uncertainty and anxiety once you build a project or a solution for an actual problem. Not to mention that having onboardings for each new team member or stakeholder will be a painful and exhausting process.

One of the consequences of having disaggregated information is to have a similar stage as the “Age of empires.” As in the game, we will only recognize what’s immediately in front of us and nothing more unless we discover and conquer more territory. Moreover, this information discovery supposes more cognitive wear and the making of conspiracy theories every time we jump into a meeting and try to understand all the ideas that are surfacing.

Another significant consequence of the “Age of empires state” is that we may be at a disadvantage regarding a general audience once we show up in a meeting. To get the whole context of a problem and develop a solution, we need to connect too many dots and do some research first, which will require more time in planning and execution.

Folders, drives, presentations, and wikis?

Is it enough to document all critical info of a project into a dropbox, G-drive, or any other collaborative tool? I would say yes, but partially, and depending on the primary intention. The first issue I’ve detected with having these documentation structures is that maintaining a proper order can be tricky, and the problem can increase if we share them with other collaborators. If rules to edit are not clear, every collaborator may end up creating different structures of information.

The second issue in this option is the lack of guidance or rules to find information; how to navigate? Is there an AI or text file that enlightens me on how to search for what I want?. In these scenarios, we often depend on someone who knows how to find the things of interest, which is not the most effective way. Another method may be to discover by our means, but the truth is if we are in a company that moves fast, we need immediate answers.

The third issue is the intention; all the purpose of documenting is to provide information for strategic conversations and metrics? Maybe for a repository of progress?. Is this source valid for all types of profiles? As product managers and as designers, do we need to refer to the same data? Sometimes this is not clear, and we need to surf all types of information without any distinction.

How did we solve this? Here’s the idea

When I got to this new job, it hurt a lot to read all the documents my partners shared with me, and to be honest; it didn’t work at all. I remember that I had multiple presentations connected with others without any specific order nor orientation; As a result, I ended up seeing problems that were entirely beyond my need and understanding. But then, I realized I was not the only one suffering from this; many product team members were also struggling with the same issue. So one day, we met and shared our frustration about this particular challenge. We decided to fix this, and we created a plan based on the followings milestones:

A common need. (We’re not a call center)

The first thing was to point out all the difficulties we were in by not having a single source of truth, at least one that works. One of the biggest pains we realized we needed to relieve was the lack of knowledge of some teams regarding some internal procedures. That point represented a massive effort for the product team to cover daily. Concepts, users, departments, contacts, and even glossaries were questions to answer.

A purpose. (A self-management tool?)

With some identified pains, then we needed to provide an intention to document info. The questions to answer were: why should we do this? What benefit can we take from this? How can we help others with a document structure?. The statement behind this solution was, “we need a place where all teams can get the relevant information according to their needs, no matter the discipline nor the seniority.” With that said, the next goal was to create a way to classify information and navigate it.

Defining an A.I. (how to navigate? what are the significant parts)

To capture all disciplines and seniorities, we divided the information into some pillars: The first one is a general overview of the project (basic concepts, users, teams, and a short guide of navigation); Why? The idea behind this part was to set up the foundations and overall understanding for everyone that wanted to get the big picture of the project. Also, this was perfect to onboard new team members, stakeholders, and others.

The second pillar contained all documents related to the tools and tasks. Again, the audience changes; here, all commercials and work teams can get a deep dive into some actions and rules. The principal intention also changes; This part is more oriented to guide people to run daily tasks and procedures.

The third and final pillar is about getting feedback from users, experience polls, and others sources of information. This part intends to build the stepping stones for future iterations of the platform.

Defining gatekeepers and Platform (frequency and maintenance)

All the above doesn’t work if we don’t settle solid rules to follow. So the first thing to decide was to pick the persons in charge to ensure that everything was updated, relevant and coherent. For that task, the product team decided to include a mandatory step every Monday to add all new information related to tools and procedures. In addition, they should announce every significant update on the workplace page, and finally, one person from the design team will oversee the look and feel for every new layout.

Regarding the platform, to start, we decided to use a G-site. The reasoning behind this was simple; we needed an easy way to upload content and modify at will everything we wanted without generating an extra task for designers and developers. Last but not least, the G-site was enabled to work only within the company avoiding leaks of sensitive information.

Rules of engagement (what is, what is not)

Once we decided to advance with this project, we started to involve people in the initiative. In the beginning, some people began to push back, and then we realized they understood this source of truth as an extra step to cover daily, which was not a popular idea. So we decided to create a “what is / what is not” list for everyone and clarify all possible doubts. Here are some statements:

What is!

• An evergreen information repository.
• A complete guide of procedures for every tool we have.
• A users and stakeholders ecosystem.
• General strategic documentation.
• Onboarding guide.

What is not!

• It is not an extra layer of work. All information should be evergreen, and that means long-term agreements and not ongoing decisions.
• A repository of changes. For this matter, other platforms better fulfill the purpose.
• A feedback manager.
• A backlog tracker.

Once the team understood this, they felt confident contributing and being part of the project.

Spread the idea (how to scale?)

Like many other projects, this one started as a proof of concept. However, the results so far evidence a good adoption from users: the commercial team, product team, design team, and other stakeholders seem to use this new source of truth as the primary artifact daily. So how should we scale this idea? The next target was to generate the Portuguese version to cover the Brazilian users and have one unified structure for all South America. In time, the IT team decided to join us by connecting their site with ours because they saw how this self-management tool could save tons of work and planning.

We also had a design HUB where we documented internal concepts, methodologies, and artifacts. Should we connect this site with de one from the product team? The answer is a solid yes! It was a beautiful accident that we ended up creating a strategic portal where users can access relevant information under the same premise: a self-management idea for all.

Today, the “strategic product document” (DEP in Spanish), as we named it, is one of the most used tools in the area I work, almost every day, we refer to this site to find or consult any question we have. Everything is there, and it is grateful to see how new members use it to understand what we do and how we look more like a compact unit. Comments have spread out into other teams. They start to look with bright eyes all the world we built; who knows if eventually, we can create a positive contagious across the company, but for now, our area has minus one problem to worry about.