Building profiles to make a better decision
GPARENCY is a membership-based commercial mortgage brokerage that aims to create equitable access to opportunities for commercial real estate (CRE) owners everywhere.
I was the main designer on this project ideating early concepts, presenting mockups to leadership and my team, and delivering final assets for development.
* The data listed on the cards are obfuscated figures and do not represent an actual property. All information on this case study is my own and does not reflect the views of GPARENCY.
When a General Partner (GP) wants to invest in a property, they want to be aware of all the property details such as property financials or sales history.
The data we provided on our property cards failed to provide enough context to GPs who are researching properties to invest in. Our users would leave for other competitors who may provide the data they needed.
We envisioned users would perform the two flows on our property card if they're interested in a property. However, we noticed that a majority of them would end up browsing instead of taking action.
There was a drop-off point at our property card that did not create interest for our users.
.png)
We wanted to address this by incorporating public data to create more engagement with our property card so that users were more likely to perform the desired flows and increase the likelihood of them financing a property with us.
.png)
The initial concept that we had for this feature was to create a separate page on our website so that users could view the public data on a page rather than on the property card.
However, our product team was pushing towards adding public data to the property cards so that users would not leave our product to increase their engagement.
Design viewed large amounts of data on a card to be noisy and would cognitively overload users with too much information at once.
We wanted to house the 40+ data fields on a separate page for various reasons:
(Design) Early concept utilizing a separate page to showcase public data
Our product team wanted to keep our users within the marketplace so they would constantly be engaged with our product.
There were some reasoning behind their thought process:
(Product) Early concept incorporating public data into our existing property cards
There were disagreements on how to move forward which led us to explore two design directions. The process led to productive discussions and resulted in a hybrid approach that combined both perspectives with compromises.
We incorporated most elements from both team's perspective:
After performing research on the data fields ,we categorized them under 5 buckets.
However, we realized this created clutter on the existing tabs.
We combined General Property into Listing to declutter the tabs.
.png)
To build trust and credibility with our users, I believed that adding a data verification notification would signal to users that the data we're providing is constantly being checked and updated.
In later iterations we decided to scrap this idea out as we did not have the technical resources to constantly verify the data.
To ensure that our cards were scalable, I created a separate section for address and property type so that our hero image was less busy and had more room for future features.
Iterations of our property cards into its final state
Our previous design had many issues that did not create a smooth and consistent experience as we were quickly adding new features as part of the launch of the MVP. We used this opportunity to make visual improvements by utilizing our newly built design system.
.png)
We maximized contrast by incorporating a green background to signify which tab is active
Icons & buttons were systemized and used consistent colors and styling based on our design system to create visual consistency
We utilized a mix of visual hierarchy, typography, and colors to create levels of importance with each section
To set our developers up for success I created vast documentation including writing design specs, creating screen flows, and organizing our Figma file.
Our developers were very happy as it addressed many of their questions from the start and they were always able to refer to the Figma file whenever needed.
.png)
Detailed design specs to ensure smooth development handoff
.png)
Screen flows to address "what if" scenarios & reduce back and forth communication
Unfortunately, my position was impacted by layoffs right after the release of this feature.
I was looking forward to hearing back from our users to see if this was going to be impactful and change how they use GPARENCY as part of their everyday tools when investing in properties.
It would've been great to see the data to provide us feedback such as seeing more users finance property with us or new users signing up to become a member.
These were metrics we could've used to define success:
Overall, I am entirely grateful to have worked on this feature as I believed this did address many business goals and user needs we were facing. I was very happy to hear that this was well received by senior leadership and my team.
