In this project, we designed a chatbot and here for our partner Homeline that would provide assistants to Minnesota tenants with these forms by guiding them through the questions and pre-filling the answers. As a collaborative project, I was responsible for the intro pitch, initial outreach to the partner, the coding portion for the initial prototype, and the implementation of five of the remaining ten forms, which were these forms: 1, 2 3, 4, and 5. Michael was responsible for later communication, the document creation for the initial prototype, and the implementation of the other five forms (which can be found in his project folder).
Tenants in apartments tend to have a huge variety of problems, and they often don't have a streamlined way to approach their landlords. Homeline has created a library of forms for those users to implement. The issue is that many people don't have time to sit down and print out a form to fill out and would rather have a version on their phone or laptop for on the go. The project aimed to address the needs these tenants who are in need but have no immediate access to printer or can't go to a physical location to request a form. Another aim was to streamline the process so that the partner can later add to their library using the same system.
The first sort of system that came to mind was QnA. This was one that we used in class and have some experience in. Other systems for this project that came up as possibilities were Google Forms or a more coded system, but with the already built-in functionality of QnA and our familiarity of using it in a legal aid context, this was the most reasonable choice. We also discussed our proposed plan with our partner and they thought that this sort of system would work well as well. There was also the research on how to make the program printer-free, where we found a service called Lob, but as mentioned later, it was something that would be tabled until after the product was deemed viable.
The biggest thing that was of concern was the ability to ask questions of the users and also use those answers to pre-fill forms. There was not much to play around with, and we quickly moved to apply our knowledge of document automation to mail-merging. Throughout the prototyping stage, a bulk of the time was needed to ensure that the code matched up with the mail-merge so it would populate the proper fields. The original prototype can be found here.
After this early stage of prototyping, we came to a crossroads on what to do. On the one hand, there were many forms that need to be implemented into the QnA system. On the other hand, the partners hoped to make it completely printer-free and implement some sort of API. Given time contraints and the more pressing needs of the system to be viable, the partners informed us that they preferred us to focus on the remaining forms and integrating them into the QnA. With this information, we decided on creating a centralized QnA program which would have all the forms available, and subsequently split up the forms equally.
We had two primary ways of user testing: testing by partner and individual testing. The feedback we received from our partner have been through email communication, which have been CC'd. Some of the user testing was in-person with friends and family, while most were done using Google Forms. The main issues that were brought up by the partner after the initial prototype were the lack of examples given to the user. There were also other issues such form fields not populating and forms not opening properly. The feedback from Google forms are collected here, which was mostly positive with some suggestions that did not take away much from their experience.
We used this data obtained from user testing to refine the product. For the feedback from the partner, we took immediate steps to incorporate those pieces of advice into our product. For example, concrete examples were added to the later version of the chatbot code. For the issue of non-populating fields and broken forms, those were issues on the code and integration process, which we fixed during the later stages. For the other testing, there was a selective process. Many of the feedback were merely cosmetic, and were not necessarily critical. In addition, many of the issues that were raised by the users were running against the limitations of the expert system in use, such as the changing of buttons, colors, and downloading directly as PDF. Several refined version of the product's code were improved upon and reshared with the partner: 1, 2, 3, culminating in 4, which is the final status of the project.
Earlier in the semester, we had to present a basic idea on the project and what direction it would possibly take. The intro pitch I made can be found here, which highlighted the goals of the partner, what steps would be taken, and future possible uses of the product.
This project made extensive use of two expert systems: the QnA system and document automation using mail-merge. Every form provided by the partner had to be integrated into the chatbot QnA, and the method of accomplishing that was having the various fields be populated by answers from QnA. With the initial prototype deemed a success, all of the other forms were coded into the QnA through various branches, and each branch had its unique mail-merge and document generation process.
This has a potential to make a significant impact to the partner's advocacy work. Right now, the forms relied on having a place to print them as well as needing to come in for personal consultation about the various issues. When this chatbot and the embedded document automation is implemented by the partner, the usage of the forms would be more far-reaching because it would be more user-friendly and take less time to complete. In addition, this would allow for more tenants to be assisted with the process of dealing with their issues with their landlord and apartment due to the automated process. While I am not sure how many more will use the product in the end, the potential has been increased greatly with the more streamlined process and time taken away from the physical, in-person asistance process that can be reallocated to further the advocacy.
This bot I believe serves the purpose of reaching the audience it was meant to. This was only meant to be for those in Minnesota in apartment with landlords, and the most common issues as well as some less commonly seen issues were covered by the document automation. If more is needed, it can easily be implemented to adjust for the added needs of the tenants and advocates. As I mention later, the partners have suggested some steps that may be useful for their advocacy process in the long-term such as an API and remote printing and mailing. Still, as it is now, the product is complete enough to serve all the needs that were addressed as needs by the partner.
There is a lot of documentation in the QnA itself as well as in my project folder. With all the refining of the bot, the language should be clear to all users, especially the partner, having added in examples as seen fit. In the beginning of the bot, there is a listing of all the possible user types who would use the system, and depending on the choices, they would be led through the prompts to reach the proper solution. This documentation always has room to improve, but as it is now, the partner understands the product and its uses.
The viability of this was highlighted in the partner letter that was CC'd to you. This more automated process saves costs for both sides, the tenant and the advocate. In its current state, the system would do its job more than adequately. Steps that the partner has indicated that could be in the horizon but not needed for usability include the implementation of an API to help the users print their documents remotely and send them to the landlords without a need to access a physical printer. In addition, the partner may decide to add additional forms to the QnA system in the future. Nonetheless, at this stage, it can likely be pushed out for public use.
This should be relatively simple to sustain. All the information needed to do so has been sent to the partners. The partner has expressed interest in keeping the project maintained, and will likely keep in contact somehow to gain more information if necessary.