Common truths
Interview with Larry Tesler from the book Designing for Interaction .
Larry Tesler is a veteran of the GUI development industry.
Worked at Xerox PARC, Apple Computer, Amazon.com, and Yahoo!
Inventor of the Cut & Paste operation, context menu.
')
Only one. Do design for users.
At the time of the birth of the GUI, when I was working at Xerox PARC, the idea of ​​user interface uniformity was new and controversial. Many of us understood that homogeneity would benefit not only users, but also developers, since typical elements can be moved to shared libraries. We have put forward an economic argument: if we are developing on the basis of standard elements and encourage uniformity, we can reduce time to market and the size of the code.
In 1983-85, when I worked at MacApp and worked on an object-oriented framework for Apple, I advocated a three-layer code model. In addition to the Macintosh Toolbox (shared library) and the framework itself, I made an intermediate layer, which was, as I called it, the “base application”. The basic application was a real interactive program - with windows, menus and commands, but did not have its own functionality, but only provided a standard way to perform typical actions. Let's say you could create, open, save and print documents in it, but the documents had no content. You could create your own application by changing the “base”, as is customary with the object-oriented approach.
To sell the idea of ​​Apple and other developers, I came up with the “Law of Preservation of Complexity”. I assumed that each application has an irreducible complexity factor. The only question is to whom it concerns more (i.e., the program is easy to develop but difficult to use, or vice versa - comment of the translator).
Since the computers were then small, slow and expensive, and the programs were designed to be compact, the software was not easy to use. The complexity of the software had to be fought by the user and not by the programmer. But commercial software is written only once and used by millions. If millions of users lose a minute a day to deal with a problem that the engineer could have eliminated in a week, simply by making the software a little more difficult to develop but easy to use, you are punishing the user for messing with your engineer.
Whose time is more important to the success of your business? For the mass software market, if you do not have a stable monopoly position, customer time should be more important to you than your own.
The idea of ​​object-oriented programming developed by Trygve Reenskaug at PARC, as well as the idea of ​​a “base application” that I developed with my MacApp team, made an investment in software convenience more acceptable to developers because allowed to simplify their work. The more complexity lies at a low level of the software hierarchy (in development), the less it will remain at the top level (i.e., for end users, for example, a translator). MacApp had a slogan: “If you make life easier for our general users, we will make it easier for you to develop.”
The mistakes that novice designers make vary a great deal, in part they are related to their learning. Some teachers, especially in computer science departments, tell their students what to design “for themselves”. If you take it literally, then this advice leads to the GUI, which is convenient only for students of computer faculties.
I believe that only if you learn to put yourself in the user's place, then you will be able to design “for yourself” and in fact you will design for the user. I call this approach “the designer’s method” because in meaning it is similar to Stanislavsky’s “method of getting used” (“Method Design” / “Method acting” - translator’s comment). In fact, you are not designing for yourself. You design for "your character." Of course, for the success of this method, you must know your character. This is one of the reasons why designers should take into account ethnographic research and usability.
Beginners often succumb to management pressure to save and skip usability tests, despite serious unresolved issues. On the other hand, newcomers sometimes run many more tests than necessary, try to cover too many areas, spend too much time preparing official reports, or are unable to defend their point of view. Usability testing should always be completed before the designer approves all the controversial interface elements. But testing should be done in the cheapest possible way.
Of course, it is sometimes necessary to demonstrate the value of research for skeptics. In this case, it is worth taking a couple of hours to prepare a video that emphasizes the seriousness of user confusion.
Two other mistakes that novice designers make more often experienced ones are ignoring standards or, on the contrary, blindly following standards. Standards are usually a blessing, so you need a very good reason for moving away from standards. Until you make sure that it is really more convenient for users to work with non-standard GUI elements, you cannot be sure that their application is justified.
The choice of words is of great importance. Shorter is usually better. But if you have to explain to many users what “x” means (or even worse, to your teammates), then you should probably replace the word “x” with the ones that you described in the explanations.
In my opinion, the main thing that separates the expert from the novice designer is the opportunity to choose the appropriate solution from the larger number of possible. Looking at the same problem, a beginner and an expert can first of all think about the same solution, say, a multi-page GUI with numerous forms. But the newcomer is likely to focus on the solution, even if it is excessively complex. An experienced designer will consider radical alternatives, say, the ability of the user to see the data as it will look in the final state and edit it in place.
An experienced designer will not stop until the design is simple enough for the user. Not necessarily this work will take several months. This may take several days or hours, even seconds. A great design often takes a lot of time, but it’s not wasteful, and the cost of a design that isn’t simple enough to enter the final product.
Larry Tesler is a veteran of the GUI development industry.
Worked at Xerox PARC, Apple Computer, Amazon.com, and Yahoo!
Inventor of the Cut & Paste operation, context menu.
')
?Only one. Do design for users.
?At the time of the birth of the GUI, when I was working at Xerox PARC, the idea of ​​user interface uniformity was new and controversial. Many of us understood that homogeneity would benefit not only users, but also developers, since typical elements can be moved to shared libraries. We have put forward an economic argument: if we are developing on the basis of standard elements and encourage uniformity, we can reduce time to market and the size of the code.
In 1983-85, when I worked at MacApp and worked on an object-oriented framework for Apple, I advocated a three-layer code model. In addition to the Macintosh Toolbox (shared library) and the framework itself, I made an intermediate layer, which was, as I called it, the “base application”. The basic application was a real interactive program - with windows, menus and commands, but did not have its own functionality, but only provided a standard way to perform typical actions. Let's say you could create, open, save and print documents in it, but the documents had no content. You could create your own application by changing the “base”, as is customary with the object-oriented approach.
To sell the idea of ​​Apple and other developers, I came up with the “Law of Preservation of Complexity”. I assumed that each application has an irreducible complexity factor. The only question is to whom it concerns more (i.e., the program is easy to develop but difficult to use, or vice versa - comment of the translator).
Since the computers were then small, slow and expensive, and the programs were designed to be compact, the software was not easy to use. The complexity of the software had to be fought by the user and not by the programmer. But commercial software is written only once and used by millions. If millions of users lose a minute a day to deal with a problem that the engineer could have eliminated in a week, simply by making the software a little more difficult to develop but easy to use, you are punishing the user for messing with your engineer.
Whose time is more important to the success of your business? For the mass software market, if you do not have a stable monopoly position, customer time should be more important to you than your own.
The idea of ​​object-oriented programming developed by Trygve Reenskaug at PARC, as well as the idea of ​​a “base application” that I developed with my MacApp team, made an investment in software convenience more acceptable to developers because allowed to simplify their work. The more complexity lies at a low level of the software hierarchy (in development), the less it will remain at the top level (i.e., for end users, for example, a translator). MacApp had a slogan: “If you make life easier for our general users, we will make it easier for you to develop.”
, GUI?The mistakes that novice designers make vary a great deal, in part they are related to their learning. Some teachers, especially in computer science departments, tell their students what to design “for themselves”. If you take it literally, then this advice leads to the GUI, which is convenient only for students of computer faculties.
I believe that only if you learn to put yourself in the user's place, then you will be able to design “for yourself” and in fact you will design for the user. I call this approach “the designer’s method” because in meaning it is similar to Stanislavsky’s “method of getting used” (“Method Design” / “Method acting” - translator’s comment). In fact, you are not designing for yourself. You design for "your character." Of course, for the success of this method, you must know your character. This is one of the reasons why designers should take into account ethnographic research and usability.
Beginners often succumb to management pressure to save and skip usability tests, despite serious unresolved issues. On the other hand, newcomers sometimes run many more tests than necessary, try to cover too many areas, spend too much time preparing official reports, or are unable to defend their point of view. Usability testing should always be completed before the designer approves all the controversial interface elements. But testing should be done in the cheapest possible way.
Of course, it is sometimes necessary to demonstrate the value of research for skeptics. In this case, it is worth taking a couple of hours to prepare a video that emphasizes the seriousness of user confusion.
Two other mistakes that novice designers make more often experienced ones are ignoring standards or, on the contrary, blindly following standards. Standards are usually a blessing, so you need a very good reason for moving away from standards. Until you make sure that it is really more convenient for users to work with non-standard GUI elements, you cannot be sure that their application is justified.
The choice of words is of great importance. Shorter is usually better. But if you have to explain to many users what “x” means (or even worse, to your teammates), then you should probably replace the word “x” with the ones that you described in the explanations.
In my opinion, the main thing that separates the expert from the novice designer is the opportunity to choose the appropriate solution from the larger number of possible. Looking at the same problem, a beginner and an expert can first of all think about the same solution, say, a multi-page GUI with numerous forms. But the newcomer is likely to focus on the solution, even if it is excessively complex. An experienced designer will consider radical alternatives, say, the ability of the user to see the data as it will look in the final state and edit it in place.
An experienced designer will not stop until the design is simple enough for the user. Not necessarily this work will take several months. This may take several days or hours, even seconds. A great design often takes a lot of time, but it’s not wasteful, and the cost of a design that isn’t simple enough to enter the final product.
Source: https://habr.com/ru/post/130389/
All Articles