Show your passport. Part 1
This project was executed in collaboration with Mitya Teryaev , a talented frontend developer.
The task of our team is simple and secure online access to all bank services. From the client’s side, this seems quite obvious. For example, after logging in to a single Google account, all services of the company are available to the user. And this is normal and correct - why re-enter the Disk, Documents, Music or Notes, if you have already successfully logged in to the Mail?
')
“Yuriki” (Alpha-Business), “physicists” (retail), “salary workers” (Alpha-Salary) are independent systems that were made by different teams, separated from each other.
Years have passed ...
A bank customer is often both an individual and a legal entity, and he needs easy and secure access to all bank services.
The task was incredibly voluminous. A lot of little things opened up, having a very remote relationship to the interface (as it seemed at the very beginning).
We started with a frontend-developer with a rework entry point for the "physicists". It was necessary to create the most simple authorization in the online bank. Our design director RockBee insisted that we work together. Thank him very much for that.
With the current implementation of the entrance to the "Click" the user has a username and password. To get into the system, you need to confirm your login using SMS.
The idea was to leave only the phone number - so the user does not need to invent, remember, record a separate login. It also required to unload the page, focusing on the entrance.
This is how the page looked like before:
Two inputa, button, entrance and registration, phones instead of the FAQ (which created an additional load on the call center), basement.
Scheme of new user flow on the example of processing the entrance to the "Click".
The first design sketches appeared in 5–6 days. It was my first week at the bank, and I was in a hurry to show the result. I repainted everything using our component library and made the first static:
A pair of screens of the very first approach to the task
At that time, it seemed to me that there was still a little bit of everything and everything - you can collect, test.
After the comment, the design director had to redo everything. The comment was simple: “Why do we need the“ Enter ”or“ Next ”button?”.
According to statistics, most users use the entry point in the Internet bank through the phone. If you are in the focus of the active imputa, you already have the “Next” button on the keyboard, and you do not need to duplicate it. Everything else, we forgot that the browser can store your cookies! So, from the login step, you can simply refuse, remembering the last login.
I did not believe that users would perceive the login page without a large control button. Our design director sent me to assemble two prototypes for testing. It seems I began to understand how to think and work in Laba.
No sooner said than done.
As a result of testing, it became clear that you can safely do without a button and move everything into the frame of the input. Users quietly moved from screen to screen by clicking on the arrow in the input instead of the button. There was no point in completely removing the button, but shifting to the input - it is possible. So we got the first real data.
Multiple “no button” screens. Cookie and change user
The assembly of the front-prototype has begun, taking into account the test results.
Feedback fragment following the results of testing. In total, we surveyed 34 respondents.
If you make a page on which there is only one input, interesting points of type appear:
And so on.
All possible scenarios were taken into account and implemented.
Creating new components
Within the Bank we use a single library of components . This is a very handy thing for quick assembly and testing hypotheses on prototypes. A kind of unifier of appearance for everything.
The problem was that the component we needed in this unifier was not. Have made:
Old vs new input
The mobile version of the web is done first of all and may well differ from the desktop.
This can be seen on the code entry screen from the SMS. We made it 1: 1 with the Alfa-Bank app. Now the teams are trying to make our products consistently and use mobile developments on the web.
SMS confirmation screen. The transition to the next step occurs without a button in automatic mode.
It is very important that the titles and labels do not duplicate each other, and the texts themselves are clear and do not contain complex technological terms. First of all, it concerns errors.
The current display of some error messages and hints. Most of the texts we have rewritten.
We take cards to order, if we understand that we have the honor to interact with a non-Alpha client.
Using Framer, Invision, Marvel, Flinto, etc., you can simulate the work of a real application, but it will still be a sham.
But working together with a developer is another matter.
Quite a common story when a designer gives a developer a picture in Zeplin, and that’s all:
Simulating the transfer of layouts with grammatical errors
As a result, you get something that requires more than n hours of work on the project, because at the very beginning you did not work together. We do not do that.
Therefore:
Come on passport.alfalab.design
What to enter in the field to see how something works?
1) +7 000 000 00 00
account with 1FA for authorization and a card for recovery.
2) +7 000 000 00 01
account with 2FA for authorization and account for recovery.
3) +7 000 000 00 02
bank customer with a card that can register.
4) +7 000 000 00 03
bank customer with an account that can register.
Any other number will not pass the first step. An error will be displayed.
Passwords are always zeros. Validation of the card / account number is based on the Moon algorithm . Use - 4111 1111 1111 1111.
Since the prototype is updated regularly, something may occasionally not work. Clean the cookie!)
Want to make cool designs with us? You know what to do .
If you have any questions about the article - be sure to write in the comments.
What is a passport and why is it needed?
The task of our team is simple and secure online access to all bank services. From the client’s side, this seems quite obvious. For example, after logging in to a single Google account, all services of the company are available to the user. And this is normal and correct - why re-enter the Disk, Documents, Music or Notes, if you have already successfully logged in to the Mail?
')
“Yuriki” (Alpha-Business), “physicists” (retail), “salary workers” (Alpha-Salary) are independent systems that were made by different teams, separated from each other.
Years have passed ...
A bank customer is often both an individual and a legal entity, and he needs easy and secure access to all bank services.
The task was incredibly voluminous. A lot of little things opened up, having a very remote relationship to the interface (as it seemed at the very beginning).
We started with a frontend-developer with a rework entry point for the "physicists". It was necessary to create the most simple authorization in the online bank. Our design director RockBee insisted that we work together. Thank him very much for that.
Stage 1 - Static. The beginning of a very long journey
With the current implementation of the entrance to the "Click" the user has a username and password. To get into the system, you need to confirm your login using SMS.
The idea was to leave only the phone number - so the user does not need to invent, remember, record a separate login. It also required to unload the page, focusing on the entrance.
This is how the page looked like before:
Two inputa, button, entrance and registration, phones instead of the FAQ (which created an additional load on the call center), basement.
Scheme of new user flow on the example of processing the entrance to the "Click".
The first design sketches appeared in 5–6 days. It was my first week at the bank, and I was in a hurry to show the result. I repainted everything using our component library and made the first static:
A pair of screens of the very first approach to the task
At that time, it seemed to me that there was still a little bit of everything and everything - you can collect, test.
After the comment, the design director had to redo everything. The comment was simple: “Why do we need the“ Enter ”or“ Next ”button?”.
According to statistics, most users use the entry point in the Internet bank through the phone. If you are in the focus of the active imputa, you already have the “Next” button on the keyboard, and you do not need to duplicate it. Everything else, we forgot that the browser can store your cookies! So, from the login step, you can simply refuse, remembering the last login.
I did not believe that users would perceive the login page without a large control button. Our design director sent me to assemble two prototypes for testing. It seems I began to understand how to think and work in Laba.
No sooner said than done.
As a result of testing, it became clear that you can safely do without a button and move everything into the frame of the input. Users quietly moved from screen to screen by clicking on the arrow in the input instead of the button. There was no point in completely removing the button, but shifting to the input - it is possible. So we got the first real data.
Multiple “no button” screens. Cookie and change user
The assembly of the front-prototype has begun, taking into account the test results.
Feedback fragment following the results of testing. In total, we surveyed 34 respondents.
If you make a page on which there is only one input, interesting points of type appear:
- I, as a non-bank customer, want to enter by phone number.
- As a bank customer, I want to enter the service by card number.
- As a bank customer, I want to enter the service, but I only have an account number.
- As a bank customer, my phone number has changed.
- As a bank customer, I want to restore access to the service while being abroad with a local SIM card.
And so on.
All possible scenarios were taken into account and implemented.
Week 2–3. End of statics
Creating new components
Within the Bank we use a single library of components . This is a very handy thing for quick assembly and testing hypotheses on prototypes. A kind of unifier of appearance for everything.
The problem was that the component we needed in this unifier was not. Have made:
Old vs new input
Consistency
The mobile version of the web is done first of all and may well differ from the desktop.
This can be seen on the code entry screen from the SMS. We made it 1: 1 with the Alfa-Bank app. Now the teams are trying to make our products consistently and use mobile developments on the web.
SMS confirmation screen. The transition to the next step occurs without a button in automatic mode.
Texts
It is very important that the titles and labels do not duplicate each other, and the texts themselves are clear and do not contain complex technological terms. First of all, it concerns errors.
The current display of some error messages and hints. Most of the texts we have rewritten.
We take cards to order, if we understand that we have the honor to interact with a non-Alpha client.
Stage 2 - Front
Using Framer, Invision, Marvel, Flinto, etc., you can simulate the work of a real application, but it will still be a sham.
But working together with a developer is another matter.
Quite a common story when a designer gives a developer a picture in Zeplin, and that’s all:
Simulating the transfer of layouts with grammatical errors
As a result, you get something that requires more than n hours of work on the project, because at the very beginning you did not work together. We do not do that.
Therefore:
All further design changes were made directly in the code. It is much faster and more efficient. In addition to speed, we were able to immediately test our product on different screens.
Where can I feel live
Come on passport.alfalab.design
What to enter in the field to see how something works?
1) +7 000 000 00 00
account with 1FA for authorization and a card for recovery.
2) +7 000 000 00 01
account with 2FA for authorization and account for recovery.
3) +7 000 000 00 02
bank customer with a card that can register.
4) +7 000 000 00 03
bank customer with an account that can register.
Any other number will not pass the first step. An error will be displayed.
Passwords are always zeros. Validation of the card / account number is based on the Moon algorithm . Use - 4111 1111 1111 1111.
Since the prototype is updated regularly, something may occasionally not work. Clean the cookie!)
In the next series:
- Hypanyam from launch (partial roll-out on the battle)
- We show the measurements of passage in the authorized zone
- Tell about the test results
- Let us dwell on the used metrics
Want to make cool designs with us? You know what to do .
If you have any questions about the article - be sure to write in the comments.
Source: https://habr.com/ru/post/335892/
All Articles