My process of designing modality.
Design challenges are stressful, but I learn something new each time.
It has been a struggle to write lately because I have been feeling a little unmotivated. However, I promised to push myself harder to deliver this weekend, and I am keeping that promise now. This article may be quite lengthy, but definitely worth your time.
I recently completed two design challenges, and it was funny how both solutions involved me using a modal flow. Prior to the first one, I honestly did not know what a modal was, rather that that was the term. It was fascinating conducting research and figuring out the best possible way to solve the given problems with modal screens.
Key learnings from my research on implementing modals to improve users’ experiences include:
- Implementing modals is useful in self-contained processes such as a login flow, where collecting information from users is necessary to complete the following action.
- Modals help users focus on the current task; thus, it is helpful where there is an apparent difference between the modal and a previous screen the user was on, such as an overlay.
- There should be an exit button; users should be able to return to the previous action they were performing before the appearance of a modal screen in case they change their minds about proceeding with the flow.
In this article, I will walk you through my process of designing the solution for the first challenge. The challenge was to design a Pay with Bank Transfer feature using a modal flow, where users can see unique account numbers to complete their transactions and check their transaction status. The duration was a week.
User research
At this stage, I understood what a modal screen entails and the process of designing the solution. I decided to start work on my solution by conducting fundamental user research.
Problem statement
The problem identified is need for a more efficient way for users to make payments through bank transfer by implementing a modality.
The problem statement made it clear who my user personas would be. They included people with trust issues who found it difficult to trust applications with their details. They were also people who had short attention spans and lacked focus.
User personas
- As a student with trust issues, I prefer to make online payments through bank transfers.
- As a tech bro with a short attention span, I would like it if I could complete my payment process without stress.
Competitor analysis
After this, I conducted a competitor analysis and examined how other payment gateways solved the problem. The competitors I identified were Flutterwave and Paystack.
Design
I was clear with the problem and moved into the design phase, where I started sketching my solution.
Ideation
I rarely create paper wireframes; I usually go straight to sketching them digitally using Figma. Since this was also a simple flow, I moved straight into high-fidelity wireframes.
Style Guide
Component Library
Solution
First flow (1): The user needs to see a unique account to make payment for a transaction.
Second flow (2): Users need to check the status of the transaction made (i.e., successful or failed).
Third flow (3): User underpays; a new account number is generated to complete payment if they reattempt the transaction or cancel the transaction and get a full refund.
Fourth flow (4): User overpays; they can proceed with the transaction and get a refund of the difference or cancel entirely and get a full refund.
Fifth flow (5): User completes payment successfully.
I created a Figma presentation where I explained my process in detail, so you can check it out here. You can also explore the various prototyped flows using this link.
The second challenge revolved around designing a solution that eliminates the need for a password to log in. Check out my short case study on it here.
I hope you enjoyed this as much as I enjoyed sharing it with you. I would love to hear your feedback too!
