Ozon pricing is the main tool for pricing, monitoring and price analytics at OZON. With its help, pricing strategies are created, applied and controlled, and price calculation methods are established. The control is carried out both in real time and in configurable time intervals
The system interface is in its original form...
The main problem that still remembers the first people is the pricing management system made by generations of developers, each of whom added their own unique view of its functions and elements. Even the oldest and most experienced users often did not know what was hiding in the context menus with four levels of nesting and what would happen if they selected those two checkboxes with strange names. Add to this conflicting modules, robots making changes to prices according to outdated data and not disabled due to not setting the end date of action, because of the lack of “alert”
The second is when users need to perform actions with prices that deviate at least a little from those offered by existing tools. All. There are two options here, either the appearance of the next strange checkboxes in the interface, about the purpose of which, except for those who wished this function, no one else knows, or writing another script that will inspire the next generation of developers
Task: to create a flexible functionality that can satisfy even the most sophisticated desires of pricing agents and implement it in an interface, where one can work without a thousand-page manual and three-months of training
The first prototype
After studying the business descriptions, one collects the first prototypes. At this stage, one describes the basic functions and scenarios of users’ behavior. We identify problem areas, logical inconsistencies, decision-making processes that are difficult for users...
As a result, one reviews workflow and rewrites business descriptions
Первый прототип
Изучив бизнес-описания, собираю первые прототипы. На этом этапе описываю базовые функции и сценарии поведения пользователей. Выявляем проблемные места, логические несоответствия, сложные для пользователей процессы принятия решения...
Результат – пересматриваеем workflow, переписываем бизнес-описания
The second prototype
According to the updated description, I start working on the interface. With analysts, we fix the main functions in the interface and get feedback from users. At the same time the UI elements are crystallized
The main difficulty is that the “business” adds requirements, which were not originally mentioned in the process descriptions, also the legislation in the field of VAT is changing, marketing is creating new features as well. As a result, it was proposed to make the interface as scalable as possible, which was of great assistance for the team later, and, the icing on the cake, respect of the whole team. Thus, to a request to add a variable, filter or form in the future, the respond will be, “Sure, already in the sprint.”
Routine
More then 300 screens, alerts, notifications, hints, microanimation and finally onboarding. Invision opens the project with difficulty, in Zeplin orientation is only through search. The product turned out without haste and mistakes
As for the problems one had to face
1. Huge tables – 260 columns, horizontal scrolling and all that follows. Moreover, users did not give up a single column, what is more, they even added one in the process, however, they agreed that the entire array of columns is never used by them. Thus, a table setup tool was suggested by me. With its help, the user can select those columns that one needs and save this set as a preset for further use and it is also possible to create the necessary number of presets
2. Quick correction of data in cells. Previously, the user corrected them in excel and re-uploaded them to the system. This feature was kept, but I also suggested doing it from the interface + storing the history of data changes in a cell with personal comments (the user often changes data and looks at how they will affect related variables)
3. In the previous version of the system, "keyboard shortcuts" were actively used. Initially, I opposed the use of this solution, which is not popular on the web. But the tests showed that I was wrong, it is convenient for users and they actively use them in their work
4. Notifications. In the process of working with data, assigning a pricing policy and performing other actions, the user can make not only errors that cause alerts, and do not allow to continue working until corrected. There are still many user decisions that are controversial, risky, but nevertheless not critical. And there may be dozens of such solutions in a one-time upload, and it is not acceptable to display the corresponding alert window on each of them. I suggested adding a notification stack to the interface – i.e. notifications. Inside, they are sorted by type and the user can select the specified rows in the table or all suspicious ones at once and double-check his decision
