June 21, 2010 at Tips for an Interface Programmer
Problem
A programmer often acts as a user interface designer. One can argue whether this is good. However, especially in small companies, this is a reality that cannot be changed.
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 plunge 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 user interfaces. That is, for some reason, the company does not have a designer, regular usability testing, the process of designing interfaces, etc.
Simplicity
User Tasks Any interface is evil. The user uses the product not for the sake of the product, but in order to solve some of his problem. For example, we use the telephone dialing interface not to dial a number, but to talk with another person. The fact of recruitment is a necessary operation that technology imposes.
Thus, creating every form, dialogue or panel, I constantly ask myself the question: “what user problem do I solve now?”. If it turns out that I'm 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 is “not for everyone” features.
Rule 20/80.As you know, 20% of the effort gives 80% of the result. Often, for tasks of 80% of users, 20% of forms / dialogs / panels are enough. Therefore, when creating an interface, you need 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, the progressive disclosure technique comes to the rescue .
For example, here is the settings panel from Firefox:
It is clear that most users block pop-ups and allow downloading images from everywhere. Only a small number manually specify exception sites.
Explanations. An interface can be called simple if it does not require further explanation. 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 more interactive control, whether it is worth splitting the process into several steps, adding an explanatory picture, etc.
For example, to configure the touchpad on macbooks, it looks like this:
That is, an explanatory text like “three-finger forward movement on the touchpad moves some applications to the next page” was replaced by a small video, from which everything is clear.
Extra questions. Often the interface asks the user about something. Usually this is a pop-up with the buttons "OK" and "Cancel". Sometimes the question is quite appropriate. However, in most cases the question only gets in the way. The pop-ups declared war long ago. Nevertheless, I would like to give the most popular types of unnecessary questions:
- A question that only 20% of users can understand.
For instance:Those who are familiar with what keychain is will understand the question and answer it correctly. However, most users will most likely shrug their shoulders and click Allow.
- A question that is not relevant to the current task. This happens very often: you work with some kind of program, and here pop-up arises:This makes you forget about the current task and urgently make a completely unexpected decision.
- A question that the system may well answer itself. For example, when deleting a file from some temporary folder, you need to answer the question:The system knows that this file is temporary and not really needed. Moreover, the user can always restore it.
Undo. People are wrong. The application should be ready for this. Ideally, there should be the ability to undo any user action. Each time the user makes a decision (for example, selects a username, deletes a file or changes the configuration), he may make a mistake. It is very sad if the system does not allow to fix this error.
I would also like to note that you cannot rely on questions like “Are you sure ...?” Or warnings, “Warning! This action will lead to ...! ” Firstly, not everyone reads them, and secondly, of those who read, not everyone really understands what exactly the system means.
Uniformity
Often a modest, neat interface is much more pleasing to the eye than richly decorated and highly animated. The easiest way to make an attractive interface is to try to do everything the same way.
Components. Buttons, checkboxes, text fields, etc. should look the same throughout the application. Components very similar to each other look very messy. For example, it is bad if sometimes the progress bar is in a black frame, and sometimes in gray. It’s good 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 really in all contexts.
The location of the components. The interface looks very messy if the components are scattered randomly. If you draw several lines and place components on them, the interface will look much more neat. For instance:
Text design. Pay attention to the labels! It is worth developing and adhering to the rules where and what is written with a capital letter, where the ellipsis is placed (...), where the points are put. It is very important to name the system objects in the same way: if somewhere there is a menu of “parameters”, then in another place the same menu cannot be called “options”.
Style.Fonts, colors, icons - all this should be the same as possible for the entire application. You should not introduce new typefaces or new font styles into the system. You should stick to the primary colors (often, these colors are the "colors of the company"). Icons must have the same style (for example, if icons in the form of black and white silhouettes are used everywhere, you should not add a new color three-dimensional icon).
Communication
The classic remark that programmers often do not imagine how users use the product, alas, is not very far from the truth. Ideally, you can arrange a record of user interaction with the program, analyze it, draw conclusions about the shortcomings of the interface. However, when this is not possible, it is useful to talk with various teams to get an idea of what they expect from the system. I prefer conversations in an informal setting, for example, at lunch.
Product management.It seems to me that the product manager should be a true friend of the programmer. Terms of Reference (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 to collect the necessary data, indicate possible difficulties associated with the implementation. It is great if the terms of reference contain outline interfaces. This at times makes it easier to understand what needs to be created.
Support Group. It seems to me that the support group (aka support) is closest to the users of the system themselves. It is they who are contacted by users when something is not clear, something does not work as the user expects, it is they who explain how to use the system. Very often, they submit ideas for new functions that can greatly facilitate the work with the product.
Reading support tickets, and just talking with someone, really opens your eyes to the real situation.
Sales group. I found it very useful to ask colleagues from the sales group (aka sales) questions about what can be changed in the interface so that the product is easier to sell. The answers can be very interesting. Maybe they’ll point out the products of competitors, maybe they’ll ask to do more. Sometimes you can hear a lot of interesting things.
Conclusion
Of course, these recommendations are not complete. Books have been written about user convenience. There are experts in this field, there are many consulting companies. However, I hope that this post will make several interfaces a little easier, more accurate, more thoughtful.
What advice would you give to a programmer-designer?