My contribution: gathering information, creating wireframes and prototypes, handling assets to developers.
Flatfair is a deposit alternative provider for renting a property. Instead of paying a traditional deposit worth 5-6 week's rent, with flatfair tenants pay a small, one-off check-in fee worth one week’s rent. Currently, extending the plan is very easy - agents/landlords only have to upload an updated tenancy agreement and provide a new plan end date. This is it. The problem is that this amount of information is not enough for flatfair to manage the risk of dealing with "Bad" tenants.
I was re-designing plan extension experience.
Collect more data during extension to decrease business risks. Capturing more information, especially the reason for the extension, is essential for solving the issues before the end of the tenancy and for having efficient communication with agents and landlords.
Educating agents on the best practices and solutions flatfair offers in case of increased risk during the tenancy. Flatfair offers various helpful resources and products for helping to solve issues with the tenants (when they stop paying the rent, etc). The problem is that not all of the agents/landlords are aware of that.
Initial research & workshops
In order to create a new experience, we had to analyse our current flow.
I noted the data that we currently collect from our users during the extension process. (It was easy to do because it was just a small modal. (See below))
2. I had a few meetings with the main stakeholders to gather the information that we need to collect.
The reason for the extension is unknown. There will be times where the tenancy is not extended but a tenant hasn't left the property.
Contact details of the tenant are sometimes outdated.
Flatfair doesn't know about the financial health of the tenancy (if there are rent arrears, etc.).
Some older plans don't have all of the referencing and guarantor information.
Agents/landlords have loads of information to remember.
Based on the above problems identified, I worked on addressing them by coming up with potential solutions:
Ask for the reason for the extension and customise the flow depending on it to make sure that agents are well informed to take any important steps to protect tenants and landlords.
Make sure that we ask for additional documents and up to date information in order to reduce potential future risks for the company.
Create a clearer visual form hierarchy by grouping related fields. It's even more important in this specific case since we will be adding some additional steps to the flow.
Make making mistakes more difficult for the agents by blocking them in the flow if necessary, showing clear error validation messages, guiding with notification boxes and tooltips.
User flows. I worked on user flows to make sure that all of the new documents and required steps are included in the new flow. I gathered feedback from the product team and the main stakeholders.
Basic wireframes. I quickly created some basic wireframes to establish the layout.
High fidelity mockups and prototypes. I started working on high fidelity mobile and desktop mockups to establish a visual hierarchy and layout for the charges creation experience. I worked closely with the end of tenancy and operations teams to make sure that all 6 different flows for different extension reasons include all of the required information and documents. After several feedback loops with the main stakeholders and product team, I iterated on my flow and created the final version to hand to developers.
Outcome and learnings
We started collecting more data as planned since agents and landlords can't extend the plan without adding additional documents and information. It should decrease business risks in the long run and decrease the time our customer support team spends chasing agents for missing information.
Create a strategic plan to launch an MVP and iterate later. This helps to deal with out-of-scope requests that could potentially delay the project and help deliver a quality product in time. Some of the improvements that we thought of later in the process should have been treated as future iterations. We learnt from it since including them into MVP delayed the development.