Reduce Distraction for Large Enterprise Users

ShimoDocs is a cloud-based productivity suite allowing individual users and large-scale enterprises to manage and collaborate on online documents easily. Launched in 2015, it has provided service for 700,000 enterprises in China.

From summer 2021 to winter 2021, I worked as a product manager on the growth team. During the spring of 2022, I worked as a product designer, responsible for B2B features related to enterprise management and iteration for Shimo Overseas.

ShimoDocs will push notifications when people are added as collaborators or mentioned (@) in documents. However, in large enterprises, irrelevant stakeholders often receive notifications of such notifications related to collaboration features, which causes distraction for users.

Collaborator Permission: Limit the scope of collaboration to reduce distraction for large enterprise users

This project was created from scratch and launched in 4 months. As the product designer, I collaborated with cross-functional and cross-product teams to ensure the delivery of this feature.

Process

When doc-owners want to add collaborators, they are sometimes unsure who should be added. In that case, they would choose "Select All Members" However, in a large enterprise, these will lead lead to thousands of irrelevant people receiving notifications. What's more, the CEO and VP will be disturbed frequently.

Regarding enterprise management, the requirement seems complex: The representative from OPPO (one of the largest companies in consumer electronics in China) said they wish only certain people could add the CEO as a collaborator. And all employees should not be able to add top third-level departments from the company to collaborate.

The challenge part of the project is how to make those complex elements clear & actionable?

After discussing with back-end engineers and product managers, I identified the essential scenarios and feasible rules to solve the problems.

I explored different information structure to find the one which could lead the manager to set the rules accurately. The decision was made based on 2 factors:

• User-side: Clearly communicate the relationship among the scope of collaborator, rules, and doc owner.
• Feasibility: Since there was limited resources, the team decided to maximize usage of existing components.

01 How to make the complex concept easy to understand?

I did internal usability testing with 5 people. I found most people felt confused by the three types of department hierarchy levels. In the final version, I used images and words to make the concept clearer.

02 Feasibility consideration

After discussing with back-end engineers and the product manager, I changed how users select custom hierarchy. The decision was made based on two factors:

• Technical feasibility: With the dropdown menu, the server needs to go over the structure of the organizations to find the exact number of sub-department when users select a new department. It takes time and is not necessary.
• Product strategy: From the client’s side, they only need three sub-department maximum. However, from ShimoDocs’ side, we want to make the feature available for all enterprise users. The input method provides more flexibility.

Last year I received feedback that many visually impaired users could not use Shimo Doc and other cloud-based productivity suites in China. To address the problem, I invited the Accessibility Lead from Google Android to lecture about inclusive design, discussed feasibility with the tech lead, and delivered an accessibility toolkit to the product team. With those efforts, the consideration for accessibility has become the consensus in our team. More importantly, supporting accessibility was added to the roadmap of our new product.

As a freshman who just stepped into the tech industry, I wanted to learn about the whole picture in the field, so I decided to intern as a product manager first. Though I work as a designer now, the journey of PM gave me a lot.

• Product Thinking: From gathering user requirements to tracking data after launch, I started to understand the big picture and complex rationale behind a seemingly simple iteration. It made me think about both the “how” and the “why“ behind each decision.
• Communication: Having collaborated with almost every cross-functional team in the company, I found people with all kinds of backgrounds, ages, and positions have such different perspectives. Thus, I became more open-minded and ready to embrace other ideas and turn them into inspiration.
• Proactivity: As a product manager, I owned the responsibility to ensure the success of the launch of each feature. Thus, I could not wait for tasks but take active actions to get everyone on the team onboard. It reminds me of the importance of ownership and proactivity, no matter my position.

A big thank-you to those who shared the amazing year with me at Shimo :)