Research question

“How can we reorganize our documentation to give the right hand-holding during the developers’ SDK installation experience?”

Subsequent research questions

• What kind of content do developers seek on the documentation page?

• How can we reduce the time developers spend on documentation?

• Can we reorganize the documentation navigation to be more developer-friendly?

• What can we provide developers to efficiently search for information without needing further human support?

Stakeholder interviews were done as a first step to Documentation revamp research. As the Documentation contains content for all Sendbird products, it was necessary to listen to Product Managers from each Sendbird product (chat, calls, desk, and pricing). I asked the PMs to elaborate on the Documentation they had good experiences with and what made it a good experience. In addition, I received their feedback on the current Sendbird Documentation, needs, and areas of improvement.

Example questions:

1. Do you think Sendbird Documentation could be better in a certain way? What are those ways and why do you think it should be improved that way?

2. Please name three companies that come to your mind when we say ‘A good Documentation’.

3. Why did you choose those three companies? Could you explain in detail how you found each Documentation ‘good’? How do you define ‘good’?

4. If you could implement one Documentation component to Sendbird Documentation, what would it be and why?

Interview scripts were later used to do a competitive analysis. Based on the list of companies PMs shared, we compared the Documentation components and defined areas of Documentation reorganization in alignment with the sub-concept derived from the previous Self-service onboarding research.

Evaluation scores based on core product:

4 - Complete: The asset is provided in detail, clear layout with possibly multiple options.

3 - Partially complete: The asset is provided but would do better with additional information and a better layout.

2 - Needs revision: The asset is provided with limited information and needs additional work.

1 - Omitted: The asset is missed.

During the ethnographic interviews from Self-service onboarding research, we drew sub-concepts of developers' experience with the documentation. Sub-concepts were critical as they consisted of real user critiques and feedback.

I aligned our internal needs (feedback from Product Managers) and sub-concepts, internal needs being the standard of our areas of improvement and sticking the sub-concepts on the sought areas to quantify the priorities.

Now that we have gathered the feedback and needs, we needed to take a closer look at our quantified data to assess if the collected qualitative data signify the needed focus areas and to prioritize the reorganization needs in sequence. Google Analytics and Looker were used to reference the unique page views, page views, and percentage of behavior flows. Although our focus was on our documentation, we took a look at our entire sitemap to have a holistic overview of page views.

Through behavior flow analysis, we identified the -

1. Documentation is the primary accessed resource, with the Developer Portal, a step-by-step guide, coming second.

2. The pages that remained in the highest behavior funnel were Products and Resources.

3. The Demos page received higher pageviews than the Blog page in Resources.

4. Among products, Chat had the highest page views, double the Calls.

5. Other than the Documentation, the pages with the highest unique pageviews were Pricing and Sign up.

As the Marketing team was already using the tool called Hotjar, we also used heatmap evaluation to visualize how people behave on our website. In addition, heatmap evaluation was to fill-in-the-gap information of behavior flow analysis.

Although the heatmap provided us with helpful insight into the user funnel of our website, it was not easy for us to find out the user goal and the reasons for behaving in such a way. Furthermore, it displayed multiple nationalities of users without specific user expertise, like their experiences as a developer. It was helpful in visualizing the general behavior patterns on Documentation, serving as a sub-guide for designing the final information architecture.

Through heatmap evaluation, we identified the following -

1. How search bars are used: users usually type only one or two words and scroll down for the exact information they are looking for.

2. How the Documentation menu is being used: users tend to search directly for what they need from the menu bar on the left.

3. How Codes and images are being used: users spend much more time looking through the codes/images rather than reading the text that explains them in detail.

Referencing from the insights from research, we set our design requirements and guidelines for our Documentation revamp. The below shows the high-level requirements we generated to revamp the Documentation page.

1. Define the ‘developer contents’ and regroup the contents by their purpose

2. Implement the frequent components in use and add on what we do not have

3. Implement the #tag system to all of our contents for using them in proper domains

4. Reorganize the Developer portal’s main page for smoother access to navigate all developer contents

5. Spot the duplicated contents in different sections to integrate them into one

The visualized Documentation journey map assisted the team in contextualizing and comparing overlapping pain points to identify the best opportunities.

As we drew the Documentation journey, we have also created a simplified information architecture of our website for more straightforward content labeling and organization.

Looking at the image, the left IA displays the Sendbird website before, and the right IA indicates how we planned to change the sitemap with the Documentation revamp.

We shared a significant amount of time on how and what we should include in Developer content and tried to integrate the contents that were not viewed as much, having our primary focus area on developer-related content like Documentation, Products, and Resources pages. Furthermore, we tried to link the pages that developer-related content could take the user to.

On April 29th, 2021, the new look of our Documentation page was launched (Hooray!). Before the revamp, Sendbird Documentation was rather text-based, with images and icons that were difficult to read unless the text was read. For instance, many developers misunderstood our sample apps’ platform logo that took them to the Github site, thinking it would take them to the platform-specific Documentation page.

Focusing on our search function, we provided clear images and lessened text with the Documentation. We also included more storytelling images, separating the other content, like support pages with different colors and designs. The revamped design initiated actions that had a significant impact.

Reference link: https://sendbird.com/docs

1. Successfully presented and shared the research outcome with the Product management team, including the Head of Product and VP of Engineering.

2. Set 2021 goals for our further renewals with our Documentation page.

3. Set the foundation for the subsequent research, which involved a thorough qualitative validation.

4. Reached our goal of increasing the page view counts of each content in the developer funnel - ‘Documentation start page’ to ‘UIKit product page’ up by 20% within 2 months

To continue with our Documentation revamp and measure its success, we set our short-term goal to increase the pageview counts in the developer funnel by 20% within 2 months. The funnel set was from accessing ‘Docs start page’ to ‘UIKit product page’ as it was considered the most critical page of our new Docs site.

Reviewing the data, checking the status, and using those analytics to gain the product and the business insights, we proactively used our tools to track. Notably, we also looked into the increase in self-service to determine if the reorganized Documentation was giving the right hand-holding without customer support from Sendbird.