content-design
How we planned strategic content pattern changes for a critical identity verification modal
For a critical Docusign Notary modal, I proposed two options for content revisions: the MVP and the fast-follow. Then, my PM offered me a seat at the table.
Context
This modal appears for notaries during an active remote online notary session. It communicates real-time identity verification results: whether a signer passed or failed, what to do if they failed, and why the notary should trust the results. The information needs to be clear and easy to digest during a live video call. If a notary makes a mistake based on bad information, the legal implications can be severe.
When I reviewed the designs, I saw opportunities to improve clarity and comprehension:
- Content patterns were inconsistent across the modal
- The information hierarchy made it hard to scan quickly
- Details that weren’t critical to the moment were taking up space
Solution
I proposed two options to my PM.
- Option A was designed to fit a smaller scope of work and could ship on time.
- Option B was a larger scope of work that we could plan out.
Drag to compare. Option A cleaned up patterns within existing scope. Option B restructured the hierarchy.
By showing two options, it was my goal to demonstrate why it would benefit the team to include content design in the planning stages for each release. At that point, I was still mostly working after product design was done and before engineering started their work. My goal was to get involved earlier in the project so that I could adequately scope and plan my work within the larger constraints of the project.
I designed the two-option approach deliberately. At that point, I was mostly working after product design was done and before engineering started. By showing what was possible within the current scope (Option A) alongside what we could do with more planning (Option B), I was making the case for including content design earlier in the process.The problem
Inconsistent content patterns. Information hierarchy that was hard to scan during a live video call. Critical status communicated only through an icon. Non-critical details competing for attention.
The result
Option A shipped first with cleaned-up patterns, accessible date formats, and rewritten error messages. Option B shipped in a later release with restructured hierarchy that led with pass/fail status in plain text.
Results
Both options shipped. Option A went out on schedule. Option B shipped in a later release, as planned.
More importantly: This strategy helped me persuade my product manager to include me earlier in the product development process, during the planning stages. 🎉
When I can scope my work alongside the rest of the team, it makes it much easier to manage a larger workload, plan for headcount, avoid burnout, and plan vacation time.
Before and after for a passing verification. The after version leads with plain-text pass/fail status.
The bigger result was the process change. After this project, my PM started inviting me to planning meetings alongside all of our engineering and design leads and PMs at the start of each new iteration of work. When I could scope my work alongside the rest of the team, it was much easier to manage a larger workload, plan for headcount, avoid burnout, and plan vacation time.
Both options shipped, and the approach changed how my team planned work.
Option A shipped on schedule within the existing sprint. Option B shipped in a later release. My PM started including me in planning meetings for every subsequent iteration.
Design details
A few answers to questions folks may have.
Why two options instead of one recommendation?
I wanted to show the PM what was achievable within the current sprint and what would be possible with earlier involvement. It was a way to advocate for a process change using the work itself as evidence.
What was the difference between the two options in practice?
Option A was a cleanup pass: consistent patterns, accessible date formats, better error messages. Option B restructured the hierarchy so the pass/fail result was the first thing a notary would read, instead of relying on an icon. Both shared the same error message rewrites.
Why does the pass/fail placement matter?
Notaries are on a live video call when this modal appears. They need to know instantly whether the signer passed or failed. The original design communicated that status through an icon, which is easy to miss when you're multitasking. Moving the pass/fail result to the first word of the header made it impossible to miss.