Revolutionizing LP Agreements: A New Summarization Model Built with Cutting-Edge Internal Tools
Product Manager: Zeina Zeitouni (now Head of Product Management & Design)
Product Designer: Erin Lloyd
Supporting: (Product Design Manager), Mark Larson (Product Director), Cody Nevels (Subject Matter Expert), Rodolfo Bargo (Subject Matter Expert and APH Manager)
Status of project: Greenfield
Impact to the Business
Creating the first ever model for the Limited Partner Agreement, the most complicated model in our system, but also enabled us to open up a completely new market segment!
Another reason we created this form was to begin retiring the outdated wizard that processes the data used by our summarization team in the Philippines.
Context
The Limited Partner Agreement (LPA) is a comprehensive and detailed document provided by a venture capital firm to its Limited Partners—the high-net-worth individuals or entities they seek investment from. Filled with complex legal terminology and terms, the LPA includes intricate schedules that outline the terms and conditions of the fund, which must be agreed upon and signed by all participating partners.
By integrating the LPA into our app, we were able to distill and summarize the key terms, providing our venture capital clients with streamlined access to their data. This innovation also unlocked an entirely new market segment tailored specifically for Limited Partners. Although a separate team handled the development of this new offering, the data we ingested played a crucial role in enabling them to build and successfully launch the product.
Retiring the Wizard
The previous platform we were using for data entry proved to be quite rigid and inefficient. Its form structure was restrictive, making it difficult to input and manage data effectively. This was largely due to the fact that the platform was built by a third party, and the underlying code base was tough to work with, which made development cumbersome. As a result, our APH team faced a frustrating experience. To overcome these challenges, we recognized the need for a more flexible solution. We decided to build a new model using React, which provided us with the flexibility and customization we needed to streamline the process and create a better experience for our team.
Hypothesis
We can build out a simple and straightforward data entry form for our amazing analyst team in the Philippines, yet accommodate all of the complexity that the data structures would have in an Limited Partner Agreement.
Research and Discovery
Advanced prototype to test whether users understand form nesting.
- User Testing: Conducted tests with APH to determine if users understood how a complex nesting structure would be used.
- Methodology: Click through Protopie Prototype, Think-out-loud testing.
- Findings: Overall findings were favorable and we went forward with a nesting pattern.
I originally created this Protopie, however due to issues with the internet access in the Philippines and connectivity, we were forced to conduct a scrappy version of the test in Figma where we showed parts of the prototype in Figma and conducted a think out loud test.
One of the benefits of using Protopie was it allowed users to be able to type and click wherever they need to, which most prototypes are limited to. At this point in time, 2022, Figma did not have advanced prototyping functionality to allow for typing or the ability for users to click wherever. See the video for a demonstration.
Research Comparative Analysis
- User Testing: Conducted tests to compare summarization speed—one at a time vs. in tandem (for comparison). The need to determine if we should make this iterative vs. comparative as Engineering pushed back on a comparative approach, citing the lift would be considerable. We, in product worried that the Philippines team would be slowed down by doing an iterative approach, so wanted to test to make sure our decision was okay.
- Methodology: Google Sheets asynchronous test.
- Findings: Results were negligible in terms of speed. Operationally, the team found it easier to process the summarizations one at a time.
This resulted in a win all around as engineering advocated, Product listened, validated to prevent overbuild, and everyone is happier.
Comparative
Two users, Reviewer 1 and Reviewer 2, would work simultaneously on the summarization, entering data asynchronously. After submitting their summaries, the Quality Control person would review and determine the correct match, ensuring accurate summarization of technical legal data.
Lower fidelity version. This page is where all the sections are accessible for work and where users can enter each section to start.
Every section is broken out. Reviewer 1 has started.
All the sections are collapsed. Some of the sections have been completed; others in progress.
Reviewer 1, consisting of users JR and CB, has completed the first summarization. It’s common for one user to hand over the task to a coworker midway through a shift. This summarization is now locked for quality control.
Reviewer 2, user DT, is currently in progress, and we cannot access the summarization.
Reviewer 3, AK, is logged in and can view and continue their summarization. It seems AK has stepped out for a break or lunch and will return to resume.
Since the reviews aren’t finished, QC reviews remain locked.
All sections are now completed. We see how long they took to be summarized with the ability to go into each section and review each summarization for what reviewer put as their answer.
In the end, this felt too dark of a pattern, tracking how long summations. We also decided that three QCs were not needed and only one QC was needed in the end.
Iterative
In the iterative approach, Reviewer 1 reviews and locks the summarization. Once finished, Reviewer 2 reviews and completes their summary, then submits it to Quality Control.
Reviewer 1 has not yet started and can open the summarization. Reviewer 2 and 3 are locked and prevented from beginning their work. QC is also prevented from beginning their work.
Reviewer 1 CB has finished their work and the summarization has locked. The time has been recorded and now the Summarization for Reviewer 2 has been unlocked. Reviewer 2 can now begin their work. Reviewer 3 cannot begin their work until Reviewer 2 completes their work. QC is still locked as well.
What does it look like?
Whiteboards
Sketching and Whiteboarding
Click on each thumbnail to zoom in and see more detail.
Click on each thumbnail to see more detail.
Low Fidelity Explorations
Lots and lots of explorations around understanding the structure.
Something around meeting with APH weekly and the Subject matter experts to build the models by hand.
Engineering weighing in to make sure things worked smoothly.
See all the explorations in my Figma file here.
High Fidelity Explorations
Color is added. Structure is defined.
We ended up refining and getting clearer in our structures. We settled that APH would summarize one at a time. They would not need to have their summarizations broken up into clusters.
They did like having things color coded and nested. And the structure of the form was helpful in training them to use summarize. To see more of the final designs, see here.
Prototype
(Note, WordPress struggles with embedding prototypes and so I am just linking this prototype for now. Please standby for a better solution. The link is fully functional and will take you to the clickable prototype).
Takeaways
Impact
While the Aumni PH team could have successfully began summarizing the LPA using our newly developed form, they still preferred Google Sheets. Which, creates some process inefficiencies that in the end slows them down. As a Product team we are looking at CSV upload as a future efficiency saving opportunity.
The new interface however did pave the way for other forms within the admin interface, offering more flexibility in data structure and allowing us to build models more quickly. It also enabled us to efficiently perform complex calculations which was a huge benefit to out VC clients and our new LP clients.
Finally, the form played a key role in onboarding and training new members of the Aumni PH team. By guiding them to recognize key phrases and areas to focus on within the document, it helped them understand exactly what to look for during data entry, improve their knowledge.
The work we did allowed another team to create a view for Limited Partners and see a view of their Limited Partner Agreements.
What did I learn?
Developing a new data model is no small feat—it’s a complex and resource-intensive process that demands a significant investment of time and effort. From initial planning to execution, every stage requires careful consideration to ensure the model meets its intended purpose effectively.
Looking back, we realized that starting with a smaller, more manageable scope might have been a more efficient approach. By narrowing our focus early on, we could have streamlined development, tested key features more quickly, and iterated with greater agility. Sometimes, less really is more when it comes to tackling big projects.
That said, collaboration was a key part of the journey. We worked closely with the summarization team, sharing designs and gathering feedback at different stages of development. These conversations provided valuable qualitative insights that helped refine the tool’s features and improve usability. However, we also recognized that a more structured feedback process—especially incorporating quantitative data—could have made our iterations even more effective. Moving forward, balancing qualitative input with clear, measurable data will be a priority to enhance both efficiency and impact.
What didn’t work and how did we make it right?
The form initially faced significant technical challenges, causing major roadblocks in development. These issues were so substantial that the engineering team ultimately decided to replace it with a more efficient library. While this was the right call, it came at a cost—both in terms of man hours and development expenses.
However, this challenge also presented an opportunity for improvement. The second iteration of the form allowed for crucial UX fixes, streamlining the user experience and setting the stage for faster, more efficient model development in the future. What initially seemed like a setback turned into a valuable learning experience.
In hindsight, refactoring the code was a blessing in disguise. It paved the way for smoother progress and ultimately led to the adoption of a newer React-based form using Tailwind UI. This modern approach not only made the form easier to program and implement but also set a stronger foundation for future development. Interestingly, while the original code was eventually retired, its structure still lives on in today’s forms—a testament to its influence on the evolution of the system.
What would I do differently?
Right now, APH users have a clear preference when it comes to summarizing data—they rely on Google Sheets. Rather than using the form directly, a separate team steps in to copy and paste the summaries into it. This extra step works for them, but it’s not exactly the most efficient process.
The challenge is that while the form does support direct summarization, it’s simply not the go-to method for users. Whether it’s out of habit, ease of use, or workflow familiarity, they stick to what they know, even if it means adding an extra layer of manual work.
Looking ahead, there are ways to bridge this gap and make the form more user-friendly. Features like CSV uploads and automated OLTP could streamline the process, reducing friction and encouraging users to fully adopt the form. By making the transition smoother, these improvements could help integrate summarization more seamlessly into their workflow.