Interaction Design—“Applicability” VS “Ease of Use”

[[132521]]

I believe everyone has the experience of going to a bank teller machine to withdraw money. There are many complaints about the operating details of the teller machine, such as it takes a long time to study the direction of the card insertion; the physical buttons are misaligned with the screen buttons, etc. These make people very unhappy during use and need to be improved. However, in the process of withdrawing money, there is a setting that will also make it inconvenient for users, but I think this inconvenience is necessary. "Applicable but not necessarily easy to use" is the theme I want to talk about today, because in life, there are indeed some designs that make you feel that the operation is cumbersome, it is not "easy to use", but its existence is necessary because it is "applicable".

Let’s go back to the example of the ATM. Let me first show you this comparison picture.

I guess everyone has encountered the two cash withdrawal processes AB. The biggest difference between them lies in the last step, whether you withdraw a card or cash at the end.

If we evaluate the process, A is the smoothest and most complete. The first step is to insert the card, and you can withdraw money multiple times during the process. The last step is to take the card. The operation objects at the beginning and end are both bank cards, which is a complete process. But in fact, whether it is my colleagues or my own personal experience, we have all encountered accidents where people forgot to take the card after withdrawing money, resulting in tragic property losses. In fact, if the ATM at that time used Plan B, the tragedy could have been avoided.

"Withdrawing money" is the purpose of using the ATM, so in the whole process, the user is most concerned about whether the money has been received. Once the money is in hand, the purpose is achieved, the user's task is completed, and the process is over for the user. The problem with plan A is that the user's process is not synchronized with the process required by the ATM. The step of "taking the card" is arranged after the end of the user's process, so it is easy to be overlooked. In plan B, "taking the card" is a pre-step to "withdrawing money", which is within the user's operational focus, ensuring the execution of this behavior and avoiding the occurrence of tragic events.

From the perspective of interactive design. Compared with Plan A, Plan B is inconvenient. If you want to withdraw money multiple times, you have to repeat the process multiple times, but it guarantees the execution of the "get card" step. Therefore, interactive design is not necessarily the most convenient solution, because in this usage environment, it must first ensure the least errors. Of course, under the premise of "ensuring the least errors", we still need to work towards "convenience". For example, later I found that Plan A has an optimized version, which is not as cumbersome as B, and also ensures the safety of the card. Of course, it still cannot guarantee that you will remember to take back the bank card 100%. The steps are as follows.

A2 is an improved process of A. After withdrawing money, you do not need to take out the card and reinsert it to withdraw money again. You only need to re-enter the password and amount. It is more convenient than solution B and does not interrupt the overall process. Although the "taking out the card" step is still after "withdrawing money", it has found a balance between "convenience" and "security", meeting the ultimate demand of "applicability".

The example of the ATM is a bit boring, so let's do something more interesting. This app is very suitable for lazy people. Either smash the machine or give the correct answer. Anyway, it can't let you turn off the alarm easily.

Our Gmail classmates also have a thoughtful function, here is its function description:

“Google is here to organize the world’s information and make it accessible to everyone. Maybe you sent an email late one weekend night and woke up the next morning regretting it. Now you can either answer a few simple math questions to send it, or get some sleep and send it the next morning.”

These examples tell us that interaction design must take into account different usage environments, and sometimes it is not necessarily "easy to use".