Introducing Massive Sign

A product imagination that makes signature gathering easier.

Brief

This is a design challenge for KPCB design fellow. As applicants, we should choose one product from one company. And make improvement for this product via the power of design.

The product that I choose is DocuSign.

Mission

Send, sign and approve documents from wherever life takes you.

When I checked DocuSign’s website, the first thing that I learnt was that they really cover all the major areas already. They have multiple department and lots of clients. At that moment, I felt I was driving to Nevada from California: there is no way I can just climb those mountains straightly. I understood that I had to take a detour.

Screenshot from DocuSign’s website.

Fortunately, I found a way. Or, let’s say, I found a problem that can be solved.

The Problem

The current coverages of DocuSign can be concluded that they have two different modes: Sending a file to one or few people to obtain signatures; When you get a signature request, sign it. But, look at the first model, do I have to know all the recipients to get their signatures. The answer is no. Let’s look at some artifacts and scenarios.

Some Signature Forms.

What are those?

Sign in sheet at somewhere

Imagine that yall are stuck at the front door to sign your name on the piece of paper, but the talk that you’re about to join will start in 1 minute. What if there’s an application which could send your ID directly to the doorman even before you can get to the building.

Sign up sheet for something

Feeling touched by someone who’s giving free tickets to their shows in the park? Wait a second, they also ask your personal information for exchange. But your dog already started chasing other dogs.

Evil professor’s attendance sheet

Wow, you just never know when will you get the attendance sheet when you’re in the Math 101. Typically, there’re more than 100 students waiting for that moment to get maybe 0.5% of their final grade.

What are the pain points here?

An organization/individual that people don’t know. Typically, if you’re sending a file via DocuSign, the recipient can be your co-worker, your student, your potential client. You know each other somehow, before you agree on something. But here, people barely know each other since in most situations, they just met each other.

A long line is a significant pain point for everyone in those scenarios. The sudden boost will make people feel annoyed and prevent potential users from joining the process.

For the organizers, or someone who’s responsible for dealing with those forms, difficulties will show up at the end of the collection. It takes time to put all the names into digital forms. And the handwritings will be difficult to read. Thus, the error rate can be high.

DocuSign should do this, but why?

1. A lot of organizations such as non-profits, campaign runners, schools, event providers, may need this application to help them to avoid jam at the entrance, to make their input process easier.
2. The large user base out there could potentially help DocoSign grow.
3. From the user’s perspective, a simple solution will make them happy about the thing they’re joining and build a long-term usage with DocuSign.

What’s the solution:

By analyzing the pain points, I found some common requirements that appear in most situations:

1. How to shorten the time of operation. The goal here is to make sign in/up process as easy as other things that people do with their DocuSign.
2. How to prevent abuse of the system. The mission is to keep the signature gathering under the organizer’s control, which means, only the target user could be able sign.
3. Not just a signature. I’ve seen some sign up sheets, well, it’s better to call them questionnaires. They will ask you questions, for example, how many siblings you have, a question that will never appear in the user’s database.

Let’s go, technology!

The most doable plan I think, is the QR code. Comparing to other technologies, the QR code is easy to be generated, and cheaper. QR code is also easy to use. Each scan only takes one or two seconds. But participants only need a phone which has a camera on it. Combining with other technologies, let’s say, the Geo-location tags, organizers will be able to constrain the signature from specific area.

Introducing the Massive Sign

The ideal user flow:

In the idea user flow:

1. To start gathering signatures, the organizer has to prepare a formal document, just like they do in the normal DocuSign process. Then they will create a special case for the file, the Massive Sign!
2. Once the organizer creates the case, they will be able to generate their own QR code for that case.
3. Organize will go and put the QR code on things such as flyers, posters, even the projector’s screen.
4. Participants, just scan the QR code. If they’re sure about their actions, hit send. If they’re not, they can always read the document provided by the organizer.
5. Every item goes to the organizer’s database. So that brilliant organizer doesn’t need to waste his/her time on data input. The organizer will also have options to output the data to the other workflows.

Design Process:

Current user flow of DocuSign

Wireframes

A wireframe for creating a new massive sign task and generating QR Code.

Steps:

1. Users starts from entering a name for a whole task.
2. A lot of types of information can be collected. Each will take a box.
3. Upload a full document for the task. (Once the file has been uploaded, the file appears in the right column. Step.5)
4. Either choose from a single event or a series of event. The idea here is to create a bunch of events, which all use the same full document.
5. Users could drag the type of file from Step.2 and drop it to the corresponding position in the file preview area.
6. Hit save to save the whole task.
7. The system will navigate users to their list of tasks, where users could review all the tasks they’re running and generate QR code. By clicking on the “QR code” link, a new page will slide in.
8. Users could set a time to activate the QR code and a time to make the QR code expired.
9. Users could add a geo-location tag to validate the participants.
10. Clicking on the generate will generate a new random QR code.
11. Clicking on the QR code will give users the option to download.
12. Users could be able to download high resolution QR code which can be used in printed materials or low resolution QR code which can be attached to digital files such as email.

Test Reflections for Wireframes:

In the creating process:

1. The task — subtask model could not fit into the current DocuSign’s workflow, because in DocuSign, users could create a lot of tasks with the same document. And they have a validate solution, the template. So it’s really confusing with the multi-layer task.
2. QR code can be generated right after user created a task. In the previous wireframe, I cut the connection between QR codes and task because for one task, it may include multiple QR codes. But if we assign one task with one QR code, there’s no reason to ask the user to wait.
3. Then the settings for task (Step. 1 — Step.4) and settings for QR code (Step.8 — Step.9) can be gathered into one page.
4. The concept of dpi in Step.12 is really an unfamiliar thing for DocuSign’s users since they are not designers.

