Deppy App
The brief was for a multi-purpose app (mobile and desktop) for Tenants, Landlords and Lettings Agencies that allows tenants to pay a low insurance premium instead of a high deposit when renting a property. In turn releasing a large amount of funds that are locked up and unused in the UK economy.
Project Outline
To allow tenants to pay for a rental property insurance at a low cost rather than tying up large sums of money in a rental property deposit. The product would make the process seamless between tenant and landlord/lettings agency as well as being fully digital, cutting out large amounts of paperwork and processes along the way.
Initial Steps
It had to be considered that the app has two main users: Tenant and Landlord. However, the landlord may allow the lettings agency to operate on their behalf, also the lettings agency may want a record of the insurance in the absence of a deposit.
The app needed to be very user-centric and easy to use as some of the users might less tech savvy than others.
Each of the 3 user types also needed slightly different functions within their 'version' of the app. These being;
Tenant - Create account, apply for insurance, accept and pay, see records of insurance, make claim.
Landlord - Create account, manage property portfolio and insurance applications (accept, reject, amend), see records of insurance.
Letting agency - Hold records and potentially the same functions as landlord if managing properties on behalf of the landlord.
Research
The research process for this project mainly came from interviews with known renters and landlords as well as use of prior knowledge from being a renter myself.
One of the stakeholders in the project also had extensive knowledge of the processes currently in place when renting a property and was able to offer insight into the legal requirements of the process.
Some benchmarking of similar products on the market was able to take place in order to see firstly how they worked, as each had differences from each other, and also to determine what legal processes each had to action that Deppy would be required to do so as well.
Using a combination of these things I was able to push forward with a flow diagram of how the 3 ‘portals’ would work and how they would eventually overlap in order to reach the required outcome.
Each type of user had to have their journey developed separately from the others in order to maintain focus on that area and ensure that all aspects and requirements of their journey were explored in detail. This was important as the product was going to produce a legally binding document at the end of the process.
Once all three journeys were developed I then needed to work out how to combine those journeys at the relevant points to make all the processes work.
Due to the nature of the project I was unable to complete a wide range of interviews with potential users as the stakeholders were not in a place to allow such research to take place at this time.
Continued research on this project also covered the potential of add-on sale points for other products that would later be added to the Deppy portfolio, such as contents insurance for instance. However, the delve into this was short mainly due to myself highlighting that the stakeholders should focus at this stage on making this initial launch product perfect before spreading out into other products.
Design Process
Having the initial flow diagram of the app walk through in place then allowed the design process to move forward and firstly a number of low fidelity mock ups were produced in order to confirm that the flow diagram could work in reality with all the required buttons and navigation requirements in place too.
Following this I was able to digitise mid-fidelity mockups that took a user through the app in a controlled environment highlighting any stoppers in the process along the way. This feedback would then be taken into consideration and used to improve the design before being retested several times over to reach a point of satisfaction in the concept.
This project was very fast paced and I was working with the developer team from day one to produce outcomes. Most wireframing was a combination of my sketches and mid-fidelity mockups alongside open communication and annotated imagery to support my visuals.
At every opportunity needed myself and the developers would have ‘stand up’ meetings to work through the project.
This was particularly useful as we were developing both a desktop platform and an app side by side.
Stoppers
The biggest stoppers of this project was the restraints of it being classed as ‘low-key’ as the stakeholders didn’t want to announce to the world what they were working on at that time, limiting research sources. Another limit was that the market for such a product was very new so existing data wasn’t always available.
Both of these research stoppers as well as the fast paced nature of the project at the time were overcome with a lot of honest and open communication between stakeholders, developers and myself to reach any and all outcomes.
Outcome
A dashboard orientated desktop and mobile app, to suite all users, that displays functions based on the type of user. Therefore, decluttering the experience by avoiding the distraction of unrelated functions. A linear process for all users with limited offshoots, keeping processes clear and simple. Simplified navigation, with large, clear call to actions and easy to access data throughout.
An InVision prototype of the mobile app can be viewed here: https://invis.io/5QY187O3SHU
An InVision prototype of the web app can be viewed here: https://invis.io/K7Y1880BET3
