Google Patents Redesign

Client Location: Hong Kong
Client: Disclosed due to NDA agreement. NOT Google!
Year: 2019-2020

A Hong Kong-based angel investor had a holding parent company with a diverse portfolio. The portfolio included more than 50 small and medium-sized South East Asian startups, and he approached me with the following three problems:

  • All of these companies have and produce multiple documents, with more than 3000 items by the time they approached me
  • Each company has its own system to manage the documents, making it harder for the parent company to have an overview
  • Some companies seize to exist (they merge, become insolvent, do not survive, and so on), making some documents lost forever. A system to keep them as archives was desperately needed
Figure 1. The physical collection of documents was massive, but all of them were stored in soft copies. Image source Pixabay.

Familiarity with Google Patents

The client had been using patents.google.com and wanted a similar closed platform with double authentication with access only to the board of directors and select partners (lawyers & accountants). Effectively this was an information architecture project with some Google Patents redesign.

The types of documents that the client was using, were vast with more than 50 different sorts!

The project was broken down into two sub-projects:
a) creating an order for all these documents
b) creating an interface to browse all these documents

The main categories I came up with were the following:

Figure 2. Suggested Document Category Types

Type of documents
L – Legal Documents
F – Financial Documents
H – HR Documents
S – Strategic Documents
O – Operational Documents

Naming Files Logically

These categories formed a controlled vocabulary that the client revised accordingly, making it match ideally to their circumstances. This controlled vocabulary was the basis for creating a file naming convention, making searching and locating documents convenient and easy.

Figure 3. File Naming Convention

The file names had 5 components:

  1. Initialism formed after the company name
  2. Type of document, based on the list shown above
  3. Date when the document was ratified
  4. A sequential number for the case of multiple documents being issued on the same day
  5. Title of the document – effectively the document content.

Giving Form to this enormous document collection

Upon giving structure and form to these documents, the next item that was needed is to build an interface for browsing these documents.

Figure 4. Internal Document Search Engine Interface

The client was very familiar with Google Patents and was using it often. They requested an interface that has a sense of familiarity and would require the minimum learning curve for their team of lawyers and accountants who often needed access to all these documents. The interface that was offered was stripped away from any branding and was kept to the minimum while emphasizing strong filtering options.

The results shown contained multiple metadata for each document, including a title, a document code, document type, and status, company name, signing location and date, as well as file type and a short description. Some of these metadata could be clicked and lead to further pages with relevant content that could be filtered with the filters explained below.

Figure 5. Breakdown of the result

Multiple Filters

Figure 6. Several filters in the left panel

Several filters were introduced:

  1. Company name,
  2. Document types, as listed above,
  3. Document status, showing if the document is completed, inactive, etc.,
  4. Type of signatories, such as government, individuals, or companies,
  5. Signatories, meaning who signed the documents,
  6. Signing locations (cities),
  7. Years when the documents were signed.
Figure 7. Filters in the right panel

Another useful feature that was incorporated into this internal search engine, is the ability to further select specifically more narrow document types (shown in Figure 2)

Figure 8. Document type filters

Upon selecting a document type, the panel would expand further options corresponding to document types belonging to the chosen option – in the example shown in Figures 8 and 9, the Financial document type has activated more financial documents, making document retrieval a breeze

Figure 9. Dynamic filters.

Development

Once this design was introduced to the client, it was commissioned and built internally by one of their portfolio companies, and all the documents were fed into this search engine. I also advised on some python scripting to get the files renamed accordingly, and the entire search engine was live within a week. There is also a backend interface where document entries can be edited individually or in bulk.

Reception

The client was particularly happy as previously everything was dumped on a shared dropbox folder with multiple random naming conventions. This was not convenient at all and the client mentioned that several hours – minutes each day were spent trying to find documents. The situation was so bad that they were considering hiring someone just for locating documents.