A wireframe for participants to want to sign a document via a QR code.

Steps:

1. Hit the camera button on the homepage could activate the camera.
2. Users could switch between two modes: the regular document scanner and the QR code scanner. The regular document (Step.2) has a larger boarder and an action button. Users can capture a series of pages. The previous taken pictures show on the left side along with the total number of pictures. The QR code scanner (Step.3) doesn’t have the action button since it always querying the camera’s active area.
3. Once a QR code is captured, the system reads related information.
4. Users could know what kinds of information is being collected by the task. They can either check the box (means, provide such information) or not (when the piece of information is not required). They can also learn the task’s name, description and the organization’s verification.
5. Users could review the full agreement and manually sign it (Step.8).
6. Users could also sign the document without checking the full agreement if they trust the organization.
7. A signed agreement will be provided to the users who signed it. They can go back to manually sign (Step.8) or send it directly.
8. When users come to the page, they will see a part of the document with a control panel, since the current files are too small. Using the control panel, users could enlarge the signature, slightly rotate it, and use thumbnail to navigate through the whole document. Yellow stickers tell users how many pieces of information have-not been checked. Users could click on the yellow sticker to navigate to the place that requires their action.
9. A confirmation letter will be provided to users telling them the summary of their actions.

Test Reflections for Wireframes:

In the scanning process:

1. Step.4 needs more information for users to make them believe they’re signing the right thing.
2. By clicking the quick sign button in Step.6. The system should navigate to the confirmation letter directly without asking users to review, especially when they trust the providers.
3. Rotate function can be rarely used since it only applies to the scanned documents that is not horizontally aligned. But most of files are uploaded to the system as pdf or other files.
4. To some degree, the thumbnail is overlapping with the reading area. It’s not necessary when the length of the document is small and the yellow stickers provide the same function of navigation.
5. Users get confused with the number inside the yellow sticker. Some of them believe that the numbers are index numbers instead of numbers of remaining box.
6. Step.7 provides the same function with Step.8 if the user signed the agreement fully. It can be removed.

Iteration based on the feedbacks, and the combination with DocuSign’s current themes

In the creating process:

The first three screenshots are a basic work flow to start a new task in DocuSign.

In the “Document” page, there’s a yellow button on the left side.

Clicking on the “new” button will activate a dropdown menu to ask the provider if he/she wants to build a new task, sign documents, or import from templates.

When the provider hit the “Send a Document” button, a setting page will be presented to the provider for them to upload files and configure details.

Here, I added a new tab right next to the “Add recipients”, since those two are quite different. In massive sign, the provider may not know the person who’s willing to provide his/her information.

On this page, user could get different settings for a Massive Sign task.

1. Project name and project description are required. Those descriptions could lead users to a quick signature, which means users skip the process of reviewing the agreement/document, and provide their information only be reading the name and description.
2. Providers could choose a data sheet for saving all the results. A data sheet can be as simple as a google sheet. It also can be a complex online database. Providers could also create a new data sheet using system’s template.
3. Two ways of verification have been provided to the providers. They can set a time and location to verify all the signatures and other pieces of information they could get.
4. Providers could hit the next button on the right top corner when they’re done with settings and document uploading.

On this page, providers will be asked to make the documents available to sign by dragging different fields to the document.

More importantly, they can choose or customize the type of QR-code that they wants to use.

A pop-up window will show up when the user clicks “go” button. On the pop-up window. Details about the QR code is provided. Providers can go back to change it if they don’t like it. By clicking the download button, this QR code can be saved to provider’s device.

Once the downloading process has been finished, the system will navigate the provider back to “document” page. Providers could be able to:

1. Click on the item’s name to modify it, or generate a QR-code again.
2. Review how many items have been obtained through the process.
3. Review if the QR code is still available.
4. View the data sheet by clicking on stats button.

In the scanning process:

Users could use the camera button to start scan their document/QR code immediately, rather than clicking on Sign and Send, and selecting camera on the sublayer.

Two tabs are available for users. The app goes to Document Scanner by default. And the user could switch to QR code Scanner by clicking on the QR code tab or swipe from left to right on the screen. The selected tab will be highlighted with an underline and brighter color.

In QR code, the active area of camera has been cut to a square to fit the shape of QR code.

A short introduction to the event, which has been entered during the creating process, will be presented to the user.

Users could use the check box to provide the corresponding information to the provider. If a required check box is left unchecked. The “authorize and send” button will be unavailable until the user checks that box.

A verification will be provided to the user to indicate that the organization has been verified by DocuSign, which means the organization is under the DocuSign’s user agreement.

If the participant prefers to read the whole agreement/document and signs it manually. This page provides a whole document. All the pages will be fit to the screen’s size. The up and down arrows on the bottom bar could help users to switch pages easily. And the yellow stickers show both what kind of information is needed and the number indicates how many boxes have been left in blank.

Finally, the user gets his confirmation letter by reviewing what kinds of personal information has been obtained by the provider. And now the user could show this to the provider. The provider could also get a new data entry at its back end.

Reach to the end.

In the end, I feel that this is really a good opportunity for me to break into an established product and think from the absent sides of the possible product. Although the design looks quite simple, but I found that in the back end, in the provider’s control panel, there’re lots of things can be done.

Also, as a designer, I thought a lot about the privacy issues like how to make the user trust the provider? how to help providers filter the information they need, and avoid spams?

Good luck to myself. And if you like it, scan the QR code in the design file for a surprise!