Changing a product's design vision
✍🏼 Project
Redesign of the financial reporting tool of Your Porter App
👩🏼 Role
Product Designer
⏳ Timeline
8 weeks in 2019-2020
🎨 Tools
Sketch, Invision, Zeplin
Why I left my job at design agency
In April 2019, I left my job at an experience design agency to work at Your Porter App. By switching from working at a design agency to a small SaaS startup, my main goal was to focus on one product so that I can have more control and understanding over the whole experience of users while using a product; from the first screen they interacted with to all user flows they see, how they make payments, what kind of emails they get from the product company, what they see on the social media about the product and so on. I wanted to get to know the users better in-depth and measure the screens that I design on users’ experiences and businesses.
An overview of Your Porter App and Income Reports project
I started working at Your Porter App as the first product designer of the company. After the initial screen designs in the beginning, they had zero assistance from any designer and all of the additional screens had been designed and developed by the product manager and developer of the company. As a result, most of the screens were outdated, the language was very technical, and the user experience was not user-friendly. That’s why I had 2 main focuses while I work there: (1) redesigning the outdated screens and giving them a modern look, (2) designing new features in a user-centered way, and getting rid of the technical vibe throughout the app.
So the income reports project was critical since it was the first comprehensive project that I did to change the users’ perspective about Your Porter App from an outdated app to a modern-looking app with good UX. And personally, I enjoyed it very much since it was a project that combined my interests in mathematics, analysis, and presenting data comprehensively and understandably.
My role
As the only designer in the team, my role was to apply the whole user-centered design process from start to end. As the product designer, my role included user and market research, user interviews, user flow, UX design, interaction design, high fidelity screen design, prototyping, user testing, and working with the developers.
Outlining the problem
Income reports are one of Your Porter App’s most used features that collect financial data from different channels and prepares a price breakdown for users in an excel sheet form. In addition to that, users can also calculate a commission if their business models involve commissions to third parties. Although it’s a significant feature in terms of summarizing the financial data of users; due to some major problems, not all of our users could able to use it, even if they could use it, it was hard to get full efficiency out of it, and the users could need other tools to see their whole financial picture.
Getting started
Before I started to dig deeper into the problem, I talked to the product team, which constantly interacts with the users, and received information about users’ complaints and feedback about income reports. In the light of those feedbacks, I interviewed 6 important users who represent 2 major personas that our audience consists of. I examined the old income reports flow in detail, the business models, and the mathematical calculations behind them. Lastly, I analyzed all of our competitors’ financial reporting systems. Now I’ll walk you through each of these steps and share my findings and insights.
Why do our users not want to use income reports?
A screenshot of the old income reports.
1. The Income Report page was badly designed and not useful
The screen above was definitely not a screen that the users would be delighted to follow their income updates, because:
-
There is no clear hierarchy, and users can’t differentiate the most important items on the screen.
-
Again, because of the lack of the hierarchy, it seems complex, making it harder to understand.
-
The date filter is very limited. Users can only view their incomes by month. They cannot look at a specific date range. For example, they are unable to see their incomes in 2020.
-
The table format is not user-friendly. If you look at the reservations breakdown of a listing, the input columns are not aligned.
2. It didn’t include the business models of all our users
Let's examine Your Porter App's personas and their business models in detail to understand the business model scenarios of our users.
User personas
The users of Your Porter App are basically divided into 2 groups:
1. Homeowners
Homeowners are the users who manage their own places as short-term rentals. Since there is no one else between the homeowner and the guests, there is no commission calculation. All of the money from booking channels comes to their own bank account.
2. Property managers
Property managers are the users who don’t own the houses but manage them on behalf of the homeowners in exchange for a commission.
When we examine the users' business models for Income reports, we see that the business models of Property managers are also divided into two.
2a. Property managers who send payout to homeowners
The first group operates the houses, takes all revenue into their own bank account, and at the end of the month, they deduct their management fee and expenses and send the remaining amount to their homeowners.
2b. Property managers who invoice to homeowners
In the second group, all revenue goes to homeowners first; property managers invoice their management fees and expenses to their homeowners and ask them to pay.
So far, everything is okay. The real confusion starts with the variety of possibilities in the commission calculation. Because the agreements between every homeowner and the property manager are various, and finding an inclusive formula that includes all possibilities is challenging.
1
Initial screens are created by assuming that users receive commissions over the "Accommodation Fee" and "Cleaning fee". However, the users receive commissions on totals such as the gross amount and net payout, and accommodation fee.
2
The cleaning fee is never divided into a percentage in any case. Either all of them go to one of the parties or the totals, including the cleaning fee divided by a percentage.
In other words, the agreements that property managers do with their homeowners do not match the management fee calculation options that we offer in the report creation flow. This results in confusion and uncertainty for the users about the correctness of the calculations.
3. Users can’t keep track of the expenses
Although they can add extra items to the invoices, our system doesn’t save them in the database. In return, they can add an expense for one time, but the report doesn’t show the correct revenue since it only shows the revenue from the booking channel, not the spendings of users.
4. The interface design is outdated and uses wrong terms to describe business models
Both the report creation flow and the report itself are not very user-friendly. The report seems like an excel sheet. In the create flow, we ask the users if they pay a commission; however, the commission is not something our users pay to someone; instead, they get paid the commission. So there are these kinds of wording mistakes that mislead the users.
Competitor analysis
I examined 10+ competitors to understand where our app stands in the market. Most of our competitors don’t have a financial reporting feature, so it’s one of our competitive advantages. However, the ones that have reporting features are far more advanced than our tool. These are 3 major competitors who have a detailed financial reporting tool:
-
Guesty has a customizable reporting tool that users can filter their data from 65 parameters.
-
It allows commission calculation for property managers.
-
They have both a table view and graphics view for the users. In the former, the users can see detailed breakdowns, and in the latter, they can see the big picture as an overview.
-
The interface seems freshly designed and appealing.
-
There are many date filters such as monthly, quarterly, MTD, QTD, YTD, and custom date range.
-
There are export/print options.
-
Tokeet has an owner center where the users/property managers can see their income states and share them with the homeowners.
-
It has “Payout Rules” to calculate commissions, and these rules can be created over different channels, owners, or rentals.
-
It’s basically designed for property managers, not homeowners.
-
There are search and download options.
-
iGMS has transactions, reservations, and listings breakdowns for revenue reporting.
-
It calculates management fees by creating rules on properties and has 2 types of formulas: basic & advanced.
-
It shows the reports only in table format.
-
There are many filtering options.
-
Exporting the report is possible.
With this competitor analysis, I understood that giving options to view the data is very important for users. All the competitors have detailed filtering options both for the metrics and the date. An overview section is always nice to have to summarize the numeric tables.
User interviews
I interviewed 6 users from different countries who have different listing sizes to understand their business models. As a result of these interviews and my examination of our database, I listed some major business model use cases:
👩🏽🦱
“I own the places that I rent, so all the earnings and expenses belong to me.”
👨🏻🦱
“I get 20% of the gross income and send the remaining to my homeowners.”
👩🏻
“I’m a property manager and get 15% of the net payout without cleaning fee as management fee. I also pay for the cleaning fee. My homeowner collects all the payout and I invoice them my management fee, cleaning fees and expenses.”
👱🏼♂️
“We are a property management company. We collect all the payouts, deduct our management fee and cleaning fee, and send the remaining amount to landlords.”
The first round of design
I started by planning to design the create flow of income reports because I had to consider all the calculation options while designing them.
Main design goals:
-
Presenting all management fee calculation models to the user in an understandable way
-
Getting rid of the technical language on old screens
-
Making sure that the new model includes all of the old models’ user cases, so the transition to the new model would be easy
These drawings were my initial approach to solve the problems on the create flow. However, they needed improvements and iterations. What I changed while going from these paper-pan drawings to digital drawings:
1
At this stage of the project, my whole focus was to understand all management fee calculations. I was constantly doing calculations. In the first create flow draft I drew, I devoted 4 questions to understand the calculation model. However, this was too long.
2
After understanding all the scenarios, I decided to shorten this part and change some terms. For example: "paying commission" was a phrase we used in previous reports, but it was wrong. Property managers who use our app never pay commissions; they receive commissions.
3
After examining the first drafts with the product team, we decided to simplify the create form. In this direction, I decided to move the question of which data should appear in the report as a filtering setting to the income report screen. Thus, users would be able to make the data adjustments whenever they need them easily.
According to these wireframes, the report screen consists of two main parts. The first part is where the users see as soon as they open the report, “Financial Overview”. Users can determine which metrics they want to examine these metrics’ performance within the date range they choose.
The second part of the page is where I show the breakdowns of these metrics on the top of the page. There are two types of breakdowns; first, I show the listings breakdown of the metrics selected in the financial overview part. In the second tab, I show the breakdown of the reservations for the selected listings for those who want to examine them in more detail. The columns in these tables are variable according to the report data selected at the top.
After going through these first drafts with the product team, I started high-fidelity screen designs. Since it is a big job for the development side, we divided the entire project into phases. By taking out the options in the "Actions" dropdown to the second phase, we prioritized the change of the create flow and the improvements on the UI of the income reports before the functional innovations in the first phase. We started to make new functionalities as of the 2nd phase, right after the 1st phase.
As a result of these decisions, the following screens came out:
With the initial screens ready, I immediately started user tests to be sure of our 2nd phase decisions and prioritize the deficiencies.
I have also prepared an excel sheet for the developers to frame and ease the transition from the old system to the new system. In this sheet, I showed:
-
The equivalent of old income reports data in the new income reports data
-
What new data should be added to the database
-
An example of calculation for all business models
A sheet to show the correlation between old and new data to the developers
User tests and final screens
While doing user tests, I chose users from different countries with different sizes of listing portfolios. My main goal was to understand how clearly the users can communicate with the new interface and if there are any usability issues. For this purpose, I prepared a list of questions that cover the entire feature:
-
Can users complete the create flow successfully?
-
Do the business models in the create flow meet their needs?
-
Can they set the report data according to their needs?
-
Can they easily see the reservation breakdown tab?
-
Can they create invoice and payout documents?
-
Can they share their reports with 3rd parties?
And at the end, I asked for general feedback about the new UI and if anything is missing. (The last 2 items were already in the old income reports, we decided to improve them in the next phases.)
I made a task matrix for income reports and filled it after the interviews:
All users did the tasks well overall. However, there were some important things to note:
1
Although the business models we offer were sufficient for the users, and they could pick the model that fits them, this still doesn't prove that they are sufficient for everyone. So I need to keep asking this question in the future and make the sample size bigger.
2
The users liked the new UI in general; however, the terms such as gross amount, net payout, etc., were not clear to everyone. And the meaning of these terms might differ from one user to another. Therefore, I decided to add info tooltips to all overview cards, so the terms' definitions would always be accessible to users.
3
There were some missing data that we didn't calculate for all reports. For example, we were showing only the payout to the homeowner that our user needs to pay for the payout model. However, they also want to see what's left for them after the payout (management fee). Therefore I added new calculations and overview cards to both invoice and payout model.
4
For invoice and payout models, users could add extra items, such as expenses, before sending the invoice/payout statement to the homeowner. However, we were not saving them to our database, and after generating a pdf of the invoice, the extra items were getting lost. We decided to work on an "Expense Tracking" feature, where users can log their expenses in detail, add receipts and share them with their homeowners.
5
Almost all the users asked for a print or export option. So we decided to add it immediately to the next release.
The user interviews and tests made us realize the need for expense tracking as well. After finishing the first phases of income reports, I designed an expense tracking feature where users can log their expenses according to their reservations and categories. I added these expense data to the income reports too. As a result, we were able to show the whole picture to our users instead of a management fee calculation only. Both the property managers and homeowners can see the money they receive, the fees and expenses they have to pay/receive, and what’s left as revenue after all the operations.
Final thoughts
This project was very challenging in that there were many different scenarios involving mathematical calculations. It was about our users’ income, a topic everyone is too sensitive to and has no tolerance to see any wrong results. I have loved math since I was a kid, so I really enjoyed all the project’s mathematical calculations. This project taught me how important it is to be detail-oriented and have documentation, especially in big projects. And I still think that there is a lot to do to improve the final screens. Although they look fine to show the revenues that belong to a specific time period, there is no data to compare that period’s performance with other periods. There is no signal if the numbers are going well or not. I guess we can examine this in a different project. To go further and fine-tune the details, we need to have a solid base first. This project was a rigid first step to have modern-looking, easy-to-use features for Your Porter App.