Planning and design of the new cash register interface for ATOL

“ATOL” group of companies is the largest manufacturer of equipment and software developer in the field of retail and service automation, including production of a wide range of cash registers (CCP). Since 2017, amendments to law 54-FZ "On the use of cash registers" entered into force in the Russian Federation, and in this regards it became necessary to work out the process of registering CCPs, taking into account the new rules.

To investigate the current CCP registration process, to suggest improvements to the registration process and to illustrate the process with a detailed prototype.

Result:

In three months, as a result of several iterations, we have implemented the CCP registration interface for different scenarios.

The session catalog displays the list of registrations carried out in the system.

Registration consists of several steps. Each step focuses the user on a separate task without distracting him by unnecessary information. The form for creating a new electronic key is shown as an example.

Point of sale data. This is a context sensitive form, the set of fields changes depending on the PoS type. This approach allows you to show only important information, hiding all the unnecessary fields.

Registration application screen. The data is sent to the OFD servers and undergoes a long check. You can exit the process while the check is in progress, and return when it is over.

Process:

At the first stage, we studied the CCP registration process. We designed the registration scripts in the form of a structural diagram. Thanks to this, you can clearly see all the features of the registration process, agree on them, quickly make changes and only then start drawing layouts. Of course, the scheme cannot take all the nuances into account, but it helps to significantly reduce the number of alterations at subsequent stages.

However, despite the presence of the scheme, new inputs kept appearing in the design process, which significantly influenced the sequence of steps and their set.

For example, an applicant uses a Qualified Electronic Signature (QES) to sign documents. In the initial formulation of the problem, only one type of QES was provided, but later two more were added. Also, a new cloud signature registration procedure has been added for those who do not yet have a QES.

This resulted in significant scenario branching. An example of interfaces when working with different types of QES:

When scripts branch, not only the set of fields is different, but the sequence and set of screens are also different.

For example, if the applicant has a cloud QES, then some of the fields are automatically filled with data from the QES. Documents are signed instantly directly in the service interface.

If the applicant has a QES that is stored on a USB drive, then for signing it is necessary to download an electronic copy of each document, sign it in a third-party application, and then upload it to the service again.

The company has its own UI Kit for ATOL products. However, this set was not enough for our task. Based on the existing styles and elements, we finalized the UI Kit and compiled an additional kit that was sent to the developers.