As Product Manager, I led user research, facilitated team ceremonies, and helped manage the product backlog.
I worked cross-functionally with two frontend engineers, two product designers, and a test engineer.
I also contributed small design tweaks to the mobile app codebase, which helped to unblock the team on several occasions.
Making cryptocurrency spendable in the fastest possible way
Liquidating cryptocurrency for spending purposes is a cumbersome, multi-step, and error-prone process.
Our customers, who invest in cryptocurrencies, prefer to “spend” from their gains, rather than their spending money, especially when purchasing discretionary goods or traveling.
For them, speed is of the essence, and the manual process was too slow.
Solution: TenX Card & Wallet
TenX Card is a debit card linked to TenX Wallet, a mobile cryptocurrency wallet for Bitcoin, Ether, and Litecoin.
You can send your cryptocurrency into the TenX Wallet, which makes it available for instant spending with the TenX Card, making your cryptoassets spendable at any online or physical store which accepts VISA.
Once set up, the card works independently of the wallet.
You could top up your wallet by sending funds in to a fixed wallet address, without having to open the app to do anything – once the transaction is confirmed on the blockchain, you can spend it with the card.
This makes the experience simple and seamless.
While there are still a few useful things you could do with the app, we designed it so it would mostly stay out of your way until you needed it to:
- check your balance
- spend from a different cryptocurrency wallet
- send cryptocurrency out to another wallet
- check your past transactions
- obtain your ATM PIN for cash withdrawals
- disable transactions from going through (if you misplaced it)
- cancel your card
What I worked on
While I was at TenX, I worked on a variety of initiatives, three of which had a significant impact.
This work, which spanned the course of over a year, helped contribute to the product reaching initial Product-Market Fit with a steady loyal userbase that uses the app daily.
Initiative 1: Migrate to React Native
From talking to our most loyal users, we found out that most of them found our product (the card and wallet combination) extremely useful, and loved using it.
However, analytics showed that most of our users weren’t returning to the app after signing up. Our support and community teams also often get complaints about bugs and usability issues in the app. On the app stores, our app also received scathing reviews from users complaining about the user experience.
So, from June to December 2018, the TenX Wallet team underwent a code migration for our mobile frontend, from native iOS (Swift) and Android (Java), to a unified React Native codebase written in Typescript.
We undertook this migration in an effort to fix technical and usability debt that had been accumulated over the course of its development, as well as to allow our small team to move faster with one unified codebase to maintain, instead of two.
This was the first bet we took towards improving the product to prove out Product-Market Fit with our userbase of early adopters.
As a result of this migration, user retention was much improved, and the app garnered better reviews on the App Store and positive feedback on social media channels, despite the underlying app design remaining largely unchanged.
It also helped improve our team’s design and development processes, enabling designers and developers to work more closely together and make shorter iterations between every release.
This migration, which was carried out over 5 months, is documented in detail within a series of three blog posts published on the TenX Engineering blog.
The first one introduces the context and motivation behind the decision, the second dives into how we evaluated the technology, and the third dives into how we executed on it:
Embracing React Native for Lean Mobile Development (Part I of II)
About one year ago, the Wallet team started to get into quite a tricky spot. Support tickets were piling up. Our backlog of bugs was growing faster than we could chew through it. With every new feature we built, new bugs emerged. Each new feature shipped felt like we were moving one step forward and two steps back.
Embracing React Native for Lean Mobile Development (Part II of II)
This is the second part of a two-part post. You can read Part 1 here, where I introduce the context and motivation behind our decision to port our standalone native iOS/Android apps to a unified...
Initiative 2: Redesign Card Order Flow
In order to get the TenX Card, users first had to verify their account.
Since TenX had to comply by financial regulations, we had to ask customers who were trying to order the TenX Card for various personal details and supporting documents:
- Verified phone number
- Verified email address
- Full legal name
- Date of birth
- National identity card or passport
- Selfie photo
- Residence address
- Proof of residence address (i.e., bank statement or utility bill)
We knew from usability tests that drop-off rates would be significant. Since this is such a cumbersome and multi-step process, we wanted to make it as painless as possible.
Because each verification attempt submitted by the user incurs a significant operational cost, we needed to massively rework the usability of the flow to ensure the minimum drop-off rates to operate a profitable business.
Identifying usability issues
From analyzing support tickets, we found two main friction points in the flow.
- When users were verifying their account before purchasing a card, they had to submit a series of details and documents in one long form, without any guidance or status to help chunk up the work.
- After users have purchased a card, and are waiting for their order to arrive, the screen simply says “Thank You!”. Users didn’t know if anything happened to their order for up to 2 weeks while the card shipped, which infuriated them.
Improving the design
With a focus on usability, we made the following changes:
First, we redid the account verification flow, with guidance and hints.
To reduce cognitive load, we also chunked up the details and documents required into multiple sections, which users could complete in any order, instead of having to fill up one long continuous form.
Below, you can see a video demonstrating the newly-designed verification flow:
Next, we added a status history to the card order flow, to be more transparent about each step in the fulfillment process: whether the order was confirmed, shipped, or delivered.
This helped to allay any concerns users may have, which often resulted in a support ticket.
Redesigning backend and operational flows
These improvements to the verification and order fulfillment flow weren’t simply skin-deep.
As part of the redesign, I had to work with the team supporting compliance and card operations to make several changes to how our backend systems treated verification attempts and card orders.
These were designed as “finite state machines”, and illustrated visually, to help coordinate work between multiple teams (the TenX Wallet team, the team that worked on our back-office administrative tools, backend engineering, as well as customer support, and operations).
Due to our improvements, we massively improved usability and managed to achieve a verification rate of 86%, meaning, for every 100 users who started the verification process, 86 of them were successfully verified.
Initiative 3: Redesign Transaction History
In December 2018, while testing out the product with a small closed group, we ran into usability problems with how we displayed past transactions made with the card.
We were using terms like “Error” and “Confirmed” to refer to certain card transactions, which, in an effort to be transparent to our users, ended up confusing them.
These statuses had an internal meaning to the operations and engineering teams, but didn’t describe accurately what was happening to users.
The problem would be simple if we could just hide these statuses from the user, but, unfortunately for us, it’s much more complicated than that.
Discovering possible solutions
Before we jumped in to redesign the app’s interface, we wanted to address some of our uncertainties by understanding how our users thought about the problem.
Because the data involved in a card transaction is varied, and dynamic (meaning, the status of a transaction changes as time passes), we couldn’t research the problem by just asking users in an interview or survey.
To discover how users expected their transaction history to be presented in different scenarios where they would spend the card, we used role-playing and wizard-of-oz research techniques instead.
During the sessions, our research assistant Christina helped to set the scene by playing a Starbucks barista, or by being the “wizard” behind the gas station machine, or the Uber app.
Within each of the specific scenarios, we got users to match transaction statuses (magnetic labels) to what they thought was happening. For instance, in the hotel example, we’d show a transaction that’s resized after the bill is closed, from the initial deposit amount.
Participants would show us how they expect the app to communicate this to them.
Using this approach, we were able to draw certain conclusions from understanding how our users thought about each scenario, which helped us design a clean, intuitive, and structured interface for presenting card spending data.
Making improvements to the interface
Remove invalid transactions from the transaction history
Through research, we’ve learned that showing full details can create more confusion for users.
For instance, this is what’s shown when the ride-hailing app Grab reserves a specific amount on your card before the ride, then adjusts it after your ride was completed:
In our redesigned interface, we decided to hide “invalid” transactions in their transaction history.
Transactions previously labelled “Error” or “Declined” transactions will not be shown in the new transaction list design.
Additionally, we omitted the status for completed transaction (which was “Confirmed” in an earlier iteration). Now, we’re only showing valid transactions in the list:
Reword labels to better communicate transaction status
The way we named our transaction statuses were confusing to users. Based on our card sorting findings, we updated them to be more intuitive:
- Pending → On hold
- Error → Cancelled
- Receive → Refunded
We also changed the transaction title to use the past tense (i.e., Sent, Received) instead of the present tense (i.e., Send, Receive).
Include additional context to help users understand unusual transactions
The VISA network provides an optional ‘Description’ section that merchants can furnish with any transaction.
Since this is not within our control, and can sometimes get quite technical and confuse users, we thought about removing the section, but we decided to keep it since the users still find the information useful. To help the user better understand this, we named this field “Message from merchant”.
To add further context, we also added separate ‘Info’ section, which communicates an additional layer of detail.
Remove transaction full list drawer from the home screen
Finally, we wanted to make the transaction list screen more flexible, so we could add enhancement features in the future, such as letting users sort, filter, and search their transaction history.
Additionally, we wanted to reduce the information density on the home screen, in order to reduce our user’s cognitive load.
In our redesign, we decided to remove the sliding drawer from the home screen that housed a full transaction history. This reduced the information density on the home screen. We moved the full view to a separate screen which also solved a related performance issue with long transaction histories.
A side-effect of this is how we’re able to simplify the app navigation, from both a technical and user experience perspective.