A UX Case Study: Building reputation between Landlords & Tenants
Result of a real client project while at the UX Design full-time program at RED Academy Vancouver, Canada. Designing an app for the rental industry.
It’s January 30th in the morning at RED Academy. Both UX and UI classes get gathered together for the long-awaited assignment of a client. A real client. It’s exciting news but also a bit scary since we are going to have to put our best effort to design a solution for a real client. Not only for teachers to see but for an actual client outside the school. We couldn’t let him/her down.
After the instructors told us our respective teams (5 people in total), we got a client assigned to us. Along with 2 pages of information about the project, but we still had a lot of questions, therefore before the one-hour client meeting in the afternoon we had to prepare the interview script. We created 7 questions to get to know the person and 22 questions about the project. Then we decided who was going to ask what part and rehearsed it. We asked the client if he agreed to be audio recorded and after getting his “yes” we began.
The problem
One hour later and many notes took we had a better idea of the client’s needs and the scope of the project.
Our client was a man who had experienced problems finding a place to live when he decided to moved to another city in a different province. Because in the new city he didn’t know anyone who could vouch for him for a reference, he had no renting history, his reference letters from a place across the country were not credible. It was like starting a credit score from zero. That is why landlords preferred to give the properties he was interested to somebody in the same city. Which made him realize this could be a problem many other people face, how to build credibility when you don’t know anyone, and this how the client came up with the idea.
Also another strong motivator to kick-start his idea was his mother’s experience as a landlord, she experienced a lot of bad tenants, and he believes a tool like the one we were about to create could have solved his mom’s problem.
The Goals
- For tenants: Finding them a place to live and build their reputation.
- For the landlords: Finding them a good tenant, and also to get credibility.
- To create a platform where tenants and landlords can build their reputation, be seen as good people with more supporting documents besides recommendations.
- Bring a social feel to the rental industry, a community that everyday renters and tenants can utilize.
- A tool that will be accesible to everyone, firstly starting with Canada.
Research
After the brief with the client the 3 UX designers on the team, including myself, started working on the research phase.
There are many different methods of research but as a team we decided on surveys and in-person interviews. With surveys we could reach larger amounts of people, even from other countries; and the interviews would gather more qualitative data as people tend to talk more and give longer answers.
Surveys
We wrote the interview/survey questions from the exercise of answering 4 main questions:
- What do we need to learn?
- What do we know already?
- Who do we need to learn from?
- How do we reach these people?
The most useful questions were the first and last one.
From the first one we brainstormed all the main questions focusing on the ones for the landlords. Later on, we wrote the questions for tenants based on these as we noticed they could convert well with slight modifications.
The second question contained the answered from the brief with the client the day before.
From the third one we realized we could survey pretty much any landlord or tenant in the world because the information was still valuable.
Because we weren’t restricted to gather information from one region, we decided to post the survey on channels where a variety of people could see it. We decided on Reddit, Facebook, Craigslist, Twitter, WhatsApp and on renting forums.
The questions we created were also used for the in-person interviews. In total we interviewed 5 landlords and 5 tenants. The information we gathered from the interviews was saved for the next phase, coming up a bit below.
We created the survey on Google Forms with one screener question at the beginning: Are you a landlord or tenant? That way the person would be sent to the right path of questioning without having to look at the rest.
We posted the survey one night (we had about 15 responses an hour later), we went to sleep and woke up to 183 replies! which is a good thing, but also bad in that we had a huge amount of data to analyze. Immediately we stopped the survey from getting more responses.
Planning
Affinity Diagrams
Because we got 183 responses from the survey we had a challenge on the next phase, the affinity diagram, as we had to read all the data and analyze it. Then writing down in post-its only the main and repetitive answers, paste them on the wall and together with the UI design members conduct the silent 6-minute process of associating the post-its on inherent groupings. This is done without talking as to not interfere with other people’s way of processing the data. After the clusters of notes were made we could put a name to the categories:
Because we have 2 very distinctive target users we had to make 2 affinity diagrams. The affinity diagrams helps to narrow down key findings.
Key Findings
Some key finding we got from the surveys and interviews:
The tenants were mainly 25 to 34 years old (73 people) and only 6 people (from the 45 to 54 age range). Landlords were mainly 27-60 years old, they were young professionals and also there were families.
Tenants
An interesting answer from the tenants was to find out 100% of the surveyed people share. Seems like not many people can afford a place only for themselves.
From the next question we got insight into how much they use online tools, like the one we are about to create. The online classifieds are used 36.6 % of the time, which is a good amount of people connected to the tools available through the internet and possibly finding out about the Coyote app.
Landlords
Another question asked to the landlords offered us with information into how often they have a turnaround of tenants, in consequence how often the users would use the app.
From the question below we decided which documents the tenants could upload into the app, based on the 3 documents required the most by landlords: Proof of work/employment, previous landlords references and bank statement/proof of income.
User Personas
From this diagram the UX team was able to create 2 user personas. User personas are a representation of our target user. They are people designed as if they were real (meaning the name and pictures are invented), but with characteristics taken from real data.
Referring back to the personas during the whole process helps to design based on the users needs, not on the designer or the client needs, because after all the app is going to be used by the target users.
Minimum Viable Product
From the information of the affinity diagram and the client brief we could come up with the minimum viable product or MVP. That is the minimum features needed to deliver a usable product to the market in 3 weeks. Due to the tight schedule, some elements would have to be postponed. The following matrix was used to determine what items were important and urgent and which ones could wait.
Later on, based on websites that both landlords and tenants mentioned on the interviews and surveys to post vacancies or look for properties, we conducted a Competitive Analysis.
Competitive/Comparative Analysis
The purpose is to research other products that exists in this industry. We selected the ones people mentioned the most during the surveys and interview, plus an extra app we found out called Roomster.
A table was created to compare features that the app Coyote Rental Solutions would have versus the ones that competitors offered. It was revealing to discover that while many features already existed somewhere else, the rating system, the inclusion of bank statements and reference letters from employers weren’t offered by the competitors. Those could be our differentiators.
Scenarios
After, we created scenarios, short stories of a person who will visit a website or app with a particular motivation and goal in mind:
Landlord Scenario
Claire Wolfe is a married 41-years-old mom with 2 kids and a dog, who recently was able to buy her first house located in East Vancouver, using some savings and a bank loan. She needs to rent out the basement suite to pay off the mortgage faster and have some extra money for her kid’s future education.
Her job as a nurse in a nearby hospital is very demanding, thus whenever she has some time left, she prefers to dedicate it to her family. Because of that she is always on the go and trying to do as many things as she can on her smartphone during her work breaks or while commuting. Claire is tech savvy and has used Craigslist, Kijiji and Facebook to post sale ads in the past, but she would like something where announcements from different interests aren’t mixed together and she could just go an post her ads easily.
Tenant Scenario
Colin Musk needs to save money for a down payment for his future home. In order to save he needs to rent a cheaper apartment as his rent is very high. Although the rent is high, Colin is happy in his current apartment as it is in excellent condition and his current landlord has been fantastic. But Colin needs to find a cheaper apartment that is also is in good condition and the landlord is good to deal with, so he can put money aside.
User Flows
A user flow is a path taken by a persona to complete a task. It starts with an Entry Point, followed by a series of steps and ends with the Exit Point or completion of the goal. In this case we created an illustrated flow instead of text-only because it was more helpful to visualize the screens we had to sketch.
The user flow was iterated through individual sketching on paper and collaborative sketching on the whiteboard.
Design & testing
Sketch
The sketch phase started out as individual, later as a team we started adding and subtracting screens to the user flow on the whiteboard. Making annotations of the written content, deciding on button labels and which screens were Must-Haves and which ones Nice-to-Have, so we could prioritize those.
Design Studio
Interesting exercise where all the UX Designers sketch the same screen for 7 minutes, then present it to the others for 2 minutes and repeat. After some cycles of design studio the screens start looking alike, which means the people were taking elements from other’s sketches to make the best possible version, therefore reaching a consensus of the best solution for the particular screen. We used this technique to design the main screens, because the other ones had already been sketched on the whiteboard and approved by the group.
Paper Prototype Testing
After all the screens were sketched we cut them out and organized and called some people over to test this low-fidelity prototype. We tested it on 7 people which is a good number to get enough information to make changes, otherwise known as iterations.
Iterations
Based on testing we changed the labelling of some buttons to become more logical, created additional missing screens, moved the placement of the elements a bit, modified the body copy (written content).
For example in the image below in the far right, we had a screen for a property with a star rating system but we took into consideration that given the timeframe we had to work on this app we could not include a rating system for the properties too. We concentrated on delivering a Minimum Viable Product (MVP), therefore we left that out as an important but non urgent feature.
Also in the same sketch on the right side there is a button that read “I’ll take it”, but through testing some people commented “I’ll take it” sounded very final, if after pressing that button they were already committing to rent that place and they couldn’t keep browsing around the app for other properties. Therefore we decided to change the text to “Apply to this Property” which reminds the user of the real life renting process where a prospective renter has to submit an application form for the landlord who can decide who to choose among other applicants. This change in the wording of a button made us have to design some extra screens, for a path that we had not considered before: the interaction between an applicant and a landlord within the app. Because he applicant had to wait for the landlord to review his/her application and decide if accept it or reject it. So we had to design some extra screens: a screen telling the user his/her application had been sent for reviewing, later on a pop-up screen indicating the landlord had accepted or rejected the application and asking the user if he/she “Would like to go ahead with this property?, if the answer was “Yes” then another screen saying “You Got the Property. Please check your e-mail for confirmation” was designed.
Wireframes
Once we had all our sketches improved and decided, we brought them to the computer to create the wireframes, which shows basic structural design, in order to make a digital prototype in InVision for further testing.
Building Prototype
We created 2 prototypes, these are the links where you can see the interactivity:
Landlord prototype and another for the tenants.
InVision Prototype Testing
After we had this prototype ready we conducted more testing to keep improving the solutions. We got lots of feedback which we annotated to later make the modifications and keep enhancing the designs or the prototype, or both.
To this day we are still making iterations… but isn’t that what design is about?
Future Considerations
- Tenant & landlord profile reviewing/commenting.
- Pay your rent through the app.
- Landlords having to pay to use the app.
- Smart watch & VR capabilities.
- Implementing the star rating system for the properties as well.