Building a Microsoft Word Add-In for DocuSign Document Generation
Timeline: 10 x 2 week sprints Role: UX/UI/IA Team: Product, Design, Research
The Problem
DocuSign currently has multiple products focused on solving customer pain points that begin with document generation: Gen for Salesforce, CLM, CLM Essentials + eSign. We have found that these silos no longer need to exist. Our long-term business goal is to create a Document Agreement Cloud, where clients can choose their own experience based on our offerings.
For this project, we want to create a standalone document generation feature that can plug into all of our current tools, while also working well with the range of templating tools our users take advantage of today.
The Information Architecture
As you can see above, each product line of business has a different way of generating a document. The important part to highlight is that we use different templating platforms (seen in blue).
The Existing Templating Solutions
The CLM (Core) Experience - In order to create the template, the user must first create a form. Each form item creates a merge tag. Once the form is complete, the user takes each merge tag and places it in the correct location in the Word Document.
The Agreement Cloud Editor - A homegrown templating tool, allowing users to upload a document and place data fields wherever they'd like in the document.
The eSign Experience "Tagger" - this templating experience allows the user to place pre-existing tags into their flattened PDF document.
The Facts
Two product lines use some type of Microsoft Word Templating Process, CLM and Gen for Salesforce.
There is a major lack of consistency across field types. i.e. merge tags, data fields, signature fields, standard fields, agreement data motel, etc.
We have products that are both self-service and professional service driven, which means there are some very complex use cases out there.
The Flow
The V1 Decision
As this is a visionary project with no stakeholders, our overall team started with some basic testing to understand the pain points of our users. Our team made the decision to test with the simplest use case in mind. That use case being, someone who creates a very simple agreement, such as an SOW or Offer Letter. After a lot of thought and discussion, we decided that our eSignature Template Builders were our ideal use case.
These users spend most of their time manipulating a document to add signature tags and create a template. We also know from Product that these users have been asking for a more “document generation” friendly experience, which is why our eSignature team has been testing a Gen for eSign Experience below.
The Research Goals
Project Goal: We are designing a universal document template creation experience in Word. We will do research with a variety of users and use cases. We are starting with research for simple document template creation use cases.
Outcomes for Phase 1: Research with eSign Users
Identify the needs of users creating simple document templates
Evaluate the concept’s usability for users creating simple document templates
Assess the value of the concept for users creating simple document templates
Identify any gaps or mismatches in the concept compared to the needs and process of users creating simple document templates
The Test Artifacts
The Design Recommendations
Product Alignment from all necessary teams (ADM, Essentials, CLM, Salesforce)
Gain analysis from simple templating research, and continue testing further
Understand how the Word Add-In can work with our Templating tools today
Examine more complex use cases (conditional logic, preview, storage, etc.)