How we made a mobile app that doesn't need a designer.
Very often in a company a design is completely dependent on the designer. He may even suddenly change him completely, despite the protesting cries of "fronts" and "moblers". We hold a different opinion: the designer’s inner worldview or the developer’s vision should not greatly influence the product. Product design is the visible part of the business with which the customer interacts. The designer cannot introduce his own wishes, he should focus on the needs of clients. Good products develop organically, with an eye on the client. This applies to both functional saturation and design.
The designer should not be the carrier of the requirements for the application, the business should dictate what it will be. Whoever works on the design of ePayments, and the site and the application will be beautiful and comfortable, and the style will not change dramatically by 180 °. This principle works for the benefit of frontend and mobile developers.
Today, I, the project designer Timur, will tell you how we redesigned the mobile application and how our design system appeared.
When I first came to the project, the application looked like this:
And before that it was generally like this:
What didn’t suit me:
1. The application did not scale. Initially, we had 2 currencies (EUR and USD) and 2 cards (for the same currencies). They were rigidly interconnected both visually and logically. The dollar section is a dollar card and so on. Then RUB was added and the whole layout began to "go." To add new elements had to use crutches. EPayments has plans to expand the list of currencies and we had to figure out how to add them without pain for the client. Behavior on all screens should remain predictable. If on one screen the list of currencies was processed by a specific pattern of behavior, then on the other screen the pattern of working with currencies had to be repeated.
2. Outdated design. The application looked very "garbage" and hard, I wanted more air and less unnecessary elements. Why do we need gradients and “beautiful”, if after 5 minutes in the application eyes get tired?
3. Difference in design. For iOS and Android there were 2 fundamentally different applications. If a person switched from one OS to another, he lost all the accumulated user experience. The owner of Samsung could not tell the owner of iPhone how to perform the operation.
4. Suboptimal workflow.When we had a new way to transfer funds from the wallet, this task fell to the analyst who was doing the mocap. Then she came to me and drew a screen for translation. Then the mobile developer turned it all into a code and tamped it into an application. This is an unhealthy process from which 80% of labor costs could be thrown out. Here you can save a lot of time simply by excluding the designer from the conveyor. If there are ready-made interface elements, you can assemble translation windows from them.
And so I set to work. First of all, I wanted to make a user-friendly application. Financial services in general should not occupy the client for a long time. It is necessary to quickly navigate, select an operation, conduct it and go about their business further.
Another important constant is the convenience for developers. If we have a new chip, currency or service, fronts and mobile workers should not suffer and stir up all the styles. They simply add a new feature that looks clear and expected.
I was looking for the simplest analogy and realized that we needed a window designer. We have a set of controls (back, forward, account selection, input of details) and rules for working with them (colors, indents, dimensions of elements). In the designer, analysts and mobile workers can make new service cards and modal windows themselves, without having to bow to me.
It was important to consider that the product is developing "in breadth". Today we have 3 currencies, in a year there may be 33. Today we give 15 ways to transfer money, tomorrow there will be 115. In the application, completely new entities may appear: virtual cards, purchase of shares or other services.
Problem : the project has a growing number of elements - currencies, transfer methods, and so on. Many elements are arranged horizontally, the more they are, the more inconvenient it will be to use it.
Solution : to foresee expansion in advance, choose convenient positioning of elements.
The main problem of the previous version is scaling. So, we have a conditional screen with a resolution of 480 * 720 px. And there are 3 tabs on it horizontally with money transfer methods. Well, tomorrow they will be 15. Who in their right mind will scroll 15 tabs to the right? Or do you need to make them micro-sized, in order to get into them it was only possible with a child's little finger?
In ePayments, the client has one wallet with several currency sections. The most scalable mobile UI element is the list. It can be almost endlessly flipping down completely familiar movement. Even if the elements suddenly become too much, you can always fasten the filter or search.
The limit of convenience is somewhere around 10 currencies or transfer methods. When there are more of them, we will connect the second mechanism, which is currently under development - selected sections. The client chooses which currency sections are more important to him and marks them with an asterisk. Or it collects its dashboard in the constructor, something like the start screen in Jira.
Also, I had a “burger” on the left and a tap bar downstairs. We placed the most important operations on the bottom panel. First of all, you look at the balance of sections and maps. Then you can go to the reception or transfer, see the transaction history or exchange currency. I put everything less important into the burger. Now there is, for example, an affiliate program, which is addressed less frequently.
Ok, problem solved, move on to the next one.
Problem : applications for iOS and Android are unlike each other. Their design is outdated, the interface has a lot of unnecessary elements. The client is difficult to concentrate, he quickly gets tired.
Solution : to make applications on guidelines, but with a unified design. Clean from gradients, work on usability.
As I said, the versions for Android and iOS were fundamentally different applications. There is nothing good either for the client or for us. In addition, developers had problems in rolling in new features and testing. Therefore, we decided to bring everything to the same species.
Cannot make identical applications. Google has Material Design, Epla has Human Interfaces. But we make the basic elements similar. The grid, most of the controls and the location of the blocks became the same. The controls that are responsible for the basic structure are adjusted to the guides of the operating systems. The simplest solution is to completely port the application. But it is rather a sign of laziness and ignorance of the guides. And the guides are written by people who are many times smarter than us, they should be listened to.
First we updated the app on Android. It was cheaper for “story points”, most of our clients use this OS. In addition, at some point we had an imbalance in the mobile development team - there were more people in the Android development team and we could allocate some of them for redesign. This version has gone ahead and the iOS version is now gradually catching up.
It is based on Material Design guides, and thanks to this, an application came out in which everything is familiar to a person with conditional Xiaomi. He will quickly find out how to send the earned money to a bank card.
When we released a redesign, we started collecting reactions and constructive criticism. First came a small stream of negativity from those who do not like redesign as a phenomenon. This is normal and should not be afraid. Every service faces this. Then everything calms down and you can collect useful information.
First, the rating went down a bit, then came back to 4.6. We made a few critical comments and the reviews again became good and kind. From this point on, it was possible to take up an application for iOS.
Now the applications are quite similar. Some things are not consciously made according to the guidelines, but the main metric is the reaction of customers. Everything seemed convenient to users: the rating has not changed, in a review we were thanked for the redesign.
The fact that applications have become similar, reflected in the development. Now it's easier to test them, the cases in Testrail are the same. All case documentation is duplicated - naturally, with amendments. For example, when we are preparing a feature in an application on iOS, it already has JSON from Android and developers do not have to go into requests.
Problem : development process is not optimized. Each new translation card is drawn and developed from scratch.
Solution : make a set of ready-made elements and rules, turning the process into a "designer".
The idea of the designer came along with the redesign of the application, but we implemented it a little later. As I said, the application should not depend on me. If we introduce a new feature, then the task goes from analytics to mobile developers. Those collect a window from ready controls, check its styles, indents and everything else - and voila, the window is ready. I can make an icon, but my direct participation should end there.
At first, I painted each screen individually. Then he grouped repeating elements: lists, controls, buttons, illustrations, confirmation screens, and so on. When the application was ready, I had a full component UI.
Look at the elements, everyone has something similar:
• heading
• “back”
• droplist
• line for entering details
• “next” We make
these elements in advance. Plus we prepare guides by colors, indents and fonts. At the output we get a constructor, in which the developer turns the drawing in the conditional Paint from the analyst into the finished translation window.
Naturally, the mobile workers had to work in order to turn a bunch of screens into a neat component system. But then it was rewarded to them after: it was no longer necessary to go to Zeplin for the screen layout, impose it and store it in the future. There are components, there is a strict style sheet.
I like what we did. The application has become more beautiful, it is appreciated by customers. It became easier for front and mobile workers to work.
We are not yet fully using metrics that would show how user behavior has changed. So now we can judge only by rating and customer reviews. The rating remains the same - 4.6 on Google Play, 4.8 on the AppStore. Most of the negative feedback concerns the verification process, it seems to customers long. And in the positive application is often praised.
Another metric, only internal: I very rarely open a sketch file with a mobile project. Developers add new ways to deposit and withdraw without me. This means that the component UI works and I was able to make the design system, without the dictatorship of the designer.
Now our plans are to bring the product to the same type on different platforms, including the desktop version. In addition, we plan to “shovel” the entire script structure of features in mobile applications so that the client spends even less time on operations. Well, at the same time we will refuse the burger on the left - this is an outdated pattern, there are more convenient options.
We are looking for employees to work in an office in St. Petersburg. If you are interested FINTECH, we are waiting for you. Below you will find jobs and links to relevant pages hh.ru.
The designer should not be the carrier of the requirements for the application, the business should dictate what it will be. Whoever works on the design of ePayments, and the site and the application will be beautiful and comfortable, and the style will not change dramatically by 180 °. This principle works for the benefit of frontend and mobile developers.
Today, I, the project designer Timur, will tell you how we redesigned the mobile application and how our design system appeared.
How it all began
When I first came to the project, the application looked like this:
And before that it was generally like this:
What didn’t suit me:
1. The application did not scale. Initially, we had 2 currencies (EUR and USD) and 2 cards (for the same currencies). They were rigidly interconnected both visually and logically. The dollar section is a dollar card and so on. Then RUB was added and the whole layout began to "go." To add new elements had to use crutches. EPayments has plans to expand the list of currencies and we had to figure out how to add them without pain for the client. Behavior on all screens should remain predictable. If on one screen the list of currencies was processed by a specific pattern of behavior, then on the other screen the pattern of working with currencies had to be repeated.
2. Outdated design. The application looked very "garbage" and hard, I wanted more air and less unnecessary elements. Why do we need gradients and “beautiful”, if after 5 minutes in the application eyes get tired?
3. Difference in design. For iOS and Android there were 2 fundamentally different applications. If a person switched from one OS to another, he lost all the accumulated user experience. The owner of Samsung could not tell the owner of iPhone how to perform the operation.
4. Suboptimal workflow.When we had a new way to transfer funds from the wallet, this task fell to the analyst who was doing the mocap. Then she came to me and drew a screen for translation. Then the mobile developer turned it all into a code and tamped it into an application. This is an unhealthy process from which 80% of labor costs could be thrown out. Here you can save a lot of time simply by excluding the designer from the conveyor. If there are ready-made interface elements, you can assemble translation windows from them.
Designing a bright future
And so I set to work. First of all, I wanted to make a user-friendly application. Financial services in general should not occupy the client for a long time. It is necessary to quickly navigate, select an operation, conduct it and go about their business further.
Another important constant is the convenience for developers. If we have a new chip, currency or service, fronts and mobile workers should not suffer and stir up all the styles. They simply add a new feature that looks clear and expected.
I was looking for the simplest analogy and realized that we needed a window designer. We have a set of controls (back, forward, account selection, input of details) and rules for working with them (colors, indents, dimensions of elements). In the designer, analysts and mobile workers can make new service cards and modal windows themselves, without having to bow to me.
It was important to consider that the product is developing "in breadth". Today we have 3 currencies, in a year there may be 33. Today we give 15 ways to transfer money, tomorrow there will be 115. In the application, completely new entities may appear: virtual cards, purchase of shares or other services.
Removing the shackles of restrictions
Problem : the project has a growing number of elements - currencies, transfer methods, and so on. Many elements are arranged horizontally, the more they are, the more inconvenient it will be to use it.
Solution : to foresee expansion in advance, choose convenient positioning of elements.
The main problem of the previous version is scaling. So, we have a conditional screen with a resolution of 480 * 720 px. And there are 3 tabs on it horizontally with money transfer methods. Well, tomorrow they will be 15. Who in their right mind will scroll 15 tabs to the right? Or do you need to make them micro-sized, in order to get into them it was only possible with a child's little finger?
In ePayments, the client has one wallet with several currency sections. The most scalable mobile UI element is the list. It can be almost endlessly flipping down completely familiar movement. Even if the elements suddenly become too much, you can always fasten the filter or search.
The limit of convenience is somewhere around 10 currencies or transfer methods. When there are more of them, we will connect the second mechanism, which is currently under development - selected sections. The client chooses which currency sections are more important to him and marks them with an asterisk. Or it collects its dashboard in the constructor, something like the start screen in Jira.
Also, I had a “burger” on the left and a tap bar downstairs. We placed the most important operations on the bottom panel. First of all, you look at the balance of sections and maps. Then you can go to the reception or transfer, see the transaction history or exchange currency. I put everything less important into the burger. Now there is, for example, an affiliate program, which is addressed less frequently.
Ok, problem solved, move on to the next one.
Leaving differences in the past
Problem : applications for iOS and Android are unlike each other. Their design is outdated, the interface has a lot of unnecessary elements. The client is difficult to concentrate, he quickly gets tired.
Solution : to make applications on guidelines, but with a unified design. Clean from gradients, work on usability.
As I said, the versions for Android and iOS were fundamentally different applications. There is nothing good either for the client or for us. In addition, developers had problems in rolling in new features and testing. Therefore, we decided to bring everything to the same species.
Cannot make identical applications. Google has Material Design, Epla has Human Interfaces. But we make the basic elements similar. The grid, most of the controls and the location of the blocks became the same. The controls that are responsible for the basic structure are adjusted to the guides of the operating systems. The simplest solution is to completely port the application. But it is rather a sign of laziness and ignorance of the guides. And the guides are written by people who are many times smarter than us, they should be listened to.
First we updated the app on Android. It was cheaper for “story points”, most of our clients use this OS. In addition, at some point we had an imbalance in the mobile development team - there were more people in the Android development team and we could allocate some of them for redesign. This version has gone ahead and the iOS version is now gradually catching up.
It is based on Material Design guides, and thanks to this, an application came out in which everything is familiar to a person with conditional Xiaomi. He will quickly find out how to send the earned money to a bank card.
When we released a redesign, we started collecting reactions and constructive criticism. First came a small stream of negativity from those who do not like redesign as a phenomenon. This is normal and should not be afraid. Every service faces this. Then everything calms down and you can collect useful information.
First, the rating went down a bit, then came back to 4.6. We made a few critical comments and the reviews again became good and kind. From this point on, it was possible to take up an application for iOS.
Now the applications are quite similar. Some things are not consciously made according to the guidelines, but the main metric is the reaction of customers. Everything seemed convenient to users: the rating has not changed, in a review we were thanked for the redesign.
The fact that applications have become similar, reflected in the development. Now it's easier to test them, the cases in Testrail are the same. All case documentation is duplicated - naturally, with amendments. For example, when we are preparing a feature in an application on iOS, it already has JSON from Android and developers do not have to go into requests.
Give the reins
Problem : development process is not optimized. Each new translation card is drawn and developed from scratch.
Solution : make a set of ready-made elements and rules, turning the process into a "designer".
The idea of the designer came along with the redesign of the application, but we implemented it a little later. As I said, the application should not depend on me. If we introduce a new feature, then the task goes from analytics to mobile developers. Those collect a window from ready controls, check its styles, indents and everything else - and voila, the window is ready. I can make an icon, but my direct participation should end there.
At first, I painted each screen individually. Then he grouped repeating elements: lists, controls, buttons, illustrations, confirmation screens, and so on. When the application was ready, I had a full component UI.
Look at the elements, everyone has something similar:
• heading
• “back”
• droplist
• line for entering details
• “next” We make
these elements in advance. Plus we prepare guides by colors, indents and fonts. At the output we get a constructor, in which the developer turns the drawing in the conditional Paint from the analyst into the finished translation window.
Naturally, the mobile workers had to work in order to turn a bunch of screens into a neat component system. But then it was rewarded to them after: it was no longer necessary to go to Zeplin for the screen layout, impose it and store it in the future. There are components, there is a strict style sheet.
Summing up
I like what we did. The application has become more beautiful, it is appreciated by customers. It became easier for front and mobile workers to work.
We are not yet fully using metrics that would show how user behavior has changed. So now we can judge only by rating and customer reviews. The rating remains the same - 4.6 on Google Play, 4.8 on the AppStore. Most of the negative feedback concerns the verification process, it seems to customers long. And in the positive application is often praised.
Another metric, only internal: I very rarely open a sketch file with a mobile project. Developers add new ways to deposit and withdraw without me. This means that the component UI works and I was able to make the design system, without the dictatorship of the designer.
Now our plans are to bring the product to the same type on different platforms, including the desktop version. In addition, we plan to “shovel” the entire script structure of features in mobile applications so that the client spends even less time on operations. Well, at the same time we will refuse the burger on the left - this is an outdated pattern, there are more convenient options.
Looking for a job?
We are looking for employees to work in an office in St. Petersburg. If you are interested FINTECH, we are waiting for you. Below you will find jobs and links to relevant pages hh.ru.