Designing visitor behavior for receiving a discount card in an online store
Now I have a client ( I have already mentioned this ) who wants to bring a new bonus system to Ukraine. Slowly it develops into a billing one. Plans are overly ambitious, and everything is done on the knee. The money from the client is big, but the man is old-fashioned and used to doing everything on the fly. This is especially true of IT.
As a result, a lot of problems arose when testing the process of activating a card by a potential owner. Briefly - 3 steps with a return one step, 2 steps for further logging into the system, inconvenient input of an inconvenient password. As a result, the predicted efficiency - a maximum of 10%. This is all a consequence of the lack of visitor behavior design.
I was told to describe “the logic of how the window for entering the card number and the crediting of bonuses with a visitor work”. The way the whole structure works at the moment (I'm afraid to name the system).
')
I dubbed this “design of visitor behavior”, I divided it into three parts: a visitor without a card + a card operator’s registration, a visitor credits bonuses to a card, a visitor pays with a card.
In theory, all this should have been in one document, since All this description of the process of a single script. But the combination of logics would be very cumbersome and inconvenient to learn, especially - people far from IT.
At the beginning of work, the “main” of this entire enterprise, after my explanations and price, issued: “yes, I’ll draw this on a knee with some shop owner for a beer”. Offended, honestly. As a result, the process that takes no more than one minute for a visitor was described in 4 days completely allocated for this work.
The final option and my recommendations showed not only the bottlenecks, but the fact that the script on the side of the store should be completely redone, and in the form in which it now works, there are all prerequisites for frauds, as well as errors when crediting bonuses into the account.
For myself, I set the task to make the process of working with a card in the interface of an online store as simple as possible, protected from errors and sabotage, clearly describe the behavior of field operators. And it is MANDATORY so that in case of any problems the visitor can solve them quickly, without hysterics. After all, problems directly affect the conversion in the store, if the process of interacting with the window for entering the card will be difficult - this will immediately affect the conversion. And the club system, in general, will lose participants.
It turned out that in the designed behavior (hereinafter I will briefly call it “logic”), there are 3 groups of so-called stakeholders. That is, the subjects who take part in the process. Operator, visitor and script. The latter also performs important actions in logic, so I also included him in the groups of stakeholders.
Describe the whole process does not make sense. You can look at the scheme according to which you made the logic at this link , here is only the simplest of the three scenarios of behavior, but it is structurally clear how the rest was done.
I will describe the key points that were revealed through the design process.
During the design process, it became clear that in addition to the field for entering the card number, a number of elements must be added to the workflow:
In this regard, I proposed to introduce a simple pop-up, which would not be blocked by browsers and specials. programs, with dimming the main window. No new windows popup, new tabs and so on. We must not forget that the ordering process should be linear , that is, the visitor smoothly moved from one window to another without any significant process changes.
Plus such a trifle as the preset repeating digits of the card: 9800000000000 (further there is a changing three-digit number).
This question can be solved in two ways. Linking the card to the visitor's account in the store. It only works if you distribute cards to your customers. Once tied (either the operator or the visitor himself) and then forgot about repeated validation, which greatly simplifies the life of customers of a particular store. But, this is already a disassembly of the store itself, respectively, its money for the revision of the functional under the card binding, the bonus card system will not be paid for this.
The second option is repeated validation. Each time the visitor produces the same sequence if he plans to use the card.
The first method does not exclude the second, since Club Bonus program means that there are other cardholders who are not your customers.
Validation will occur via SMS, the visitor will need to enter the code from the SMS. It would seem that everything is simple, "they did it a hundred times." In fact, there are several points that need to be considered:
When I handed over the work to the customer’s representative, we started a dispute about the need to validate the cardholder, provided that the client simply wants to credit the money to the bonus account. It would seem, why is there validation? No one wants to credit money to someone else’s account.
I insisted on validation, my arguments were:
The complication of the process is obvious, and there is a bunch of conditions that will naturally go to the script and to the design of visitor behavior.
It took me an hour to convince the client representative that I was right.
The system is designed so that after validation of the cardholder, the script receives the balance of bonuses on the card account and other data. Accordingly, in the memory of the script on the side of the store is recorded information about the available amount of bonuses.
An attacker may deliberately try to deceive the store at this moment, for example, by spending some bonuses on replenishing a mobile phone, so I provided for a second inquiry on the balance, after pressing the “pay” button.
The current reality of online stores is such that the goods ordered by the visitor may not be available. Accordingly, such cases need to be provided in the logic of the program, which sends data to the server system.
I recommended the function of reserving funds in the visitor’s account, in cases where he pays the order with bonus funds. Money must leave the client’s account , and fall into a buffer, waiting for confirmation from the operator, who, based on the situation, either cancels the operation or confirms.
Naturally, there is a complete replacement of the order, with the possibility of the operator in a telephone mode (from customers on the wire) withdraw bonus funds from the customer's account.
This feature came at the very last moment. The fact is that not only visitors are mistaken, but also operators. It is not a secret for anyone that it is simpler to simple to make a mistake or to enter something incorrectly. I recommended to add the following checkbox for the admin in the script engine functionality: “I confirm that I have repeated the card data to the visitor”. Funny is the fact that in this case, the usability of the checkbox should be terrible - only when clicking on the box itself. Only by ticking the operator will be able to make further changes to the order.
This function is a small trifle, but it will save a lot of nerves to operators and store owners because of the proceedings and refunds.
Some of the above functions may seem trivial or trivial to someone. I want to notice only one thing, namely such trifling banalities and are lost sight of, during the first launch of a new service or even an entire online store. Most likely, I could not foresee all the problems that would arise in this process, but at least reduced their number.
I realize that in my terms and approach there is a share of lamerism, but I think that, in general, this did not greatly affect the result.
For owners of online stores, I added a check-list of some points that are forgotten when connecting to any third-party scripts, or entering into an agreement with some club system:
As a result, a lot of problems arose when testing the process of activating a card by a potential owner. Briefly - 3 steps with a return one step, 2 steps for further logging into the system, inconvenient input of an inconvenient password. As a result, the predicted efficiency - a maximum of 10%. This is all a consequence of the lack of visitor behavior design.
I was told to describe “the logic of how the window for entering the card number and the crediting of bonuses with a visitor work”. The way the whole structure works at the moment (I'm afraid to name the system).
')
I dubbed this “design of visitor behavior”, I divided it into three parts: a visitor without a card + a card operator’s registration, a visitor credits bonuses to a card, a visitor pays with a card.
In theory, all this should have been in one document, since All this description of the process of a single script. But the combination of logics would be very cumbersome and inconvenient to learn, especially - people far from IT.
At the beginning of work, the “main” of this entire enterprise, after my explanations and price, issued: “yes, I’ll draw this on a knee with some shop owner for a beer”. Offended, honestly. As a result, the process that takes no more than one minute for a visitor was described in 4 days completely allocated for this work.
The final option and my recommendations showed not only the bottlenecks, but the fact that the script on the side of the store should be completely redone, and in the form in which it now works, there are all prerequisites for frauds, as well as errors when crediting bonuses into the account.
For myself, I set the task to make the process of working with a card in the interface of an online store as simple as possible, protected from errors and sabotage, clearly describe the behavior of field operators. And it is MANDATORY so that in case of any problems the visitor can solve them quickly, without hysterics. After all, problems directly affect the conversion in the store, if the process of interacting with the window for entering the card will be difficult - this will immediately affect the conversion. And the club system, in general, will lose participants.
It turned out that in the designed behavior (hereinafter I will briefly call it “logic”), there are 3 groups of so-called stakeholders. That is, the subjects who take part in the process. Operator, visitor and script. The latter also performs important actions in logic, so I also included him in the groups of stakeholders.
Describe the whole process does not make sense. You can look at the scheme according to which you made the logic at this link , here is only the simplest of the three scenarios of behavior, but it is structurally clear how the rest was done.
I will describe the key points that were revealed through the design process.
Interface change
During the design process, it became clear that in addition to the field for entering the card number, a number of elements must be added to the workflow:
- A link like "No card? You will get it for free!";
- Short descriptive text;
- Support telephone;
- New input field for cardholder validation (more on this below);
- Text issued after validation of the cardholder.
In this regard, I proposed to introduce a simple pop-up, which would not be blocked by browsers and specials. programs, with dimming the main window. No new windows popup, new tabs and so on. We must not forget that the ordering process should be linear , that is, the visitor smoothly moved from one window to another without any significant process changes.
Plus such a trifle as the preset repeating digits of the card: 9800000000000 (further there is a changing three-digit number).
Validation of the cardholder
This question can be solved in two ways. Linking the card to the visitor's account in the store. It only works if you distribute cards to your customers. Once tied (either the operator or the visitor himself) and then forgot about repeated validation, which greatly simplifies the life of customers of a particular store. But, this is already a disassembly of the store itself, respectively, its money for the revision of the functional under the card binding, the bonus card system will not be paid for this.
The second option is repeated validation. Each time the visitor produces the same sequence if he plans to use the card.
The first method does not exclude the second, since Club Bonus program means that there are other cardholders who are not your customers.
Validation will occur via SMS, the visitor will need to enter the code from the SMS. It would seem that everything is simple, "they did it a hundred times." In fact, there are several points that need to be considered:
- Smska did not come, what should the visitor do? This is where the need for a support number appears.
- Sms came, but to another person (entered incorrectly or someone is abusing), it is necessary to think that there should be, besides the validation number in the sms, so that people do not worry about their money.
When I handed over the work to the customer’s representative, we started a dispute about the need to validate the cardholder, provided that the client simply wants to credit the money to the bonus account. It would seem, why is there validation? No one wants to credit money to someone else’s account.
I insisted on validation, my arguments were:
- It is necessary to warn programmatically visitors from their mistakes with incorrect card input, I have not seen any other method besides validation; (reading Alan Cooper, found confirmation of his thoughts at the very beginning of the book) ;
- The script does not know what operation the visitor wants to perform, so input of additional steps is necessary, such as checkbox “I want to spend bonuses”;
- Many visitors will want to spend bonuses. Therefore, requests for checkbox will be the vast majority. At the same time, the same majority absolutely do not know how many bonuses are in the account;
- From the previous paragraph, there is the problem of checking bonuses on the account, which implies mandatory validation;
- The client retorted the fact that they make a payment system, and, for example, most webmoney users know how much money they have in their account. Here, by the way, the key feature of the future of this club card crept in. The user uses the webman to pay for the goods , while he buys the goods, using a card , to receive or spend bonuses. And based on the method and principles of the distribution of the card, the audience will perceive it as a bonus, as the client will then work with changing the association I do not understand (sorry for the lyrical digression) ;
- Additional steps complicate conversion. Everyone understands - more steps, lower conversion;
- Online stores like to put on any super-duper-hyper club cards, if they reduce the conversion of visitors. As follows from the preceding paragraphs, the complexity of the process is obvious, and many stores will be against such difficulties.
The complication of the process is obvious, and there is a bunch of conditions that will naturally go to the script and to the design of visitor behavior.
It took me an hour to convince the client representative that I was right.
Confirming the amount of bonuses on the account
The system is designed so that after validation of the cardholder, the script receives the balance of bonuses on the card account and other data. Accordingly, in the memory of the script on the side of the store is recorded information about the available amount of bonuses.
An attacker may deliberately try to deceive the store at this moment, for example, by spending some bonuses on replenishing a mobile phone, so I provided for a second inquiry on the balance, after pressing the “pay” button.
Bonus funds reservation function
The current reality of online stores is such that the goods ordered by the visitor may not be available. Accordingly, such cases need to be provided in the logic of the program, which sends data to the server system.
I recommended the function of reserving funds in the visitor’s account, in cases where he pays the order with bonus funds. Money must leave the client’s account , and fall into a buffer, waiting for confirmation from the operator, who, based on the situation, either cancels the operation or confirms.
Naturally, there is a complete replacement of the order, with the possibility of the operator in a telephone mode (from customers on the wire) withdraw bonus funds from the customer's account.
Rescue managers
This feature came at the very last moment. The fact is that not only visitors are mistaken, but also operators. It is not a secret for anyone that it is simpler to simple to make a mistake or to enter something incorrectly. I recommended to add the following checkbox for the admin in the script engine functionality: “I confirm that I have repeated the card data to the visitor”. Funny is the fact that in this case, the usability of the checkbox should be terrible - only when clicking on the box itself. Only by ticking the operator will be able to make further changes to the order.
This function is a small trifle, but it will save a lot of nerves to operators and store owners because of the proceedings and refunds.
Total
Some of the above functions may seem trivial or trivial to someone. I want to notice only one thing, namely such trifling banalities and are lost sight of, during the first launch of a new service or even an entire online store. Most likely, I could not foresee all the problems that would arise in this process, but at least reduced their number.
I realize that in my terms and approach there is a share of lamerism, but I think that, in general, this did not greatly affect the result.
For owners of online stores, I added a check-list of some points that are forgotten when connecting to any third-party scripts, or entering into an agreement with some club system:
- Check the contract so that it is clearly stated who is responsible for the money received from the store (customers' money);
- Carefully read the section with the termination of the contract. Who will owe what and to whom;
- Think hard about what happens if the store logs out? In the case of my client, the store has the opportunity to simply pay for using the system, as a kind of service. Termination of the program will be a painful process for your customers;
- Examine the system's money-back process for you. Terms, commissions and so on.
- Carefully study the usability and interface of the proposed script. Future conversion may be very dependent on it.
Source: https://habr.com/ru/post/120268/
All Articles