Executive Summary

BitOasis is a trading platform which offers it's users multiple methods of buying and selling cryptocurrencies. As a Senior Product designer within the team, my requirement was to work across multiple facets of their product, with a major focus on new feature creation such as the deposit and withdrawal flow, along with an improved method of connecting payment methods.
Below you will find the steps taken to come to the decisions made and the rational behind them.

User Feedback

We had received feedback from approximately half of our “elite pro” users that they wanted to invest in coins/tokens but had their money in multiple bank accounts. Most pro users are in the UAE or Saudi Arabia, the pro traders accounted for ~1% of the total user base, but roughly 70-80% of incoming funds were by these traders.
The BitOasis platform only allowed for depositing from one bank account; the laws in the Middle East and the technology available when BitOasis was released didn't allow multiple bank accounts to be connected. The problem this presented, in the Middle East, wire transfers are the only way to transfer money between bank accounts, and this can take anywhere between 24-72 hours - when a particular coin (e.g. Ethereum) looks like it's doing well, waiting up to 72 hours for the transfer and then however long the deposit process takes (dependant on the size of the deposit) is too much of a risk. The technology had since advanced, and the laws in the UAE became more accepting of crypto.
Initially, this was intended to be a one-week project (half a sprint); I, a product manager and three developers (Lead, mobile & web) would improve the backend to support the functionality and adjust the interface to accommodate the change.

How we defined user categories

We categorised users into a persona system. Each persona also contained deeper sub-personas. The overarching categories were; Newbie (little to no experience), Amateur, Pro, Business & Passenger (use the platform to purchase coins/tokens, then transfer to a waller or other service to store).
Pro was split into two more sub-categories; general pros, who had experience trading but were otherwise “normal” everyday people. Or elite pros were extremely wealthy people who could invest substantial sums of money.

"Bigger than we thought”

Accessibility has become an area I have gravitated towards more as my career has progressed. At 22, like every fresh-faced designer, I wanted to make pretty graphics and animations that would make Disney jealous. However, as I've evolved through my career, I've come to appreciate the need for more inclusion within design - and tech.
I aim to go beyond just wanting it to "be easy for less abled people". Although this is a significant and fundamental goal, I want to design products which work great without compromising their flair "just to be accessible".
Of course, this is much easier said than done. Almost no website looks amazing when zoomed to 200% or with labels everywhere. Still, I believe if we start by making accessibility the foundation of our work, then everything else becomes easy.
During the project scoping, I found many issues with the existing features and steps required by the users; some include;
No place on the platform to manage multiple banks
No clear indication of deposit history
No easy way of knowing you can deposit various supported currencies
An almost impossible-to-understand withdrawal process
Visually, the deposit interface was very cluttered and had caused many complaints of users being confused (cognitive load)
Analytics I had access to (e.g. Google Analytics for web) showed almost 60% of users who initiated the deposit process didn't follow through
Further to the above, many users complained on App Store (iOS & Android) about how difficult it was to deposit and how impossible it was to withdraw
The pro traders had a general idea of how trading platforms work and could figure out how to navigate the UI or call the desk for advice. But new users found multiple deposit methods and the process of depositing extremely complex
Specific laws existed in the UAE at the time which required a user to state the amount they are transferring before sending it to the BitOasis account - for money laundering reasons

Identified Issues and Challenges

