Tips for an Interface Designer

Problem

The programmer often serves as a user interface designer. You can bet it is good. However, especially in small companies, this is a reality that does not change.



I believe that a programmer can make a very decent interface. In this post, I would like to collect some tips that will help the programmer more or less successfully dive into the irrational world of users and design good interfaces.



I will make a reservation that these tips are more suitable for programmers who are forced to develop a user interface. That is, for any reason, the company has no designer, regular usability testing, interface design process, etc.

')

Simplicity

User tasks Any interface is evil. The user does not use the product for the sake of the product, but in order to solve some of its problem. For example, we use the phone number dialing interface not to dial a number, but to talk to another person. The very fact of recruitment is a necessary operation that technology imposes.

Thus, by creating each form, dialogue or panel, I constantly ask myself the question: “What task of the user do I solve now?”. If it turns out that I am trying to solve several problems with one form (or panel), then most likely something is wrong. In such cases, you need to think about what is the main function, and what features are “not for everyone”.



Rule 20/80. As you know, 20% of efforts give 80% of the result. Often, for tasks 80% of users, 20% of forms / dialogs / panels are enough. So, when creating an interface, you have to be very careful when choosing those twenty key percent.

Before adding another button, checkbox, field, link, I try to answer the question: “will 80% of users use this function?”. If not, then progressive disclosure technology comes to the rescue.

For example, here's the settings panel from Firefox:



It is clear that most users block pop-ups and allow downloading images from anywhere. Only a small number of manually indicate exclusion sites.



Explained. The interface can be called simple, if it does not require further clarification. That is, if for further actions it is necessary to read a small text explaining what's what, then it is very likely that the interface is too complicated. In such cases, I think about whether it is possible to make a more interactive control, whether it is worth splitting the process into several steps, adding an explanatory picture, and so on.

For example, to configure the touchpad on MacBooks looks like this:



That is, an explanatory text like “forward movement with three fingers on the touchpad moves some applications to the next page” was replaced by a small video, from which everything is clear.



Unnecessary questions. Often the interface asks the user about something. Usually this is a pop-up with the “OK” and “Cancel” buttons. Sometimes the question is quite relevant. However, in most cases the question only hinders. War pop-apam declared long ago. Nevertheless, I would like to cite the most popular types of unnecessary questions:

1. A question that only 20% of users can understand.
   
   For example:
   
   
   
   Those who are familiar with what keychain is will understand the question and answer it correctly. However, most users will likely shrug and click “Allow”.
   
   
2. A question not related to the current task. It happens very often: you work with a program, and a pop-up appears:
   
   
   
   It makes you forget about the current task and urgently make a completely unexpected decision.
   
   
3. The question that the system can easily answer itself. For example, when deleting a file from a temporary folder, you must answer the question:
   
   
   
   The system knows that this file is temporary and not very necessary. Moreover, the user can always restore it.

Undo. People are wrong. The app should be ready for this. Ideally, it should be possible to cancel any user action. Each time a user makes a decision (for example, he chooses the username, deletes the file or changes the configuration), he may make a mistake. It is very sad if the system does not allow to correct this error.

I would also like to point out that one cannot rely on questions like “Are you sure that ...?” Or warnings, “Attention! This action will lead to ...! ”. Firstly, not everyone reads them, and, secondly, of those who read, not everyone really understands what the system means.

Uniformity

Often modest, neat interface is much more pleasant to the eye than the richly decorated and heavily animated. The easiest way to make an attractive interface is to try to do everything the same.



Components. Buttons, checkboxes, text fields, etc. should look the same across the application. Very sloppy components look very similar to each other. For example, it is bad if sometimes the progress bar is in a black frame, and sometimes in a gray one. Well, if the progress bar is always implemented by the same component and always looks the same.



Behavior. In different situations, the same components should behave similarly. For example, the back button should always return to the previous page. Or, if the green button always opens an additional dialog box, then it must open it in all contexts.



The location of the components. The interface looks very messy if the components are not scattered around. If you draw several lines and place components on them, the interface will look much neater. For example:

It can be seen how the components are combined with each other along horizontal and vertical lines.



The design of the text. Pay attention to the labels! It is necessary to develop and adhere to the rules, where and what is written with a capital letter, where dots are put (...), where dots are put. It is very important to name the objects of the system in the same way: if somewhere there is a menu “parameters”, then in another place this menu cannot be called “options”.



Style. Fonts, colors, icons - everything should be as much as possible for the entire application. It is not necessary to introduce into the system new typefaces or new types of fonts. It is necessary to adhere to the primary colors (often, these colors are the "colors of the company"). Icons should have the same style (for example, if icons are used everywhere in the form of black-and-white silhouettes, you should not add a new color three-dimensional icon).

Communication

The classic remark that programmers often do not understand how users use the product is, alas, not very far from the truth. Ideally, you can arrange a record of user interaction with the program, analyze it, draw conclusions about the disadvantages of the interface. However, when there is no such possibility, it is useful to talk with different teams in order to get an idea of ​​what is expected of the system. I prefer conversations in an informal setting, for example, at dinner.



Product management. It seems to me that the product manager should be a loyal friend of the programmer. The technical task (aka PRD) is one of the main documents that help to understand “what is needed”. It is with the product manager that you can discuss controversial issues, ask for the necessary data to be collected, point out possible difficulties associated with implementation. It's great if the technical task contains interface sketches. This at times facilitates the understanding of what is required to create.



Support Group. I think the support group (aka support) is closest to the users of the system. It is to them that users turn when something is not clear, something does not work the way the user expects, it is they who explain how to use the system. Very often they provide ideas for new features that can make it easier to work with the product.

Reading ticket support, and just a conversation with someone really opens your eyes to the real situation.



Sales team I found it very useful to ask colleagues in the sales group (aka sales) questions about what can be changed in the interface to make the product easier to sell. Answers can be very interesting. Maybe they will point to the products of competitors, maybe they will be asked to do a "povedvanolee." Sometimes you can hear a lot of interesting things.

Conclusion

Of course, these recommendations are not complete. About the convenience of the user written books. There are experts in this field, there are many consulting companies. However, I hope that this post will make several interfaces a little simpler, more accurate, more thoughtful.



And what tips would you give to a software designer?