Redesigned a settings page to increase usage and add a new report type with no product design support. This feature is used by DocuSign administrators at big pharma and healthcare companies who need FDA approval to distribute and sell products, like vaccines. This project was really fun.
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.
Adding a toggle for the new report wouldn't help meet the goal to increase feature adoption:
- It's not obvious that a recipient is required to send the report
- To see the recipient list, you had to click “Manage Recipients” so it also wasn't obvious when recipients were missing
As a user, it would be really easy to toggle the report on first — since it's at the top of the page — then leave the experience alltogether without adding a recipient. And since the report cadence is monthly, the audience wouldn't immediately realize something was wrong. Then, once they got to the screen again to troubleshoot, they still may not realize that a recipient is required because the recipient list is hidden behind a modal that appears when you click “Manage Recipients.” Also, we don't mention it anywhere and the recipients section is secondary in priority on the screen.
After some discussion, the product manager and I decided to expand the scope — just enough to add customer and business value.
- Use an empty state to force folks to add recipient before they can ever turn the reports on
- Stop hiding the recipients list in a modal and add it as a table, first thing on the page
- Combine the existing report history table with the new recipient table to match existing design patterns in Admin — the screen would be too busy with multiple tables
- Revise the information hierarchy so that the recipient list is at the top
- Clearly communicate the conseuqences of removing the last recipient
- Turn off the toggle-ability of the toggles when folks remove all recipients
- Use a tool tip to communicate why they can't toggle the toggles
- Rewrite the descriptions to accommodate a few smaller (but important) content needs
- Clarify the purpose of the report to specifically call out Part 11
- Add a link to the help center as a resource
- Clarify report cadence and set delivery expectations
- Reduce the content reading level
- Fix terminology issues
Since this report is required to comply with FDA regulations and could affect approval for important things (like vaccines) and 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.
It took me about 2 hours to research comparable experiences in Admin and to produce my deliverables, from start to finish.
The design systems team that manages Admin for DocuSign has a pretty robust set of design patterns so I was able to move pretty quickly. I created a page for components specific to this experience, as well.
As a result of this work, the NPS for this product increased by 20 points and contributed to an 80% increase in usage. 🎉
These results made my day.
My first ever official product design improvement is also memorialized in the DocuSign help center. And that makes me feel nice.
- Validator for Life Sciences how-to video (skip to 1:41 to see my UI in action)
- Enable the Validator for Life Sciences Reports help article