Contract lifecycle module inside a legacy procurement platform
A new contract lifecycle module added to an existing procurement platform. The bet that mattered: treating negotiation as its own phase, not a second pass at authoring.
Figma
MiroRole and scope
I was the only designer on this module for its full twelve months, end to end. The CLM module is part of a larger procurement suite sold both standalone and as part of the wider Source-to-Pay system used by mid-market and enterprise B2B companies to manage supplier contracts.
My scope covered the full module: information architecture (dashboard, contract repository, templates, contract types, attributes), the three core flows (authoring, negotiation, execution), and integration with an external e-signature provider. I owned discovery, wireframes, prototypes, validation sessions, and design handoff. Decisions on logic and business rules were made jointly with the CPO, Solution Architect, and Product Manager — I prepared the design artefacts that those decisions were made against.
Context
The host product is a Source-to-Pay platform serving mid-market and enterprise B2B customers — primarily in procurement, with legal departments as the critical second user group for any contract work. Before this module, the platform had no real contract management. Customers used it for sourcing and procurement but moved out to email, shared drives, and Word documents the moment a contract needed to be drafted, reviewed with a supplier, or signed. The business case was to bring that work back into the platform.
The product is sold both as a standalone CLM application and as part of the broader procurement suite, which constrained the design: it had to feel like a coherent module on its own and like a native extension of the existing system.
Problem
The legacy approach customers were patching together had three concrete failures, all surfaced repeatedly across roughly ten user and stakeholder interviews:
No single repository
Contract drafts lived in inboxes and shared drives. The 'current version' was whatever the last person to edit said it was.
No distinct phases
Authoring, negotiation, and execution weren't distinct activities — just the same Word file passed around with different filenames.
Lost connection
Once signed, the link between the signed PDF and the procurement workflow that produced it was lost.
The first internal product framing addressed the repository problem and the signing problem, but treated negotiation as just another editing pass. That framing is what I pushed back on, and the rest of this case study is about why.
Process
Research
Interviews with current users and stakeholders, plus analysis of existing requirements
Wireframes
High-level wireframes and user flows prepared for working sessions with CPO, Solution Architect, and PM
Prototypes
Detailed prototypes reviewed with designers for UX critique and validated with stakeholders
Handoff
Internal team refinement pass, final adjustments, and design handoff
Authoring
For contract authoring, I designed for users to start either from a template or from a blank document, with all contract attributes visible at once on the form. Attributes were grouped — those groups being configured by an admin role I designed alongside the main flow.
Why not a wizard? Tested poorly with legal users — they want to see the full shape immediately and fill fields in their own order.
Negotiation
In the initial product concept, the flow was: author a contract → send it for approval → sign. Negotiation, if it happened, was assumed to be "the author edits the document again and re-sends." Mechanically identical to authoring.
What I heard in interviews and in stakeholder sessions with sales and customer success was different. Negotiation in the real world is the slow, multi-week part where the supplier marks up clauses, the legal team comments on the markup, the procurement owner counter-proposes, and three parties argue across email threads. Treating that as "another authoring pass" meant the module would solve the cheap parts of contract work and abandon users in the expensive part — the part that was driving them to email in the first place.
✓ Solution I proposed
External review inside platform, per-version commenting, visible version history
✗ Alternative rejected
Email-based review with re-upload — preserved the exact failure mode we aimed to fix
Execution
For signing, I designed the flow around an external e-signature provider rather than building a native signing experience. The decision was straightforward — legal validity of e-signatures is jurisdictional and the bar for getting it wrong is high — but the design work was in making the handoff feel like part of the platform: signers see the contract context they need, and the signed PDF returns to the repository linked to the original draft and its negotiation history.
Outcome
Full scope shipped
The full scope — repository, three-phase contract lifecycle with negotiation as a distinct phase, e-signature integration, admin configuration of attributes — went into the release. No major scope was cut between validated prototype and shipped product.
The negotiation-as-distinct-phase decision survived contact with engineering effort estimates, executive review, and the ship deadline.
Reflection
The strongest move in this project was pushing back on the initial framing of negotiation. The weakest one was not setting up instrumentation for the metrics above before launch — I was thinking about getting the design right and not about how I'd know, six months later, whether it was right. Next time I lead a 0-to-1 module, the measurement plan goes into the design phase, not after.
I'd also revisit the authoring form decision once there's data. Showing all attributes at once is the right call for legal users I spoke with; I'm less sure it's the right call for procurement managers who touch contracts occasionally. A progressive-disclosure variant for that user group is the first thing I'd test post-launch.