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.

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.

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!

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:

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.

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