Other issues I found, aside from just within the app, included; a negatively skewed perception of the app from newer or mid-level traders. Public platforms (Trustpilot) had almost 50-50 feedback between 1-star and 5-star reviews. There was very little explanation to users about fees for investing; for example, the primary platform had a ~4% fee on buying a coin, whereas the pro platform only had 0.25%. The reduced cost was because the pro platform required a larger deposit and investment per transaction; we failed to communicate this to the user in a sensible manner - which, in turn, led to users either condemning the platform as a scam or amateur traders using the pro platform (forums telling of lower fees) and losing a lot of money because of the lack of safety net provided by the pro platform.
Many qualitative and quantitative issues existed around the deposit interaction, and plastering over the cracks to allow for multiple bank accounts may solve the problem in the short term; however, it would exacerbate it in the long term.
I discussed my findings with the PM assigned to the project and the Head of Engineering. We decided to increase the project scope to 2 sprints (4 weeks) to fix as many issues as possible and present the best MVP solution.
The PM and I wrote a recommendation to present to the VP of Design, Heads of each company facet and the C-level members. There was some pushback initially; however, upon explaining that we could solve major issues with an extended project now and prevent the need to return to these issues multiple times.
The CEO also informed us that we would expand to Turkey and, if successful, more of the European region, so we should include features and functionality that those markets may require.
Once we agreed on an overarching plan, I set about creating a scope to present to my design team to be reviewed within a week, as this would have significant knock-on effects on other areas of the app.

Planning and Scoping

The planning process required working with our UX researcher to define user pain points and features/changes they have requested. Speaking with each design team member to understand the projects they were working on and how the new system of depositing, withdrawing and managing funds would affect their scope from a usability and functionality standpoint. Speaking with key stakeholders to learn of upcoming plans over the next two quarters, as this would have to fit into existing top-level KPIs but would also adjust the more granular goals we had.
The research and data were presented to my squad on this project; the Head of Product, VP of Design, Lead Designer and Head of Engineering were present so they could coordinate their respective teams based on the plan we agreed upon in the presentation meeting.
We hadn't begun any design or improvement work at this point, but the 1-week project had increased in scope to another eight weeks (4 sprints).
However, many benefits came from this; some UI-related problems highlighted were being compromised between us and tech so we could push changes faster. The Lead Designer suggested that we could use this project as a stepping stone for a redesign and rebrand of the BitOasis platform - which ultimately we did, and this was the very next project we began work on.

Improvements and Design Changes

