Docusign
Supporting Docusign’s
Global Community
DocuSign is the leader in digital signatures. When I took on this project, DocuSign offered few self-serve support options. There were only a couple FAQs buried on a subpage of the docusign.com marketing site.
In this case study, I’ll describe the planning and execution that went in to meeting the business goal of contact center deflection while meeting the customer needs for answers and education.
Role
- Coordinated with UX Research team to gather insights
- Worked with Product Management to gather and prioritize requirements
- Led the design of the support and community sites
Process Overview
1 Strategy
Project context and origination.
2 Discovery
Evaluation of Product Analytics and customer interviews.
3 Design
Wireframes, layout iteration, and final designs.
4 Outcomes
Evaluation of success metrics, driving customer behavior changes.
5 Learnings
Content creation, internal and external customers, scoping challenges.
1 Strategy
The self-serve support experience for the DocuSign platform was poorly planned out, hidden on the marketing site, and organized by internal business units not familiar to the customer.
We had a strong set of business goals that initiated the project including
- Identifying deflection opportunities: Finding ways to get customer’s questions answered before they have to contact DocuSign’s call center.
- Entitlement based routing: Increasing the call center’s efficiency by cutting down on the amount of time it takes for agents to establish the support level tier, let alone start solving customer problems.
- Localization: Enabling support for all languages the product was available in.
Previous support experience
2 Discovery
With clear business goals we started discovery to understand customer goals.
Evaluating product analytics
We started by evaluating product analytics to understand how customers were using the current experience. The main finding was that, overwhelmingly, the customer’s first action was to search. They had clear questions that they wanted quick answers for and they didn’t want to hunt and peck for them. Customers generally were only browsing when they couldn’t find the search results they were looking for.
Another finding was that although the design allowed a customer to browse by product, in analyzing search terms we realized that customers didn’t think that way. They were browsing by topic.
Interviews with target personas
DocuSign had a rich set of personas and we identified four personas to address with this project.
- Customers that needed information on signing documents
- Customers that needed information on requesting signatures from others
- Account administrators that needed to understand admin features
- Customer support representatives
We did a series of interviews with individuals that fit each persona. The two main topics that came up were:
- Customers couldn’t find support information so had to call the Customer Support center which was time consuming and not always convenient for them. There just wasn’t a lot of support content available and the search not specific to support, but was a global marketing site search, so results were not meaningful to customers.
- Case management was poor for both customers and agents. When a customer contacts the Customer Support center with an issue, a “case” is created. Once a case was created, the customers felt they had no visibility. For the customer this caused frustration. People told us they didn’t think DocuSign was being responsive, and there was a lot of back and forth churn as customers tried to understand what was going on with their case. For the business, this drove up contact center volume as customers would contact customer support to try to understand what was going on with their cases. Agents were swamped just answering calls and emails telling consumers their cases were still be actively worked on.
3 Design
Wireframes
So how did we address these findings?
- First and foremost, we separated the Support Center from the corporate marketing site. This allowed for an easy-to-remember URL for customers to visit when they had questions. It also allowed for a search dedicated to support topics making search results much more relevant to customers queries.
- I made search the prominent feature on the page and added a section of top FAQs. These FAQs are dynamic based on popularity, but also the user’s role. For example, if a customer is logged in and has a signer account, this section is populated by questions about signing. If the customer is an administrator for their company’s account, this section is populated by questions about account administration.
- We still included the browsing options, but created topic groups and moved them to a more prominent place on the page above browsing by product.
- Lastly, we added visibility into support cases. Instead of guessing or digging through emails about the status of their case, the customer could come to the support center, see the status, and add or edit information.
(Wireframes are intentionally vague to protect confidential information)
(Wireframes are intentionally vague to protect confidential information)
Design Iterations
I built a simple clickthrough prototype for testing. Our UX Research team did a round of usability on this prototype and based on the findings we did a few iterations to the layout.
- One change was to add a hero section at the top. This was because customers were flipping back and forth between the product and the support center and this hero panel gave them a big visual cue that they were viewing the support site.
- I kept search in a prominent position as this continued to be the most used feature.
- Lastly, in the initial wireframes Topics and Products were in list format. This pushed a lot of browsable categories below the fold and required a lot of scrolling. I switched the design of Topics and Products to a grid and created icons for each. This incorporated more content above the fold and made the easier to see in a single glance. These icons propagated throughout the site making wayfinding easier for the browsing customer.
Final Design
DocuSign has a very strong Design System (thanks to the detailed work of Brian Baer) and I utilized as many existing components as possible.
I quickly realized that the Design System was developed for the Product and was missing important elements that were needed for this Support Center.
I worked closely with both Brian (the Design System lead) and the front end team to identify, define, and design these components. Any new components were reviewed by the Design team so they could provide feedback and so that we could develop best practices for their use.
4 Outcomes
Log in
+4.1%
Search
+16.2%
Top articles traffic
+2.5%
Contact us traffic
0%
Self-service customer support deflection
+176%
The UX and UI changes drove behavior change. Customers were more likely to log in so they could see their cases and receive personalized information. They were more easily able to search and find relevant articles quickly. And importantly, none of the changes increased traffic to the Contact Us page, which addressed our top success metric of contact center deflection
Overall, we were able to increase deflection rates from 13 to 36% which had a positive effect on our ability to scale the business without scaling our Support team.
5 Learnings
Content
As I stated at the beginning, there wasn’t a lot of content to begin with. We needed to introduce enough content to make a support site meaningful as well as organize it in such a way that it was easy to search and browse. We were able to engage the Customer Support team and the DocuSign University training team to help us not only write hundreds of articles, but also use their knowledge of customer questions to organize them into meaningful topic groups.
Internal Customers
When including case creation we had to really understand not only the needs of DocuSign’s external customers and partners, but the workflow of our internal Customer Support team. We needed to design case management for customers in a way that didn’t result in a lot of new training for agents and didn’t disrupt their workflow and efficiency.
Importance of a properly scoped MVP
And, lastly, make sure the most important features and functionality are addressed first in your MVP. Budget cuts forced us to scope down our initial feature set, but careful scoping and prioritization allowed the project to still be successful.
Building, growing, and leading product design teams that create great customer experiences by understanding the complex relationship between design, business, and technology.