Structuring a Manual Contract Process
Streamlined contract initiation through structured request forms and optimized analyst workflows.
Reduced total processing and delivery lead time by 7+ days.
Enabled instant access to contracts at any stage for ad-hoc analysis or requests.
Decreased the time required for compliance, reporting, and auditing through automated validations.
Introduction
There was no digital version of the contract process. Contracts moved manually through account analysis, verification, and compliance review, expert-dependent work that was slow to service and hard to scale. Designing the digital contract experience from the ground up was the clear path to a sustainable, reliable process.
How I worked
On the first service agreement, the users were internal teams with limited bandwidth, so the PM and BA ran the requirement-gathering sessions and relayed the findings to me. As I designed later sets across different services, I had built enough familiarity with the workflow to work faster, and enough trust with the teams to join the sessions directly. Knowing the pattern, I could walk each team through it and ask targeted questions to locate where their needs diverged and how to customize for them. That familiarity became scaffolding: it let me ramp into each new service quickly and focus on what was actually different.
The Design Focus
I partnered with a PM to design both the advisor-facing and operations-facing workflows. The advisor initiates each service agreement through a long data-entry form, pulling client information from a separate profile surface. The form's four-stage structure, moving from basic to detailed account data, was an existing framework I inherited. My work was to build the data details into it, and as I took on additional service agreements, to decide how each new set of data grouped across those stages. I grouped by category rather than by field count: client information, service type, and fee information, so each stage held one coherent set of data. Each version was validated with the PM, BA, advisor and operations users before it went to build.
Image: On the review screen, recorded notes and attached documents stay with the request, keeping the decision context in one place.
The operations workflow centered on data review and a multi-step approval process before a contract was finalized. Reviewers couldn't complete a review in isolation: they needed to coordinate with other operations personnel and attach related documentation to the record. I designed the review screens to surface that communication and documentation alongside the data being reviewed, so the context for a decision stayed in one place rather than scattered across tools.
Working with Engineers
The design system was only partially complete, so I worked closely with engineering to carry designs through to production, specifying details down to font sizes and button placement. I developed screen-by-screen flows documenting interactivity and specs, and ran work sessions to review details, data, and flows together.
Image: Screen-flow wireframes to review with collaborators
Image: QA notes specifying design changes needed in the UI
Design System
To create new components, I aligned with the wider UX teams on interaction patterns and UI elements before partnering with engineers to build them.
Image: Custom components built for cases the existing system didn't cover
System Mapping
While designing the first service agreement, I began mapping the experience and data flows across the onboarding platform. Because several designers each owned a different surface, the map gave the team a shared view to align on the seams between surfaces, rather than designing in isolation.
Image: The system journey map, highlighting contract data and multi-user touchpoints