Complex Legal Contract Made Easy


A few months after joining the young startup, I had successfully led one of the two cross-functional teams (we launched a stable Beta).

Now, it was time to start building up the second team, and work with them to deliver the next big priority. The team didn't yet have a Product Manager or Front-end Engineer, and the Back-end work had been done ahead of time, so this was mostly a solo-mission at first.

For the later stages of this project, two amazing front-end engineers joined the project, as did our trusty Product Designer Ben Katz who contributed greatly to the Final UI through regular design jams and independent exploration, helping me apply and evolve the Design System to optimize the experience.


Investing in private funds requires filling out a Subscription Document. Ours was a 40+ page contract put together by our general counsel to cover all the requisite regulations and preferences.

We wanted to transform the process of filling out this complex, intimidating legal document into an extremely lightweight and informative product experience.

We needed to:
- Make completing a long contract a pleasant experience
Delineate quick wins vs. long term opportunities
Define processes for this new cross-functional team

Who is this experience for?

While several user types would be engaging with this, the focus was on Advisors in small practices, who had to manage all back-office tasks themselves, and typically had no experience with this kind of document before.

We aimed to make it feel not only tolerable, but empowering, so they would continue to utilize these kinds of investments more and more, across their client base.

Step 1: Analyzing the Contract

I started by diving into the contract. The legalese was strong, filled with caveats, references to sub-codes in the law, and complex asides and conditionals.

It looked something like this:
It was organized into sections based on the regulations that necessitated them. Similar or identical questions were asked in different areas of the contract, in different ways.

I started the process of re-organizing the information by affinity diagraming.

I went through the dense language and used a highlighter to surface the key concepts in each question.

Then, I cut out each question so I could physically group related questions together with paper clips, and then group by topic into folders.

Splitting Pathway by Entity Type

I noticed that the document had several sections that were only required for certain entity types. Individuals had to answer half as many questions as Businesses, Trusts, IRAs, etc.

The engineers advised us not to invest too heavily in dynamic flows based on every question, but it was clear that identifying the entity type up-front and narrowing the scope of questions from there would dramatically streamline the experience, and was worth the effort.

My hope had been to have one standard experience for advisors that felt familiar each time, regardless of what type of entity was investing, but since the questions were so different, I didn't expect to be able to.

I created a diagram to demonstrate how the first and last sections could be consistent for all, but we would need to split the middle part based on the two main types (Entity vs. Individual).
Even though it seemed the sections would have to change based on entity type, ultimately I was able to identify an overlap in themes, and make the section names across consistent for all entity types. Hurray!

Initial wayfinding approach

In the early wireframes, I was ambitiously planning to give every single page a title, so the users could get a quick sense of the nature of question they were on, or were about to navigate to.

However, it proved to be nearly impossible to boil down some of the concepts being asked about and redundant to the main question.

I realized not only was it difficult to condense the labels, but these labels were actually bogging down the experience, making it feel slower and heavier.

This is what that looked like:

Condensing similar questions
with simple Yes/No follow-ups

Some questions like "What is the investors name?" were asked multiple times, but from a legal standpoint, were technically different.

How a name appears on a tax return is not necessarily the same as it appears when doing business. If there were differences, we needed to collect them.

Instead of asking this similar question 3 times at different points in the process, I combined them into a single question, with follow-up questions, so that if the answer was the same for all 3, the user could click yes twice and be on their way.

Only if the user confirmed the name was indeed different, would we them prompt them to provide it.

Progress bar iterations

We didn't need to label every page, but we did want to give users a sense of what sections there were, as well as how far they had progressed.

Jamming with our other Product Designer, together we came up with a condensed style of progress bar that could appear at the top of the screen to handle this elegantly.
We were rather pleased with this direction, and while we expected it to be a light lift to implement, after reviewing with engineers, we understood that it would actually be too much work for the MVP.

In our discussions, one of the engineers suggested (s/o Jack Lynch) that we mirror a competitor who had an overview screen, that both revealed the user's progress and gave them the ability to dive in and out of sections.

We agreed this would make it feel much more flexible and lightweight, and less like a long, monolithic process.

We explored several variations on how this page could look:
Ultimately we devised a novel approach that felt friendly, simple, and very clear:
We also introduced a Review page at the end of each section, to give users a chance to check their answers.

This screen also enabled users to jump through the sections much faster when returning for another round of investments.
We mapped out the entire flow for each entity type in figma, mapped them to the API keys, and worked with the engineers as they utilized this same document to track system logic, UI variations, and implementation progress.

Zoomed out view:
Zooming in a bit to show variations and specs:


This MVP was a huge win for our ability to present as a tech-forward company, banishing the old way of filling out long contracts.

Users who tested it were easily able to navigate it. Internal stakeholders and external partners were inspired to see how simple things could be.

Demoing to potential partners who were well-versed in competitors resulted in fawning with comments like "this is by far the best version of this I've ever seen."

The project successfully:
- Illustrated to partners the superiority of our target experience
- Kept customers engaged
and excited about how easy things would be
- Enabled actual transactions
to be completed, with minimal manual work
- Identified and designed the future
enhancements, ready to go