Sign
Turning static agreements into structured, lifecycle-driven workflows, with governance, multi-party permissions, and signing built in.
About the project
Sign is an enterprise agreement management platform for regulated industries. Teams create, approve, and execute agreements in a secure, auditable workflow, with identity verification, permission governance, and document storage built in.
My role
I worked on Sign as one of two designers, owning the end-to-end design of the core agreement workflows, from research and system analysis through to engineering handoff. Much of the work was translating fragmented, high-stakes processes into one coherent, governed system.
Design goal
- Reduce system switching across the agreement workflow
- Make permission ownership explicit
- Show every party an agreement's state, roles, and next action at a glance
Discover
I mapped the existing agreement processes as-is, tracing how documents, roles, and approvals moved between tools.
Research & Insights
Analyzed lifecycle complexity and governance gaps, and turned recurring pain points into design principles.
Concept & Design
Translated insights into structured agreement flows, role-aware permissions, and field logic, designed end-to-end.
Validation
Tested key flows with internal users across two sessions, iterating with product and engineering before handoff.
Research Approach
To understand where agreement workflows were breaking down, I analyzed the full document lifecycle, the governance structure, and how teams moved between disconnected tools. Direct access to end users was limited, so I leaned on the people and documentation closest to the domain.
Research methods
How I worked
As-is agreement workflow
How an agreement moved across fragmented tools before redesign, and the pain points I mapped.
Research process
How synthesis turned research into the core insights that shaped the design direction.
Key Insights
These insights shaped the core design principles and solution direction.
Insights
Stakeholder sessions surfaced that governance was unclear: access rights and approval ownership had no consistent visibility across the agreement lifecycle.
Documentation review showed static agreement formats were limiting automation and tracking, and slowing execution across systems.
Competitive benchmarking confirmed no existing contract tool combined lifecycle visibility with governance clarity, the gap Sign needed to close.
I structured Sign around six core modules: agreements, templates, documents, digital titles, notifications, and contacts. Each maps to a distinct stage of the agreement lifecycle, so the structure itself guides the user instead of relying on them to remember how fragmented tools connect.
Before & After
Three key changes — agreement structure, template logic, and document lifecycle.
Template creation
Before
Static templates with no conditional logic, set up from scratch each time.
After
Reusable templates with conditional clauses, dynamic roles, and automated dates.
Agreement creation
Before
No ownership or signing-order indicators, unclear who acted next.
After
Ownership, roles, and signing order visible at every step.
All Documents table
Before
Only Template and Agreement tables, no way to tell where an agreement stood.
After
Full lifecycle states (Draft, In review, Signed) with activity indicators.
Validation Approach
I validated each solution with product and engineering before development, testing key flows with 5 to 6 internal users across two sessions.
Methods
Tasks & Findings
Across two sessions, task completion went from partial and failed to fully passed.
| Task | Session 1 | Session 2 |
|---|---|---|
| Create a new agreement | partial | passed |
| Create a Digital Title template | failed | passed |
| Add fields and adjust view agreement | partial | passed |
| Find agreement by status in All Documents | failed | passed |
| Sign an agreement | partial | passed |
Key Findings & Resolutions
Ownership and signing order unclear.
I surfaced roles and signing order in the agreement panel.
Template creation too static.
I rebuilt it with conditional, role-aware configuration.
Document table lacked lifecycle visibility.
I added lifecycle states and activity indicators to the table.
Concurrent signing conflicts.
I redesigned fields and parties as independent records.
Impact
The redesign closed the core governance and execution gaps I found in research, tested with product and engineering throughout delivery.
Key Outcomes
Stronger governance visibility
By surfacing roles and status throughout the workflow, multi-party agreements became easier to coordinate.
coordination effortFaster agreement execution
Building templates and actions into the flow cut setup and approval time.
workflow speedImproved operational oversight
Lifecycle states let teams track active agreements and spot pending actions without chasing.
execution visibilityReduced execution risk
Making responsibility and confirmation explicit meant fewer approvals slipped through.
approval failuresProduct & Design Impact
I built lifecycle states into every stage, so teams could track progress without chasing status.
I replaced one-off templates with a standardized, reusable configuration model.
I brought coordination into the workflow itself, cutting reliance on outside tools.
I made ownership and signing order explicit, so teams could execute with confidence.
A few things that shaped the work, and what I'd approach differently next time.
Hardest decision
The trickiest part was field behavior. The same field could be editable, locked, required, or auto-filled depending on the user's role and the agreement's stage, and some fields carried built-in calculations. Turning that web of states into something predictable, where users always knew what they could touch, took the most iteration.
Constraints & what I'd do differently
With regulatory constraints and an early-stage product, I worked mostly through stakeholders rather than direct user access. It was the right call at the time, but with more access I'd validate the field and permission logic with real end users earlier, to catch edge cases before build rather than in testing.