Different understanding of developers and users

An example of "simple" but "complicated"

When I communicate with a developer, a project needs. They frequently sigh with regret that Mockup's design is considered quite perfect. Many programs have to implement the pre-and "non-basic function points" so that the development of the personnel to be discouraged, reluctantly to achieve. In contrast, designers have to avoid the problem of error, and racking their brains to imagine and consider, developers are more inclined to directly to a can only be allowed to operate, other illegal requests are all used to make an error: "The program is rigorous, he was wrong, I error, in order to change." Isn't it nice to be simple? "Programmers even smile:" Considering their experience so much, we develop the experience is really bad, please, we can not make things very complicated ah.

In this example, the programmer seems to consider the various situations that users may have in the process of interacting with the system, looking for the most obvious, easiest, and most user-error design that is inefficient and time-consuming. Designers do this by complicating simple things. OK, now there is a question, what is "wrong"? Is the user really "making a mistake" whenever the program wants to handle the wrong request?

1. Question one, whose fault is it?

When I used a website's photo album feature one day, I encountered this situation (pictured below):

"Normal upload" is the current selected state, and the button to upload "Cancel" is the same style. Because the selected state has a "positive, OK" potential hint, so the negative operation and positive operation of the state is completely confused, users in the upload process is prone to the wrong point "Cancel" button as a confirmation of the completion of the upload task error operation.

If this is really happening (there should be a few, like I happened in the local very difficult to choose a good picture delayed like "Confirm" function "Cancel" and do not work hard situation), yes, the user made a mistake, but the responsibility is not in the user? "I didn't make mistakes, it was your design that made me wrong, or at least increased my chances of making mistakes," he said. "Similar to such errors, the system may or may not, but the real should be reviewed is the system itself, namely: User understanding of the interface and its own system intent error, system design ambiguity and other inherent defects resulting in user error." The reason why users frequently hit the wall and create frustration is not the stupidity of the user, but the stupidity of the design.

2, question two, is this not a mistake?

The 2nd of the interpretation of the word "error" is mainly aimed at the user's behavior layer of the system, that is, the user's misoperation in the Man-machine interface interaction, the system fails to reduce and avoid the loss caused by the user's misoperation through better design.

Take "Upload photos" For example (pictured below):

A modal warning box, impressively tells you, you want to upload photos here, should not use in addition to IE browser! In addition to not planning to inform you in advance, but also did not discuss, because I did not give you other alternative options and other options.

Can imagine, users want to use this upload photo function, already need to go through a lot of steps, such as to open their own albums stored online address, to successfully login into the management background, to find the upload photos of the functional modules, etc., has paid a considerable part of the operating costs. But the system is cruel to let the user all work white, not only that, but also very barbaric way to tell users: you from the beginning of the wrong! In this case, there is no error in the user's understanding of the system, but there is a serious frustration in the process of interaction. But is this really a user error and a responsibility that needs to be borne? I don't think so: "Strictly speaking, I'm not making a mistake, I'm just not sure what I can do and how to do it." ”

From the above two cases, I think that can be a preliminary answer to the programmer classmate's question: "Yes, simplicity is always good, but in the process of interaction, the event is always complex, the possibility of what may happen is always so much, not you think for him more, let him simple; More complex, worse experience. "

3, question three, how to do:

Three realms of fault tolerant design:

1, to ensure that it is not our own fault: shielding will cause ambiguity in the design, its unreasonable design, do not let users because of the system design defects caused by mistakes.

2, the simple left to the user, the complex to leave themselves: through the system of good design constraints and guide the user's operation, the possibility of the error to minimize.

3, reduce the cost of error, to help users do the right: when the user or made a mistake, through the design to guide the user to the right direction.

For interaction designers, the first is the bottom line of design that should be adhered to, and 232 is the design Guide to be followed at design time. The third article, about how to help and guide the user to do after the error, Changxuan students will then write a special article to explore this issue, here is not to repeat, the following mainly on the second article to talk about some views:

Second, how to avoid user error: 1, give users the appropriate behavior constraints--for users to close off the wrong path

This is the Gmail mail processing area.

The figure above shows that when no email is selected, the operation items are dimmed and cannot be selected. In this way, while effectively avoiding misoperation, the content of all functions provided in "more operations" is shown and predicted when the operation requirements are met.

The following figure is the case when a message is already selected, when the action item is all activated to a usable state. Compared to the previous picture is not activated state, you can note that in addition to the activation of the state difference, and the "star marking" function in the initial activation is only a raise and hide the deletion function, fully considered the add and remove functions of the mutex to be hidden.

Through the user's use state, through the Selective setting function item activation, to activate the state, as well as the function item display, hides the state, is the effective avoids the user misoperation the commonly used method. This thoughtful design has largely prevented the user from operating errors.