ThinkEmpire Payment System
︎︎︎ SaaS product design
︎︎︎ strategic design
︎︎︎ UX case study
︎︎︎ strategic design
︎︎︎ UX case study
Designed a payment infrastructure and checkout flow to facilitate the in-app purchase feature for the ThinkEmpire app from discovery to delivery

Role
︎︎︎ product designer
︎︎︎ product designer
Time
︎︎︎ Feb. - Apr. 2020
︎︎︎ Feb. - Apr. 2020
Tool
︎︎︎ Adobe XD
︎︎︎ Adobe XD
Discipline
︎︎︎ digital product design
︎︎︎ digital product design
Collaborators
︎︎︎ worked with three engineers, one project manager, and two executives
︎︎︎ communicated user research findings with the team to ideate the feature and drive impact on the final decision.
︎︎︎ worked with three engineers, one project manager, and two executives
︎︎︎ communicated user research findings with the team to ideate the feature and drive impact on the final decision.
︎
Project Overview:
Objective
To fulfill the monetization plan for the ThinkEmpire product, the team had to design and build out a payment system in the app. Since we had to have a monetization option up as soon as possible, we decided to move on with two phases of implementation for the payment system.Deliverables
In this project, I was responsible for the UX/UI design, from defining the problem to deliver the hi-fi prototypes and developer handoffs.Challenges
For this project, we needed to choose an external payment platform and design based on the documentation it offered. Besides prioritizing features included in the first stage of implementation due to confined time, we also needed to make sure it would be simple to extend the construction from phase one to phase two.Outcome & Impact
The team built out the in-app purchase function with a reusable payment module for the most demanding feature in a month. On average, we ended up having a 20% growth rate of transactions in three months. We received a lot of positive feedback from both users and stakeholders.**
Research Methods: stakeholder interview, user interview, requirements & constraints gathering, content audit, competitive analysis, design review, prototype testing & feedback
**
Deliverables: user-flow charts, wireframes, hi-fi prototypes, developer handoffs
︎
Background:
ThinkEmpire is a SaaS product providing comprehensive commercial real estate data for NYC. It offers an advanced search feature that allows users to search by property or people based on dozens of criteria. Besides, it presents a visual CRM for users to keep track of people and properties with which they have interacted.
![]()
When I joined ThinkEmpire, I started with redesigning one of the three main panels of the app and the advanced search feature. At the same time, I initiated the build for a design system to bring consistency of visuals and interactions to the user experience throughout the whole app. Then, I completed the design for features including list view redesign, login/signup system, onboarding tutorials, feed for social posts, maps, listings, user profile and settings, and downloading lists as CSV.
Design System
While the app had many useful features, we had not designed and implemented any system to monetize the service we provided. Therefore, we would like to build out this payment system as soon as possible and simultaneously create a thorough version with a pricing page and a billing tab within user settings.

When I joined ThinkEmpire, I started with redesigning one of the three main panels of the app and the advanced search feature. At the same time, I initiated the build for a design system to bring consistency of visuals and interactions to the user experience throughout the whole app. Then, I completed the design for features including list view redesign, login/signup system, onboarding tutorials, feed for social posts, maps, listings, user profile and settings, and downloading lists as CSV.

While the app had many useful features, we had not designed and implemented any system to monetize the service we provided. Therefore, we would like to build out this payment system as soon as possible and simultaneously create a thorough version with a pricing page and a billing tab within user settings.
︎
Process:

