A fun settings page redesign that lifted growth 80% and product NPS by 20 points

Context

The product manager for this project came to our office hours for content help. She wanted to rewrite three sentences and add another toggle for the new report. She had no product design resources to work on this project.

However, the scope was too narrow. The original scope didn’t fully consider the functionality of the setting and changing the functionality of the setting would have been a big engineering effort.

The problem? At least one recipient is required in order for the report to send, even if the reports are toggled on.

Let’s take a closer look.

Problem

The settings page had a structural issue. At least one recipient is required for any report to send, even when the reports are toggled on. The page didn’t make that clear.

Here’s what a user would experience:

1. Land on the page and see the report toggles at the top
2. Turn on a report (easy, prominent, top of page)
3. Leave the page without realizing they also needed to add a recipient
4. Wait a month (the reports are monthly) before noticing nothing arrived
5. Come back to troubleshoot, still not realizing a recipient is required because the recipient list was hidden behind a “Manage Recipients” button that opened a separate modal

The page never mentioned that recipients were required. The recipient section sat below the toggles with lower visual priority. The whole experience made it easy to activate a report that would never send.

Solution

After some discussion, the product manager and I decided to expand the scope, just enough to add customer and business value. Here’s what we landed on:

• Force the right order of operations. An empty state requires users to add at least one recipient before they can toggle any reports on.
• Surface the recipient list. Pull it out of the modal and onto the page as a visible table, placed above the toggles.
• Consolidate tables. Combine the existing report history table with the new recipient table using a tabbed layout, a pattern already established in DocuSign Admin.
• Restructure the hierarchy. Recipients first, reports second. This dependency is mirrored in the information hierarchy.
• Communicate consequences. Make it clear what happens if you remove the last recipient (reports stop sending, toggles disable, a tooltip explains why).
• Rewrite the descriptions. Call out Part 11 compliance explicitly. Add a link to the help center as a resource. Clarify report cadence and set delivery expectations.
• Fix terminology and reading level. Correct inconsistent terms and bring the content reading level down.

Since this report is required to comply with FDA regulations and could affect approval for important things (like vaccines), and the PM had no design resources, I offered to design the changes myself. I knew the design system really well and I love working in Figma, so I got to work.

The Admin design system had the patterns I needed — tabbed tables, empty states, inline toggles — so I could move quickly and stay consistent with the rest of the product. I built a components page specific to this experience as well.

Results

The full design took about two hours, including research into comparable experiences across Admin.

The empty state prompts users to add recipients before anyone can activate a report. This follows existing patterns in DocuSign Admin, so it doesn’t feel unfamiliar. I used DocuSign’s tabbed table pattern to keep the screen clean. The recipient list and report history share the same table area, with tabs to switch between them. I also built a components page in Figma for anything specific to this experience. The NPS for this product went up 20 points and usage grew 80%.

Design details

A few answers to questions folks may have.