Two weeks to gather and organise data. Planning everything on paper (theory) and setting a timeline for each area we'd like to complete by the end of the project.
The remaining six weeks were spent between meetings where we'd discuss a particular screen or feature to improve and brainstorm within our squad about the technical, functional and design areas.
There was less of a timeline for each feature change; some pages or elements could be altered or corrected within a day. Some required a half-a-week to understand and complete improvements to ensure the experience was optimal for users and wouldn't need to be redesigned heavily (apart from any UI tweaks) during the rebrand.
Certain areas were also adjusted to update the platform and align with modern design practices, such as; removing the need for an entire page modal when making a small change (e.g. which currency you'd like to deposit in) in favour of a sliding modal at the bottom of the page on mobile and a simple drop-down on desktop.
We ensured each native mobile app was relatively familiar to its users by adopting some native design principles. But some parts of the visual identity were unique to BitOasis, and I designed them to focus on the function instead of the form.
We kept users updated (test group) throughout the process. We would A/B test UI elements or suggest an interaction pattern for a specific action to ensure users felt included and their pain points were acknowledged and corrected.

Flow breakdown - Initial deposit flow vs New deposit flow

Old Flow:

1. The user would go to their wallet screen, which contained a list of all tokens on the platform (repeat of homepage) with a button at the top which said "Deposit"
2. Upon pressing the button, the user will land on the image below
3. From here, the user would choose the funding method. If they wanted to change wallet (different currency), they were presented with a dropdown to do so
Note: A user would have to come to this screen to withdraw fiat currency - there is no indication of this requirement anywhere else on the app
4. The user would be given an entire page to enter the amount they want to deposit and the bank details they should deposit to.
Users were required to press 'Complete' to register that they have initiated the process - this is to notify our financial team in case some or all of the funds are lost.
Users weren’t informed this was mandatory, and the visual component for the button was very easy to miss.
Many users would run into problems after sending their funds from their banks.
Such as, if a deposit hadn’t arrived for two days, they would contact BitOasis customer support for help, but there was no record of them registering a deposit
Also improved in this project - the details for bank deposits were static text, without any interactive elements or a way to ‘copy & paste’ the details - therefore, users had to remember each item and write it into their banking app.

New Flow:

1. Users would access their wallet screen (this step wasn’t necessary when the new homepage was launched)
2. User would decide which action they would like to initiate
1. The user would then decide which wallet they would like to deposit into
2. IF a user selected a default currency at any point (onboarding or in settings), this step would be skipped
Deposit methods had information toggles to help users understand which was best for them
The copy for each method was improved to be a brief but descriptive action, as opposed to the name of the method, to increase ease of use further
3. If no accounts or cards were connected, the user would be taken through the iban.com flow, with the option to add details manually.
If an account was added (below), the first three screens (above) would be skipped.
4. The user would input the amount they wish to deposit
5. The details were presented on a separate screen for users to copy and send to BitOasis
The separation of the two actions ensured users wouldn’t miss the completion CTA
The completion CTA was made ‘sticky’ as opposed to ‘inline’ with the original implementation - to increase visibility
A copy function was added to each field to allow users to enter the details into their banking app easily
If a user had saved accounts:

Specific Challenges and Solutions

Problems arose when we looked into granular elements within each action; for example, we decided to integrate with a service called iban.com to auto-detect a users bank - as opposed to requiring a user to provide all details (Bank name, branch address, etc.). However, some countries like Oman didn't use IBAN addresses for banking. The functional and visual design would need to make it easy for users to see different options given their country at registration.
The solution uncovered problems:
Only some users were comfortable having their bank details checked against a database. While testing the iban service, it sometimes returned errors or completely incorrect bank details.
So a system had to be included for users to input details manually and a redirect for users whose iban address repeatedly returned incorrect details.
Certain countries could deposit and withdraw multiple currencies (depending on country laws), and some could only use their native currency. For example, Saudi Arabia could work with Saudi Riyal (SAR), UAE Dirham (AED) and the US dollar (USD) - but Turkey could only work with the Turkish Lira (TRY) as we still needed to incorporate Euros.
Furthermore, to future-proof the platform, designs would have to exist for countries which allowed automatic depositing and withdrawals (see Trading212).
Adding a new bank account also required proof of identity; the UAE and Saudi Arabia followed a similar system, so this was never a problem. But most other GCC countries and European countries had different systems - all of these had to be accounted for and updated within our verification process.
The withdrawal process was almost non-existent before this project. You landed on a screen with your fiat wallet amount and had a text field to enter the amount you'd like to withdraw. Completing this process would send an email to BitOasis with your account details, which would then have to be manually triggered by our financial team. The process was slow and could take between 4 and 14 days on average.
We automated the process in the backend, with manual intervention possible for the financial team if required. Users now had an interface where they could select their account (saved accounts or iban system), and details were presented to the user in a confirmation screen communicating all information such as fees and bank, etc.
The platform now had a section for users to add, remove and manage their connected accounts - manual bank, credit/debit card and "linked banks", which we called accounts connected to a third-party depositing service called Bolt (see MoonPay). Ultimately, this was the same process as adding a new account for depositing. However, the user had two extra pages; one to see the connected accounts and a confirmation page when they asked to remove an account.

Quality of Life Changes and Additional Improvements

Some quality-of-life changes were added upon my suggestion, remembering the last account a user deposited from or paid within the simple trading platform. This reduced friction for users and required fewer steps for a user to complete an action. The idea was to reduce our current 60% bounce rate by adding a convenience factor. Labels were added to icons, such as; the history button, for users to view previous deposits and withdrawals.
We made many improvements to the app over this 8-week project. Some of these inspired the creation of new pages, updates of marketing websites and improvements of existing pages, such as a settings page, which initially was used for password changes and ID verification but was later expanded to give users a hub to view and manage all aspects of their BitOasis investment portfolio.The Home Screen was also rebuilt from the ground up using my direction. Initially, it was a list of all coins/tokens on the platform, but we moved it to be a main page where users had access to news, tips, an overview of their wallets, etc.


The changes made had good immediate feedback, such as; users liking the copy changes within the platform to communicate fees and directions for the differences between Core and Pro.
Many changes would require long-term usage data, such as; if the reduced friction and incorporation of external services reduced the bounce rate for deposits.