The problem

Many organizations have modernized their customer relationship management with Salesforce. However, most still prepare, sign, act on, and manage customer agreements through manual, disconnected processes.
‍
Salespeople had to copy the contract in MS Word multiple times and manually fill in the information for different signers. This process was tedious and prone to errors.

DocuSign Gen for Salesforce helps automate and simplify agreement processes

It allows users to create agreement templates directly within Salesforce, eliminating the need to switch between different platforms.

Chorus is a contract template editor that lives within the DocuSign Agreement

Chorus consists of 4 parts
Top toolbar: contains all the basic content formatting tools
Left side bar: where all Docusign fields and salesforce custom fields live.
Contextual tools: such as tables add rows.
Right side bar

*Docusign Fields: Fields that provide placeholders for user to sign the contract
*Salesforce Custom Fields: Fields that pull the data from Salesforce

1. Heuristic Evaluation

To get to know about Chorus, I started off by conducting a heuristic evaluation.
I went through as many features as possible in the current build of Chorus by following Nielsen’s Heuristic standards, Chorus Design Principles and DocuSign design principle.
Based off the issues I have found, I categorized them into bugs and design issues. This project helped me to set up a general understanding of Chorus.

2. Improving Document Importing Experience

During the heuristic evaluation, I found that the image and document icons were confusing for first-time users. After discussing this with the design team, we decided to improve the document importing experience. Another reason that we want to prioritize it right now was because there were some needs from the developer side of revising the uploading user flow.
‍
I identified several opportunities to enhance the document and image uploading experience:
1: Clarify the import icons to make them more intuitive for users.
2: Display success or error messages following document uploads.
3: Inform users about file size and format restrictions prior to uploading in the empty state.
4: Consider incorporating delightful moments into the design.

Original Document Uploading flow

UX Design reference

I talked with the engineers to understand the constraints of file uploading. The supported image formats are PNG, JPG, GIF, and JPEG, with a file upload size limit of 25 MB. PDF support is coming soon.
‍
To get some inspiration, I also explored the design patterns in other apps with editors, such as Evernote, Notion, and Grammarly. I noticed that when you open these three apps, they have very clear empty state designs. This effectively guides users through the process of importing files.

Opportunity 1: Clarify the upload signifier

Empty State Iteration Process Hightlights

Opportunity 2: Uploading Feedback

By Providing Success/Error message after uploaded a document, users are promptly informed of the outcome.

Opportunity 3 - Drag and drop and loading

Including the Drag and drop interaction for a more natural user interaction.
Taking consideration of providing delight moment in the design.

SHipped Design

I enhanced the importing experience by focusing on 4 key areas: Writing from Scratch, Empty State Iterations, Upload Success/Failure Notifications, and File Selection. I incorporated the file drag-and-drop feature and implemented immediate feedback toasts for file uploads.

Use Feedback

After presenting the design to the team and reaching a consensus, I conducted usability testing with 25 participants. The users were assigned with tasks, and all of the participants successfully completing the main task of uploading a document. They also provided positive feedback on the interface's clarity and found the instructions easy to follow.

3. Chorus Information Architecture

Learning from the observing people completing the tasks. I found that participants express the need to find the same feature in multiple places. This finding makes me feel interested to dig in more into the placement of each features to enhance the productivity of designing the Chorus editor.

|  How might we build a scalable system for the Chorus information architecture that will enable the team to easily incorporate new tools and features?
‍
|  How might we standardize what goes in the toolbar, left-side bar, right-side bar, contextual tools, and contextual on hover?

I also wanted to create something useful as a reference, so when we have future features, designers can refer to the guidelines to facilitate where to place them.

I started off by understanding the existing functions in Chorus by creating an information architecture of the current build. The current build consists of three parts left side bar, toolbar, and contextual tools (The team is expecting to make use of the right side bar for “comment” feature).

Information Architecture of Current Build

Card Sorting Workshop

To better understand the optimal placement of features, my mentor and I conducted a card sorting workshop with Chorus engineers, designers, and individuals external to DocuSign. We listed all the features planned for inclusion in the current and upcoming sprints, allowing participants to sort them in a manner they felt was most logical.

Takeaways from card sorting workshops

1. Users expect to see tools in multiple places. For example, comments in Google docs lives in both the toolbar and directly on the page – this is also a finding I have learned from the user testing
2. There’re lots of value in contextual navigation as it removes distractions and help user focus on the content
3. Most of our customers use MS word, so we want to bring a level of familiarity to the information architecture to make the experience less intimidating
4. Most people associate the right sidebar with comments rather than having an independent “comment mode”

Affinity Diagram

To further solid the finding into the making of information architecture. I planned out extra steps to best utilize the data from the card sorting workshop. I made an affinity diagram of all the features that was considered in the project scope. By following the card sorting result, I placed them into different area of the interface.

Final Information Architecture

Based on the information architecture I generated 2 type of outcomes

Outcome 1: Interface Proposals

Outcome 2: Flowchart for facilitating feature integration

key Takeaways

Working with the Chorus team was an incredible experience. This internship provided me with invaluable experience in designing for real products and offered the opportunity to collaborate with many talented designers. I learned that clear information architecture is crucial for tool-based products, particularly in the early stages. It not only helps in organizing the placement of existing features but also provides actionable insights for integrating new functionalities and interactions in the future.