Designed the digital contract experience, new to the platform, that streamlined client onboarding.
Customized the contract flow to handle multiple owners and their accounts, a case the platform’s standard contract patterns didn’t cover.
Designing interactive patterns for data-heavy information
Contract agreements used to move slowly, through manual coordination between an advisor and the operations team. A digitized contract surface sped up the process, with review and business logic built in. Minor variations across service types and business groups required design customization.
The contract surface inherited most of the platform's design framework, but one contract type was unusually data-heavy. The existing components covered standard forms and tables, but not the high-volume data entry these workflows needed. Bad data at entry fragmented the records and sent operations back to manual verification, the very work the tool was meant to eliminate. Accuracy at the point of entry was the whole point.
I designed this pattern iteratively, building buy-in across cross-functional stakeholders and the wider design team. The rest of this case study walks through that process.
The Work
Splitting a compound task
Digitizing the contract workflow meant accessing and retrieving datasets from data servers, so that logic drove every interaction decision. It was also the information operations teams looked at most closely when reviewing contract request forms.
The pattern required the requestor to enter multiple owners, each with several data sets, plus their mapped bank accounts, which risked making the task complex. To keep the form manageable, I split this section into separate steps, consistent with how the full four-section form was structured.
The design was reviewed and signed off with the PM and stakeholders.
Making a long table legible
The owner list could run long, so I capped the table at ten visible rows and added a running party count at the top, letting users confirm the total before submitting. The cap served rendering performance and scannability, and kept the page from turning into an endless scroll. The count is the subtler decision: a small piece of contextual guidance that lets users verify their work before it enters processing.
The list caps at ten visible rows to stay scannable; the user scrolls to reach the rest.
A running party count at the top right lets the user confirm the total before submitting, without scrolling back through the list.
Protecting data integrity at the point of entry
To protect data integrity, users could type in only genuinely new accounts; everything else was selected from records already on the platform. Since owner data already lived there and appeared on another surface, I pulled it from that source rather than have users re-enter it, keeping the data consistent everywhere.
Adding an owner: the user types a name and the system surfaces close matches to select from, so existing records are reused rather than re-entered.
Adding a financial institution to an owner; no match found, so the system offers an "Other" path to enter a new one. New entries are the only ones typed from scratch, which is what protects data integrity.
Adding a financial institution to an owner; a match is found and the user selects it.
An escape hatch for high-volume entry
Adding accounts line by line for every owner was heavy work, and a stakeholder had asked for a faster path, so we added an option to upload an account list. Spreadsheets were the tool finance users already reached for, which made an upload the natural fit. Reading unstructured files was technically constrained, so I worked with an engineer to understand what the parser could reliably read, then designed a downloadable template that structured the data for cleaner processing.
Left: the upload and download-template links, each tied to its action. Right: the upload window repeats the template link and instructions, in case the user didn't grab the template first.
Edge cases
Alongside the main flows, I designed the edge cases: what a user sees when an action falls outside the established business logic, and how the system reports partial failures after a bulk upload.
An added account breaks a business rule. The error state names the problem and lets the user download the file, correct it, and re-upload.
An account fails to add. The notice gives the reason and lets the user fix the entry and retry, or cancel.
Collaboration with Engineers
Once stakeholders approved and signed off on the designs, I reviewed the flow with engineers. We walked through the screens weeks before each sprint to confirm technical details and answer design questions, and the wireframes were attached to each Jira story. I also reviewed the built work in QA and production so every detail matched the design. Anything that didn’t align with the spec was resolved quickly or added to the backlog for a later update.
In the end, the design left a reusable pattern for multi-list data entry, applicable beyond this contract type.