Skip to content

content-design

How content design changes cut errors by 43% and doubled feature adoption at DocuSign

I rewrote content and error messages in a DocuSign validation modal and doubled the success rate.

6 min read

Context

DocuSign had shipped a beta feature for real estate agents. To activate it, users had to enter credentials through a validation modal. This was the only way to access the feature, so the modal’s success rate directly controlled adoption.

We weren’t hitting our adoption goals, and an engineer flagged in standup that the volume of failed validation attempts was high. I wanted to understand why, so I jumped into my test account to troubleshoot.

Problem

First thing’s first: there were three versions of the same modal. We consolidated them to one.

But wait, there’s more:

  • The terminology was incorrect and inconsistent and incorrect throughout
  • The help link for finding your NRDS ID was nowhere near the relevant NRDS ID field
  • The “numbers-only” ID field accepted symbols and letters without complaint
  • There were zero inline error messages (users got no feedback until a toast appeared)
  • The toast itself was wrong: 500 error copy (“Unable to process the request right now”) was appearing for 429 rate limit errors

The 429 errors were the most common failure for this modal, and every one of them was showing 500 copy. Users who’d simply tried too many times were being told to try again because the server was down.

We were rate limiting people, then telling them to try again. We put them in 429 purgatory.

Solution

I pulled the error volume data from the engineer, put together a plan, and pitched it to our product manager. She said yes, the engineer said the scope was easy to manage, and we got to work.

Consolidated three modals into one. Three entry points had drifted into three slightly different modals. I unified them so the header matched the purpose of each CTA, but the content and structure stayed consistent.

Corrected the terminology. “Forms” became “Form Libraries” (the actual product name). I introduced “form source” to prepare for an upcoming release that would add more real estate associations. I verified every term by logging into NAR with my grandfather’s credentials (he’s a licensed realtor). The original modal used names that didn’t match what agents actually see.

Restructured the information hierarchy. Instructions for finding the NRDS ID now sit next to the NRDS ID field. The description leads with what to do and why. A new line under “Associations” clarifies that you need active membership for this to work.

Added inline error messaging. Users now see feedback at the field level instead of waiting for a generic toast.

Rewrote the error messages. I separated the 429 copy from the 500 copy so each error type described the actual problem. Previously, the most common error (429) was using copy meant for server failures (500), which made it look like the product was broken.

The error message rewrite had the biggest measurable effect. Once the most common error accurately described a rate limit instead of a server failure, users stopped assuming the product was broken.

Results

43% Reduction in highest-volume 429 errors
Validation success rate (doubled feature adoption)

Because this modal was the only way to activate the feature, doubling the validation success rate meant doubling adoption. The error message rewrite drove the largest single improvement, a 43% reduction in the highest-volume 429 errors disguised as 500 errors. The terminology corrections, hierarchy changes, and inline feedback closed the remaining gaps.

Two of three original modal variations, one showing a 500 error toast for what was actually a 429 rate limit
Two more original modals with inconsistent headers: Verify Your NAR Membership vs Add Credentials
Revised modal with inline validation errors for the NRDS ID field
Revised modal showing the new rate limit error message and a completed form
1 / 4

Two of three modal variations. The 500 error toast appeared for 429 rate limit errors.

Content changes alone doubled feature adoption.

The fixes were all content and information hierarchy changes: error messages, terminology, inline feedback, and a restructured layout.

Design details

A few answers to questions folks may have.

What was the timeline?

About a week from pitch to ship. The engineer said the scope was easy to manage. Most of my time went into the initial audit and terminology research.

Why were there three versions of the modal?

Three different CTA entry points had drifted over time. Each had slightly different headers, copy, and terminology. Consolidating to one version reduced tech debt and gave users a consistent experience regardless of how they got there.

How did you verify the NAR terminology?

I borrowed my grandfather's credentials (he's a licensed realtor) and logged into NAR to check the correct names for membership IDs, associations, and form libraries. The original modal used terms that didn't match what agents see in their own NAR accounts.