Family Promise of Spokane
Recently I had the opportunity to work with the organization Family Promise of Spokane. Our team of four Web Developers and three Data Scientists had one month to lay the groundwork for a much needed web application for Family Promise of Spokane. Unfortunately the work our Data Science team did didn’t make it to front-end where I spent most of my time, so I can’t speak much on what they did.
An overview of our month:
The first week was spent on planning and understanding the project meeting with our stakeholder and discussing what technologies would be required. Our second week was mostly spent on setting up basic file structures and components on front-end , back-end began designing our data base. Since we were working with new technologies such as PostgreSQL we experienced some set backs. However; by week three we were able to connect back-end and front-end with most features ready to deploy. The first two or three days of week four was spent on cleaning up front-end and resolving any bugs before demoing our final product to Family Promise of Spokane. The remaining days were spent documenting and getting the project ready to handoff to the next team.
What is Family Promise of Spokane?
Family Promise of Spokane is an organization that helps prevent families from becoming homeless and help families who are already homeless by providing shelter options and the necessary guidance to get back on their feet and stay there.
Currently Family Promise of Spokane uses a paper system to check a guest into a shelter and keep track of their information in a filing cabinet. They then had to manually upload their information which was obviously very time consuming and frustrating for both the employees and the families trying to check in.
Our primary goal for the first release was to reduce the time for the overall intake process by creating a simple user experience and storing guest information in a database to replace the previous paper filing method.
Although our main goal was essentially setting up the different user types and having the ability to create an account for a family and view it, our original product road map also included additional features such as a messaging system and the ability to leave notes on each family. At the time I didn’t really doubt we would be able to accomplish these features in the given time frame (1 month) but I was worried that we would end up with several incomplete features from trying too hard to get every feature, rather than having some of the features user-ready.
My main role for this project was working on the form for the intake process and a profile to view the family’s information. To clarify, the intake process involves an employee, such as a shelter supervisor, sitting down with a homeless family and filling out a form containing some personal information for the family as a whole, as well as each member of the family. The original intake packet was provided to us via a PDF. I used the packet as a guide to design and create a multi-step form, which in my household, is now referred to as my “problem child.”
The problem child:
In our initial planning phase we had already decided to use Ant Design for our design guide. I’ve never worked with Ant design which wasn’t too big of a problem due to their beautiful documentation. However, I decided to do a multi-step form, as mentioned above.
Why? Because not every section would apply to each family, it would be more efficient to be able to easily skip entire sections. Plus, having too much on the screen at once can be a lot on an already frustrated and tired family. So the multi-step form was a must, but why was it my problem child?
Well you see, Ant Design has its own way of saving input values when the form submits. When a submit button is pressed it “submits”; this triggers any validation on inputs and sets the form state with its own useForm hook so it posts and persists properly.
The issue here is that I used a switch statement with a useStep hook to navigate through my form.
So rather than having a submit button, I had a previous/next button. This created an assortment of issues, but the big one was that I was unable to use the useForm hook Ant Design uses. I was still able to use a useForm hook, but it was unable to set certain field types such as the date picker and select component.
UseForm uses the name attribute to set state. Which usually looks something like this.
The name of course being the desired location in the database, in this case, the phone number for the first parent.
When I tried to set the state for the other input types I would receive an error declaring there was no name even if I had set the name attribute correctly. Unfortunately, I never did figure out what was truly going on. My team needed to be able to POST and start testing.
So instead of using setForm in the onChange attribute I called a custom function that used the input value when changed and manually reassigned the value in my state object to the input value.
Was it the best solution? I don’t think so, but it was a quick solution and won’t be hard to change for the next team. One day I will figure out why my child was acting out. I will say though, working with my problem child helped me really understand Ant Design better, so working with my other child (the family profile view) went quite smoothly. Don’t worry — I love them both equally.
The final product still needs some UX/UI love but is still a product I am proud of. Most of my time was spent on the intake form, but my other teammates were able to complete the following features after many sleepless nights and dozens of hours of Zoom calls just in time for the demo with our stakeholder.
- Create a supervisor/case manager/family account
- View family information as a supervisor/case manager/family member
- View individual members as a supervisor/case manager
- View list of members as a supervisor/case manager
- Post notes for a family as a case manager
- View profile completeness as a family member
We received great feedback and discovered we could definitely improve the current features but what we created was an amazing start. Unfortunately, our time is up and it’s up to future teams to develop.
The future of our product:
Our team was able to set the foundation for such an amazing project and I’m so proud I got to be a part of it. While our amazing and talented team did an excellent job, the journey for this project is just starting and has a ways to go before it’s ready. A few features that still need to be included for just the Intake include:
- Self incrementing case number for each family to guarantee case number uniqueness
- Auto filling and skipping certain inputs/sections to reduce intake time
- The ability to edit family profile information
There is so much you can do for this project and it’s for such a great cause I look forward to seeing where future teams will lead this project. Although my problem child may give them a hard time.
An opportunity to grow:
You may have noticed most of what I said focused on what I did and not so much on what we as a team did. It’s true, my team work isn’t what I thought it was. Although my team never said anything (honestly the sweetest team on the planet) I know I could have been more involved. Of course there were times that I worked with them but not to the extent I wish I would have. I admire my teammates and learned a lot from them. They impacted me more than they could know. Yeah I wasn’t where I wanted to be but by the end of the month I was way better than where I started. I pushed myself to be a better teammate and more helpful/involved and improve everyday. I am grateful for my team and this project. I will continue to grow and learn from this experience.
Thank you for taking the time to read my article! I would appreciate any feedback you have!