Introduction : 3 Step Divorce & Nolo
Inspired by the success of WillMaker online (read all about it here), the team at Nolo engaged us to enhance another one of their legal products. We were tasked to modernise a pre-existing legacy divorce product, and to apply the technical solutions from Willmaker to completely transform the user interface and experience, bringing it to parity with consumers of the 21st century.
3StepDivorce's mission is to provide an affordable and accessible solution for individuals seeking to annul their marriage on mutual grounds. The product enables the user to complete a simple guided interview that would ultimately produce documents that are legally compliant in court, thus easing the process of divorce.
In the beginning
With WillMaker Online successfully operating in all U.S. states, Nolo was eager to capitalise on this momentum and bring an enhanced divorce product to the market. Having ample experience with building complex questionnaires, our team (known as the codeRunners), was uniquely suited to rise up to this challenge. However, things were slightly different this time: the Nolo Divorce teams were new to the project. This meant that fresh relationships and unique processes needed to be fostered that would allow us to collaborate well with all stakeholders involved.
Scrum continues to be our preferred framework as it allows us to adapt to changing requirements. Additionally, we were able to prioritise features and fixes that were most valuable to our customers in a predictable manner. We believe that failing fast and learning fast is the lifeblood of building a successful product.
Once we had a clear understanding of how the teams would collaborate with and support each other, we proceeded to define the rest of the project's scope.
What were we trying to solve?
3StepDivorce prompts a series of accessible questions for the user to respond to. These questions are then converted into usable documents in court to facilitate the divorce process. In the United States, divorce processes and procedures operate under state jurisdiction.This means that all 51 states have their own unique set of regulations and the one-size-fits-all approach that was prevalent in the legacy product was suboptimal. The existing set of questions were too general to encapsulate the intricacies of state laws and regulations required to successfully file a divorce.
Another problem was that the purchasing journey and user flow were separated from one another, incurring overhead costs when the filing process was initiated. Clerks would have to reach out to customers to gather details that were not captured in the general interview, then manually produce documents that were compliant.
Additionally, adding or modifying questions in the 20-year-old portal was challenging in a world where family legislation is in constant flux. The interview UI was also in desperate need for a fresh take that would not only be relevant and scalable to users of today , but also easier to maintain from a technical standpoint.
It was clear that we needed to take a generalised interview and rebuild it to cater to state-specific laws. We needed to reduce overhead by automating and simplifying the end-to-end process, from purchase to court filing.
Setting goals
Having defined goals from the beginning is essential to kickstart a project well. We knew that we wanted to have an enhanced interview as the main goal, but we also needed a plan for existing customers on the legacy portal. The initial idea was to find the path of least resistance to migrate the forms in the legacy system over to the new portal. Our team performed an analysis to ascertain just how much of the code could be ported over to the new portal, while the editorial team focused their time and effort in writing the requirements for the upgraded questionnaire.
There was also a separate intent to migrate user accounts from the old system to the new one. We proceeded with an analysis to assess the complexities involved so we could make an informed decision.
With the design goal defined, there were 2 other goals to be understood. We conducted feasibility studies to ascertain:
- If legacy forms and user migration was doable.
- If setting up a new interview and diverting traffic to it was possible.
Defining our MVP
Like any other project, we needed to identify the scope of the MVP that was going to underpin the initial launch. After discussing and collaborating with stakeholders, we decided to select a state with high traffic volume and where the interview would encompass a variety of questions and complex logic to facilitate maximum learning and scaling to subsequent states.
A number of features were defined under the MVP scope. These included:
- The ability to divide the interview to chapters and subchapters.
- Integration with Google Analytics to track performance and areas for improvement.
- The ability for users to flag questions for later review.
- The ability for users to store their contact information and easily populate them in their interview.
- Enabling users to select dates from a calendar picker.
The purpose of an MVP is to build a product that contains just enough features to be usable by customers with the least amount of effort. It also provides an opportunity for us to learn and gather early feedback from users so we can adapt and improve quickly.
The ability to divide the interview into chapters and subchapters was a non-negotiable requirement. Another requirement specified the use of Google Analytics for tracking purposes however, we opted to use Sentry and Datadog, which are monitoring systems that were already baked into the current ecosystem. Since we were leveraging the existing application already built for WillMaker Online, this meant that we were able to integrate the contacts and calendar feature with little effort. The feature to flag questions was not pivotal to completing the interview. Therefore, we removed it from the MVP scope and placed it in the backlog for the next iteration.
This prioritisation process allowed us to keep the deliverable focused on a usable product while expending the least amount of effort.
Technical approach
As the editorial team fleshed out the requirements for the interview, uncertainty began arising as to whether the current infrastructure was robust enough to handle the complex interview scenarios. We decided to work closely with the editorial team to gain a deeper understanding of the product's needs, as well as to support them through the core functions and features of the interview. This not only enabled the editorial team to better focus on their output, but also allowed our devs the foresight to implement technical solutions that are reflective of the product's core needs and attributes.
Conversations around an independent and functional form builder type product were raised. This was also considered during the days of Willmaker Online because it would allow the editorial team to make adjustments on the fly. It became more apparent that a tool like this would be useful for Nolo in the future. However, both the editors and our business stakeholders were eager to see this MVP in the market soon. A fully equipped form builder may take years to build, so we needed a stopgap measure in the meantime.
The solution was straightforward, practical and effective. By creatively leveraging Google Spreadsheets, an already familiar tool to both the editorial and dev teams, we were able to make progress together with minimal time sinks. The editors would clearly input the questions followed by their expected functions and validations in the same row. The Technical Project Manager could easily identify a new or updated function or feature to prioritise in the backlog for the team. Additionally, because the team worked asynchronously with one another, the ability to track and comment on a specific item was invaluable. This also allowed for another layer of closer collaboration with our stakeholders.
Migration study
As mentioned, another one of our goals was to conduct a feasibility study to ascertain if forms and user migration was possible.
There were 2 distinct options to consider:
- The first was to migrate existing users from the legacy system to the new one. This would include their answers and account details.
- The second was to migrate the configurations in the legacy system's database. This included the types of questions asked, the format they were in and their accompanying labels.
Our feasibility study first looked into the migration of users. We found that this would be more technically challenging than its worth because the users' answers would need to be painstakingly patched into the new format. It would also be operationally cumbersome and time-consuming since consent would need to be obtained from these users ahead of the migration. Additionally, we were informed that a typical user's lifecycle on the legacy portal was relatively short, making the effort needed for a user migration impractical.
We then considered the possibility of migrating the forms. It was not a difficult task to perform from a technical standpoint. However, after discovering that the legacy forms were obsolete, we decided that it would be more sensible to create a new form in the new system. We redirected traffic to the new forms, allowing users to begin their journey anew.
Building the first state
The state of California was selected as our MVP state - relatively high in traffic volume and with the right balance of nuances within its interview questions to serve as the foundation for subsequent state-specific forms. The expectation was that future development iterations would scale and become more time effective through reused functionality.
We shared a preliminary version of the interview with the editorial team to provide them with a visual representation of the product. By believing in failing fast and learning fast, and through the iterative process of receiving and acting on stakeholder feedback, we were able to develop features that simplified daily tasks and removed impediments. We also made sure that the spreadsheets we were working on together were consistently user-friendly and that everyone understood the developments that were taking place.
How we operate
The time zone difference between our teams presented a classic challenge. To tackle this, all of the conversations and planning were managed asynchronously. The only exception to this was a weekly Scrum of Scrums meeting that took place at a time where the working hours of both teams reasonably overlapped. Conversations were held in public team chat spaces to maximise transparency and eliminate the risk of miscommunication. We practised clear and concise written communication so that there was little room for misinterpretations or misunderstandings.
On the other hand, we are adept at taking advantage of time zone differences and baking it into our processes. Feedback provided by the editors or QA team at the end of their working day would be picked up at the start of our own. Small changes would be addressed and ready for further testing by the following working day in the U.S. Additionally, deployments conducted during our work day was ideal as the non-peak hours in the U.S. helped to reduce the overall risk in case something went awry.
Setting a date
We believe that a data-driven plan is a well thought-out plan. We cannot predict the future, but we can make an educated guess based on the facts. With an understanding that there is a higher trend in demand for a product like this following the holiday season, our clients decided that the MVP should be launched after the New Year. This was certainly in line with their marketing strategy but it begged the question "would such a tight deadline be technically feasible?"
The answer was "yes", but with caveats. The scope of the MVP had to be guarded tighter than ever. It is always tempting to include nice-to-haves as product development matures. By managing our client's expectations and satisfaction around the MVP and future vision of the product, ideas for improvement were placed and prioritised in the backlog for a fast-follow.
With that, we were primed for a January 11 launch and all hands were on deck to make that happen.
Handling hiccups
By the end of December, all the pieces required for launching California were in place. We had a working interview and robust testing was underway. The team began spending time fixing critical issues, and were even looking forward to a couple of fast follow items that were scheduled for later releases. We also had a beta launch prior to this, with the intent of gathering as much user feedback as possible. All that remained was to implement another round of refinements. However, we encountered an obstacle. The questionnaires associated with WillMaker worked with smaller amounts of data, and typically contained less questions. With the divorce interviews, the number of questions were larger and our application was not optimised to handle such large datasets. Performance was subpar and we needed to get it optimised, and fast.
Our engineers assessed potential solutions to unblock the imminent launch and came up with 2 possible approaches. We could either segregate the interview into bite sized chunks so that our application wouldn't have to process all the data simultaneously, or we could rewrite our code so that it would be better equipped to handle larger datasets. With d-day on the horizon, we went with the option to segregate the questionnaire. The segregation of the interview was done on the code level and was not perceivable to the users, yet the performance improvements it delivered were instantly noticeable.
D-day
With the last batch of fixes going in, all preparations for launch were complete. On 11 January 2023, we met our goal and successfully launched the divorce interview for the state of California. New users were actively using the interview within 24 hours, marking an incredible milestone for Nolo.
Conclusion
This was only the beginning of our Nolo 3StepDivorce product journey. Through establishing a supportive, communicative and collaborative approach with our clients from the outset, we were able to continuously grow and strengthen our working relationship, even as new teams and stakeholders were introduced. By taking a data-driven approach to our technical strategy, we were able to learn fast and build a product that was scalable to our client's needs. Since the launch of California, we were able to increase the efficiency of development to new states by 70%. In addition, the robust and optimised system we built as a result of this experience has enabled 100% of new traffic from the legacy system to be diverted to the new interviews today.
