Salesforce

UX Strategy and Content Design

Timeline: May 2022 - August 2022

Role: UX Strategist & Writer

A special thanks to: Kris Royer Collins, for mentoring me throughout my time at Salesforce.


At Salesforce, content centers are internal developer tools full of information for engineers to utilize and ensure that their services are operable. However, these content centers are full of an abundance of documentation and resources that touch upon every aspect of the developer experience—and some of it could be wrong or outdated.

This is where feedback comes into the picture. Feedback enables technical writers to make the appropriate edits to the internal content centers so that Salesforce engineers are able to streamline their work process. However, across Salesforce’s four different content centers, the process for giving feedback is inconsistent, making the process for implementing iterative changes confusing and inefficient.

As Salesforce’s Technical Writer Intern, I led an end-to-end UX research project to redesign the feedback mechanism for the company’s internal content centers. Through a combination of content design, user testing, and a lot of Figma files, I proposed to Salesforce senior leadership a new way for employees to give feedback with ease and control.

 

Defining the Project Scope

To gain a better understanding of the factors leading to the issue, I first led a town hall meeting with the Internal Content Strategy team to diagnose the problem—looking at it from the lens of both the users, the constraints, and the overarching organization. I discovered that based on the business needs, the new feedback mechanism required the following:

  1. Have the ability to visualize the quantitative data that is gathered

  2. Initialize a workflow to act on the feedback and work items

  3. Consistent UI text that is flexible and adaptable to the specifications of a specific content center

For the feedback mechanism, the stakeholders include both 1) the engineers to which the content centers serve and 2) the technical writers of the content centers who collect and implement the feedback from the engineers. Therefore, the redesign of the feedback mechanism must balance these two stakeholders.

 

Identifying the Problem

I didn’t want to hear from just the team. I also wanted to hear from the actual users themselves: the engineers who utilize the content centers. I gathered nine participants, all of whom are users of the four different content centers. I designed the user research guide to include behavioral questions about the participants’ past experiences using the content centers and interactive visual exercises based on current feedback procedures. I specifically analyzed how they navigated each page and function, collecting both quantitative and qualitative data about their behavior.

Based on the participants’ interactions with the content centers, I identified the following insights.

Key Takeaway #1: For those who have given feedback before, almost all noted that the way that feedback had been given had been through mediums besides the actual feedback mechanism. This includes surveys, Slack conversations and threads, and a comment section at the bottom of the page.

Key Takeaway #2: When asked about how much time people were willing to give feedback, most noted only a couple of minutes, specifically 5 minutes. This short time span means that our feedback mechanism needs to be quick and simple because users are not motivated to use the current feedback forms because of how time-consuming it is.

Key Takeaway #3: When asked about what features participants would like to see in a feedback mechanism and what would be the most ideal way to give feedback, they noted the following:

  • Make sure that the mechanism allows the user to display thoughts and indicate if they would like to give even more feedback

  • Clarify where the feedback is going after the form is submitted

  • Indicate a way to acknowledge if someone has seen your request

  • Identify a way to point to a piece of content on a page and say what is wrong or needs to be changed

After assessing these insights, I crafted a central problem statement that would guide the content design challenge:

How might we create a consistent feedback mechanism that motivates content center users to give feedback while allowing technical writers to consolidate and respond to this feedback?

 

Designing the Wireframes

I began to sketch the initial wireframes of the feedback mechanism, prioritizing the following:

  • Feedback button placed on bottom since users go to the bottom of pages for help

  • Form should be a Confluence form embedded into the page

  • Content and copy should be informational but short

  • Instructions to guide the user should be written at the top

  • Copy informing the user of where the feedback goes and to which team it goes to

Then, after sketching the foundations, I brought my vision to life by designing a high-fidelity prototype on Figma. The first screen is the home screen of the Writing and Communication Content Center. I placed the feedback mechanism button at the bottom left of the page, and the button will guide the user to the actual feedback page on the second screen if the user clicks “Not really”.