︎
Stakeholder Interviews:
At the early stage of this project, I had several meetings with stakeholders to identify the core problems and get a sense of their expectations for the project timeline.
- They wanted to have a payment system implemented as soon as possible
- Eventually, they planned to apply a subscription model to the app.
︎
User Research:
To understand what current features users would most likely to pay to use, I conducted a user survey and figured out that these two features were essential to them:
- Downloading a list of properties or people as a CSV file
- Looking into a property owner's contact info
︎
Opportunities:
- How might we combine existing features with the payment system so it could be up in the app as soon as possible?
- How might we incorporate the subscription model with the payment system into the current user flow?
︎
Requirements & Constraints:
Limited Time
Given a tight time frame, the team decided to separate the two opportunities into two phases of design and implementation. First, we planned to start by adding an upgrade option to the most demanded feature, exporting CSV. Then, we would expand the whole payment system with a pricing page for subscription plans and a plan and billing info section on a user's settings page.Technical Requirements
To set up our payment infrastructure, we had to use an external API, and thus, we had to design our user flow and interface based on the style guide and features listed on the API doc. We also had to gather the required info from users to accept a payment.︎
Goals:
Since we decided to move on with two phases of implementation for the payment system within a limited time frame, our goals for each stage were:
Phase One
Phase Two
Phase One
-
Provide in-app purchase for more CSV exports with property owner's contact info
- Create a basic checkout flow that is extendable for phase two design
Phase Two
- Based on the checkout flow from the first phase, integrate an upgrade option with different tier plans to unlock more features
- Add a pricing page with details of all the subscription plans
- Include a plan & billing section to a user's settings page
︎
Principles:
I followed these principles while I was designing the payment system:
- Consistent - The payment system design should utilize the components and style guide from the ThinkEmpire design system. Therefore, users can have a consistent experience across the whole app.
- Mobile-friendly - Although most of our users use our app on their desktop devices, the user interface should be accessible and user-friendly for different sizes of screens. I always design with a mobile-first mindset.
- Expandable - While we would have two phases of implementation for the payment system, we had to make sure users would not have to spend time getting used to the new user flow after phase two development. We wanted to ensure that the user experience of upgrading is expandable, both design-wise and technical-wise.
︎
Design Deliverables:
*All numbers on the UI Screens are placeholders.
Phase One
While designing, I had to make sure that we could reuse the payment/checkout module.
Add an in-app purchase flow to the current feature of downloading a property list as a spreadsheet

- We lead users to purchase the proper amount of exports to download the rows they've assigned by selecting the most matched option for them, so users don't need to do the calculation.


- Users can add a new card by entering the number, expiration date, and CVC according to the documentation from the external transaction platform we use. Users can add it to the purchase and make a payment only after our system validated the payment information (the button will turn from disabled to available). This "add a payment method" module is re-usable for future iterations.


- If users have saved payment methods from previous transactions, they can choose to pay from one of those and change it to a default card. Users can also add a new card by selecting the "add a different card," and it'll open the "add a payment method" module.

- After users made a payment, users might forget the amount they want to download, so we will show the new remaining exports and display the amount of the rows that users were trying to download on the download button as a reminder.

A notification at the bottom-right of the screen showing users' remaining exports after downloading a spreadsheet
- After users downloaded the CSV, we will do the calculation and show a snack bar at the bottom-right corner of the screen to notify users of their remaining exports.

Mobile-friendly modal design for different sizes of screens
- To give users an experience similar to a mobile app with our web-based app, I created the small-screen design based on the mobile app design discipline.

Overview of the user flow
- Based on the number of the items in the list and a user's remaining exports, there are three different flows for the in-app purchase experience.

Phase Two
We had to add the subscription packages to the existing flow utilizing the same payment/checkout module.
An upgrade modal leading users to a pricing page to switch to a different subscription plan
![]()
![]()
A pricing page showing four tiers with corresponding package details

- If users click on the locked features, we will prompt them with this upgrade modal, which will lead them to a pricing page after hitting the "upgrade" button.

A pricing page showing four tiers with corresponding package details
- The words of the button on more premium plans comparing to a user's current subscription will be "upgrade now" while the ones on more budget options will be "select plan." This way, we can encourage people to pay more for a higher tier while simultaneously, we don't give any negativity by using the word "downgrade."

- Users can switch between monthly and yearly prices by clicking either the switch or the text labels. This way, it makes the clicking area larger for users to click.

- The page is responsive to different sizes of screens.

A plan payment modal combining "add a payment method" and "saved payment methods" modules from the previous phase

A "Plan & Billing" section on a user's settings page to show the current tier and all the invoices

- This page is responsive to different sizes of screens. I made each row of the invoice table into a card so users can expand it to see more details of an invoice instead of scrolling the wide table left and right.

- Users can add a new billing email address. After verifying the email address, users can use it as their default billing address.

︎
Outcome & Future Iterations:
We conducted usability testing to iterate on phase one design based on user feedback before implementing it. After launch, we had a 20% growth rate of transactions on average in three months. We started having revenue by successfully developing the in-app purchase system on the most demanding features.
Based on users' data from phase one and feedback for subscription plans, we would make adjustments for details of each tier. After implementing the subscription model, we would run analytics to draw out more customizable in-app purchase options within a subscription plan. We also planned to do more user interviews and usability testing to iterate and improve the user experience.
Based on users' data from phase one and feedback for subscription plans, we would make adjustments for details of each tier. After implementing the subscription model, we would run analytics to draw out more customizable in-app purchase options within a subscription plan. We also planned to do more user interviews and usability testing to iterate and improve the user experience.
︎