Onpay.ru – is a service organization for the reception of electronic payments, which gathers in a single view multiple payment methods in runet.
Anyone who pays a purchase online through this service and gain access to your personal account, where there is a history of operations, re-tools, re-regular payment, the most common ways to withdraw funds from the wallet phone payment and invoicing to another user. The balance can be replenished, order and pay for products online store directly from your personal account. Service already has a few tens of thousands of users required a redesign of maintaining the functionality. It looked like a purse interface before beginning work.
Design a personal account interface wallet.onpay.ru, to develop a new adaptive design that is optimized to run on devices with different screen sizes. This publication describes the interface design process.
Service users – individuals, consumers, pay for purchases using Onpay on the websites of online shops. This is a wide range of both experienced and, increasingly inexperienced in terms of online payment, users who pay to buy the network in large, small and regional online stores, the buyer goes to Onpay for payment.
The priorities were identified as follows:
- The interface should be as simple as possible and details not loaded;
- Forms of payment shall consist only of the required fields, and save the visibility of which section they belong to;
- The minimum depth of the divisions in the navigation;
- Conservation as possible in view constantly come in all areas, even on small mobile screens.
- Home (dashboards) should be a square panel – dies with a summary of all recent transactions. When you press each panel should open over the page interface and contain a detailed entry and operation of the instrument.
- Design a web application must be built with responsive design.
- Tools left to the discretion of the designer.
It was agreed that:
- It would be adaptive for three prototypes of 4 screens widths: 320, 480, 768 and 1200 px, developed Axure;
- The level of detail is high, with a clear portrayal of all controls;
- Pages should contain close to the real demo data.
The prototype should be drawn:
- All cabinet page;
- All types of operations available to the user and form repeating each operation on the home page;
- Adaptive operation history table;
- Adaptive list special offers shops where Onpay service is used.
Process and decision
The final result was achieved through several integrations and find the optimal decision for the display structure and operations forms in the panels.
Have questions about:
- Should the panel to open a modal, or opening operation should be left outside panel elements.
- Should the panel to occupy the whole area of the pages on larger screen sizes as well as on small mobile screens.
- Should the company have a special button “Cancel” button or the user, and so understand that the folding panel – this is the cancellation.
- It will clear enough minus symbol for the action of folding panel.
- Obviously if that button with the symbol “X in the circle” to remove the panel from the tape dashboards, and not just close (swerve) it.
- Does the user puzzled when the form operation comprises several steps with animated moving horizontally and the lack of back button to the previous step, if this step has been passed and validated.
- Do I need to open an animation panel, moving step by step form.
The first versions were drawn prototypes, where the panels were opened, increasing and pushing neighboring, some form of payment in the body of the page opened, occupying the entire central part. Some sections of the main menu hidden in the flowing menu on mobile screens.
Obviously, the decision was unsuccessful, when used on mobile screens would need to show the panel open from the top, which would lead to complicated mechanics and unnecessary delays in the mapping.
In the second version of the panel and open the page in the body, but at the same time remaining concealed, thus open the panel occupied the entire width of the content area of the page
The resulting interfaces were well designed for mobile screens for mobile first method
The requirement of leave forms recognizable and similar to mobile and larger screens, but on wide screens on the window controls were too separated from the main part of the form.
It was decided that:
- Too much space was given to a small composition in the form of wide screens, so they were kept to a minimum fields;
- It remained unsolved problem of the high probability of user care by filling in the form (not to get hit by accident or distracted by other information) is great, because all elements of the main and bottom menus remain available;
- On dashboards panel increases with suggestive, leading to disruption of the grid complex and rebuild on mobile screens, which adds lightness, little suitable financial service interface.
- Form in the remaining sections differ in the mechanics of opening and type of forms in the panels on the dashboards that have been logically incorrect, as forms on other pages creating the same operation, only new and had to keep the interface is the same as in the panels on the dashboards.
At the last stage:
- Opened modal steel panel, at the opening of the rest of the page was blocked interface, the user has less chance to escape from the payment transaction;
- Form in the panels and in other sections of the same behavior, the magnitude and configuration;
- Steel dies firmly shifted to each other, thereby reducing the amount of noise and superfluous lines;
- Panel width on all screen sizes should not exceed 480 px, preserving the geometry of form fields virtually unchanged on all screen sizes;
- Each step fillable forms have no more than three rows of fields;
- Unnecessary “Cancel” button in the box Hide;
- The panel control remove from the dashboards were placed in the bottom of the panel, in order to first show the user the content pane, and why has the decision about removing her, removal from the dashboards not led to a complete loss of information about the operation in the panel, it is simply no longer displayed on dashboards but the data can be found in the history of payments and sent the list of accounts;
- Panel had only three kinds of badges, tokens of successful, unsuccessful or expected operation, but in the form of a detailed view of these markers were obtained from different types of different decoding operations;
- Markers allowed rapid initial information about the status of the payment, in most cases, the use of service was enough information for the user, so the markers of the largest and most conspicuous element of square dies on dashboards;
- Flexible mobile list of the cards in the history of operations with two rows of labels on the card turned into a standard tabular view of the desktop;
- Navigation is as accessible as possible to all screen resolutions, first to selectively hide labels labels for elements which may be recognizable mark icon in the drop down menu hiding functionally similar action groups, so that the name of the group came up to all elements hidden behind it;
- Dice retain their geometry and are adjusted for the width of the mobile screen in the vertical and horizontal orientation.
- Functional, structural concept of a personal account interface;
- Rendered in black and white pages service prototypes of all, fully detailed, clearly reflecting all the necessary functionality;
- Adaptive html-prototype;
- Navigation service partition scheme;
These prototypes of the next stage are the visual requirements specification, and allow to start a programming interface and graphic design, layout simultaneously, which speeds up the development as a whole.
Next was developed interface design based on these prototypes.