When the user indicates an issue with the content center, the actual feedback form pops up. The top of the form contains brief copy that informs the user of what the form does. The form also includes three simple questions to help reduce cognitive overload. Finally, the bottom of the form contains additional copy informing the user of which team the feedback will go to and where they can check the status of their feedback, if needed.

 

Testing the Waters

But I didn’t stop there. I wanted to make sure that employees would actually use what I built. So I took the prototype back to the field for a round of user testing to observe how users would interact with the redesign.

This time, my UX research focused primarily on interaction with the prototype through observation and open-ended questions. I designed the research study to give participants autonomy over how they wanted to interact with the tool, and from there, dive deeper into their thoughts and opinions. I ran this test with 7 participants.

After averaging the usability rating given by participants, the prototype received a score of 5 out of 10, a rather mediocre result. In fact, some even stated that they would never use the mechanism to give feedback. But why?

I looked back at the comments and interactions and discovered the following:

  1. People did not like putting in their work email or the page title. They want this section to be auto-populated because they believe or assume that the Confluence page would take this information.

  2. The copy “type in the title page” is not clear. In fact, people can not see the title page in the page tree unless they pull it out due to the collapsed sidebar on Confluence.

  3. The instructions on the top of the page were ignored. Many stated that it looked too small or didn’t seem important.

  4. Participants wished to specify the problem even more. An example includes differentiating between whether the issue is missing information or incorrect information.

Moreover, participants consistently noted that the idea of a Slack support channel is appealing. This is because they would know who the person is behind the feedback and it streamlines communication between both parties. Furthermore, many support channels are now centered around Slack.

 

Back to the Drawing Board

There is delight in feedback, and I took all of these insights and decided to make the following changes in the final iteration of the feedback mechanism:

  1. Remove the Salesforce email and page title questions

  2. Include radio button question to allow users to specify the actual problem

  3. Populate submissions to a Slack support channel to streamline communication

  4. Make copy changes to further reduce cognitive overload and emphasize certain functionalities

 

The Final Iteration

The changes I made above went into the final designs I created and proposed to the content strategy team, which can be summarized into the following three user flows:

Add a button to submit feedback at the bottom of the Confluence page

The button to give feedback should be placed at the bottom of the page right on top of the comment section because most users tend to navigate to the bottom of pages when looking for help. The wording has been revised from the original prototype to clearly indicate that clicking the button will allow users to request improvements and give feedback.

Add a form to submit feedback, suggest improvements, and specify which page or section to implement these changes

After clicking the “Click Here” button at the bottom of the page, a Confluence form pops up on the screen. A description at the top tells the user that the team managing the center views the submission in a Slack support channel. The form consists of these three features:

  1. Page link or screenshot upload: The user has the option to submit the page link or a screenshot of the page. This gives the user some autonomy over how they want to point to a specific area that should be improved.

  2. Radio buttons specifying the issue: To help track data on what issues users are facing, the user selects whether the issue is incorrect or out-of-date information, missing information, information that they aren’t finding, or other. This also guides the user to reflect before they enter their suggestions for improvement.

  3. An open-ended section to type their requests/feedback: The user here can be as detailed as possible and specify how the team can improve the content center.

Link the feedback to a Slack support channel

Finally, the form submission will be transferred to a designated Slack support channel. There, the user can see their form submission and interact with the tech writers managing the content centers. This facilitates open communication between both parties and writers can ask for clarification and let users know when their requests have been resolved.

The form submission notification would look like the following in a designated Slack channel.

 

Lessons Learned

My time at Salesforce was full of lots of accomplishments—but more importantly, obstacles that taught me valuable content and design lessons. This includes…

  1. Asking the right questions. Whether that be user research or hosting meetings, learning to ask the right questions allows us to better define the mission at hand.

  2. Falling in love with feedback. When creating for an intended audience, you have to let go of your ego and know that you are creating for them, not you. Feedback is the perfect way to better understand those you are designing for.

  3. Words matter. They guide users through the entire process from beginning to end. It’s up to us as writers and content designers to ensure that the path is clear.

The biggest shoutout to my amazing tech writing team for being so incredibly supportive and kind!

Next
Next

Alltruists