What are the problems?

Lack of orientation due to inconsistency and clutter

• When a user is on the Deposit tab -> selects Bank Transfer but has no bank account yet, clicking on `Add Bank Account` will switch them to the Manage tab where they fill in the details. However, when they `Add a Debit/Credit Card` they retain on the same tab and not switch to the Manage tab.

• Problematic hierarchy of information as it’s not intuitive enough in guiding the user to complete the task easily.

• UI is all over the place which disrupts legibility.

• Deposit prompts user to select method first, however, for Withdrawals user is prompted to select currency first.

• Irrelevant information are displayed e.g. “Unfortunately, we cannot accept cards issued in Germany at this time” when this is only applicable to less than 5% of our existing users.

Lack of user confidence

• Due to the lack of orientation, it requires the user to learn the process instead of simply completing the task in a flash.

• There is no `Review` step before clicking `Pay` when making a credit card transaction so a user would have to check the summary section thoroughly. With the reasons stated above, this leads to a lack of confidence, which results to a slow success rate. This becomes more apparent when a user makes a large transaction.

Omnichannel experience can’t be achieved

• As the desktop version is already problematic, the same issues will be carried over if we were to implement the same structure on the mobile app.

Approach

Was excited for the challenge! I knew the legacy design structure wasn’t optimal for the mobile app so I decided to revamp Deposit & Withdrawals mobile first and then scale up.

With all the points listed above in the Considerations & Challenges section, this is the 4-page flow system I’ve set up for the Deposit & Withdrawal, which aims for a flexible, scalable and systemic approach. The 4-page flow system:

1. Choose Deposit/Withdrawal Type

2. Instructions

   • Select Currency

   • Enter Amount

   • Select Payment (Card Deposit)

   • Select Bank (Bank Transfer Deposit & Withdrawal)

   • Add (No existing card or bank)

3. Review

4. Confirmation

Considerations & Challenges

Leading this project, I worked closely with the Product Owner and Head of Design — here are essential points about the EQONEX Exchange that I needed to consider when building the new Deposit & Withdrawal workflow:

Deposits

Holding

• The platform does not hold any fiat wallets.

• Any fiat currency deposited will automatically be converted into the base currency the user has selected on their account, which is either USDC or USD.

Adding

• A debit/credit card is not saved until successful transaction.

• There’s no need to add a bank account when making a EUR or GBP bank transfer but a USD bank transfer does.

• It takes 3 days to verify a bank account.

Accounts

• A user can only deposit into their Main Account. Transferring balance into their Sub Account(s) can only be done after the deposit is successful. To learn more about the sub account feature on the EQONEX exchange, view case study here.

Bank Transfer

• When making a USD bank transfer for the first time, it requires a document verification whereas EUR/GBP does not.

• When making a USD bank transfer, the amount stated in the deposit request should match. Otherwise, Ops team would need to manually update the request on the internal portal.

• When making a EUR/GBP bank transfer, the name on the EQONEX account and the bank should match as well as the amount stated in the deposit request. Otherwise, if the names significantly mismatch it’ll be marked as `Failed` then Ops team would have to contact customer notifying them the result. The customer will have to make the necessary adjustments, if not the deposit won’t be accepted.

Withdrawals

• In order to make a fiat withdrawal with a selected currency, a deposit has to be made first in that currency

• The balance they can withdraw is only the value of their USDC asset. If they want to withdraw the balance from their other assets such as BTC, they will need to be traded first.

Designing the omnichannel experience

As the UX team is building the new Design System, we are also in constant discussions about the why’s, what’s, how’s and where’s. For example, in what format should Deposit & Withdrawals be on the Exchange and why?

• Does it live in a page?

• Is it a hovering flow that is temporary?

• Should it be as a drawer? Or a modal perhaps?

With the UI Overhaul Day 1 release, one of the main goals of the new Exchange is to have fast access navigation back to Trading. In order to be aligned with that goal, we want Deposit & Withdrawals to be a hovering flow so that a user can quickly get back to the Trading.

Exploration

Now in what format should it be? A modal or a drawer?

Judging Criteria

UX

• Clarity / Single-mindedness (what do I need to do)

• Error prevention (how easily could I make a mistake - wrong choice, cancel flow)

• Orientation (where am I, how do I get back, what’s coming next)

System

• Scalability (does this work with any flow that may be a modal)

• Omnichannel (does it allow the flow to work the same way in all channels)

Drawer exploration

Multiple prototyping samples of the drawer were done to help us evaluate the experience better.

1. Small and large drawer sizes

2. One-action only inside drawer

3. Multi-level steps inside a drawer

4. A combination of a drawer with quick action modals

As much as we wanted to make the drawer work, it is not well suited for the Deposit & Withdrawal flow. Why?

• Multi-level steps inside a drawer makes the user lose orientation

• Accidentally clicking outside the drawer would be an inconvenience

• Considering how Deposits & Withdrawals are fundamental flows - making the user fixate only on the right side of the screen:

  • Does not provide the flow the importance and focus it needs

  • Loses comfortability for the user in comparison to looking at the centre of their screen

Modal exploration

Multiple prototyping samples of the modal were also done to help us evaluate the experience better.

1. Fixed mobile-size modal (with scroll when necessary)

2. Large and medium-sized modal with a left-handside menu

3. Fixed sized modal that is top-aligned

4. Fixed sized modal that is centre-aligned

5. Modal height changes responding to the length of content