It is relatively easy to design for the situation where everything goes well, where people use the device in the way that was intended, and no unforeseen events occur. The tricky part is to design for when things go wrong.
Consider a conversation between two people. Are errors made? Yes, but they are not treated as such. If a person says something that is not understandable, we ask for clarification. If a person says something that we believe to be false, we question and debate. We don’t issue a warning signal. We don’t beep. We don’t give error messages. We ask for more information and engage in mutual dialogue to reach an understanding. In normal conversations between two friends, misstatements are taken as normal, as approximations to what was really meant. Grammatical errors, self-corrections, and restarted phrases are ignored. In fact, they are usually not even detected because we concentrate upon the intended meaning, not the surface features.
One of my rules in consulting is simple: never solve the problem I am asked to solve. Why such a counterintuitive rule? Because, invariably, the problem I am asked to solve is not the real, fundamental, root problem. It is usually a symptom. In design, the secret to success is to understand what the real problem is.
Communication is especially important when things go wrong. It is relatively easy to design things what work smoothly and harmoniously as long as things go right. But as soon as there is a problem or a misunderstanding, the problem arise. This is where good design is essential. Designers need to focus their attention on the cases where things go wrong, not just on when things work as planned. Actually, this is where the most satisfaction can arise: when something goes wrong but the machine highlights the problems, then the person understands the issue, takes the proper actions, and the problem is solved. When this happens smoothly, the collaboration of person and device feels wonderful.
He pulled together a team of 40 employees, took them off their usual job, and placed them in a room with LG’s best-selling washing machine. Take this thing apart, he told them, and examine every screw and bolt and determine if it deserves to be there. Then rebuild it from scratch. But don’t rebuild the same machine. Rebuild it as the best washing machine anyone could ever want.
The team went to work. Their task wasn’t just to design a new washing machine. It was to create a new process for building such a machine. That meant supply chains had to be designed and set up for each part. The layout of the factory floor had to be drawn out in every detail, and every motion of each worker had to be choreographed in advance. Shipping routes, in-store marketing material, and after-market warranty servicing work had to be planned in advance.
We concluded that cars are the means to a sort of dream fulfillment. There’s some irrational factor in people that makes them want one kind of car rather than another — something that has nothing to do with the mechanism at all but with the car’s personality, as the customers imagines it.
What kind of order? Why of course, the kind that reflects the designer’s view of the world as she feels it should be. Her choices can be understood as an expression of her particular ideas of the way the world should function. It’s a small, limited form of tyranny imposed on an even smaller corner of the world.
On the other hand, a user of an interactive system can sense that the features of that system — its content, its tools, its navigation — are constructed according to some overarching design. If he encounters some evidence that there is order in place, his confidence in and sense of ease with the system increases dramatically. An ordering system need not announce itself, and it may never be consciously understood, but its presence is nevertheless significant.
We first judge truly good design not by its beauty or its innovativeness or its efficiency, but rather by how well it responds to its original problem. Successful solutions demand that the designer grasp the problem presented to her and the constraints within which she’s working. The designer has to ask and understand the answer to questions such as: who is the audience, what is the context, when will the solution be encountered, how will the solution be used — and even why is the solution necessary?
These kinds of constraints might appear to limit the options available to a designer, they very often also have the effect of increasing a designer’s inventiveness. The more wide open a design problem and the less restrictive the constraints, the less a designer is likely to make those insightful leaps of logic that are the hallmark of great design. Nonnegotiable constraints can help spur a designer to do this.
Type is saying things to us all the time. Typefaces express a mood, an atmosphere. They give words a certain coloring.
Typography is also the mechanized presentation of language. In this way it is subservient to the structures of the messages it presents.
- Readers come first, second, and third. Designing is not done for peer approval or prizes.
- Readers are neither “target audiences” nor cliches: they bring their own purposes and questions to every encounter with text.
- “Reading” is not one-dimensional: there are many reading acts.
- Content matters: design nothing that is not worth reading.
- Stand by meaning.
- Embrace the big picture.
- Attend to details.
- Looking good is better than looking different.
- Looking good is worthless without making sense.
An erroneous conception of the graphic designer’s function is to imagine that in order to produce a “good layout” all he need do is make a pleasing arrangement of miscellaneous elements. What is implied is that this may be accomplished simply by pushing these elements around, until something happens. At best, this procedure involves the time-consuming uncertainties of trial and error, and at worst, an indifference to plan, order, or discipline.
The designer does not, as a rule, begin with some preconceived idea. Rather, the idea is (or should be) the result of careful study and observation, and the design a product of that idea. In order, therefore, to achieve an effective solution to his problem, the designer must necessarily go through some sort of mental process. Consciously or not, he analyzes, interprets, formulates. He is aware of the scientific and technological developments in his own and kindred fields. He improvises, invents, or discovers new techniques and combinations. He co-ordinates and integrates his material so that he may restate his problem in terms of ideas, signs, symbols, pictures. He unifies, simplifies, and eliminates superfluities. He symbolizes — abstracts from his material by association and analogy. He intensifies and reinforces his symbol with appropriate accessories to achieve clarity and interest. He draws upon instinct and intuition. He considers the spectator, his feelings and predilections.
Frequently, trite ideas or unimaginative translation of those ideas is the result not of poor subject matter but of poor interpretation of a problem. In the absence of a fresh, visual solution, subject matter sometimes becomes the scapegoat. Such difficulties may arise if: a) the designer has interpreted a commonplace idea with a common place image; b) he has failed to resolve the problem of integrating form and content; or c) he has failed to interpret the problem as a two-dimensional organization in a given space. He has thus deprived his visual image of the potential to suggest, perhaps, more than the eye can see. And he has denied himself the opportunity of saying the commonplace in an uncommonplace way.
An ugly system is one in which there are special interfaces for everything you want to do. Unix is the opposite. It gives you the building blocks that are sufficient for doing everything. That’s what having a clean design is all about.
It’s the same thing with languages. The English language has 26 letters and you can build up everything from those letters. Or you have the Chinese language, in which you have one letter for every single thing you can think of. In Chinese, you start off with complexity, and you can combine complexity in limited ways. That’s more of the VMS approach, to have complex things that have interesting meanings but can’t be used in any other way. It’s also the Windows approach.
The theory behind the microkernel is that OS are complicated. So you try to get some of the complexity out by modularizing it a lot. The tenet of the microkernel approach is that the kernel, which is the core of the core, should do as little as possible. Its main function is to communicate. All the different things that the computer offers are services that are available through the microkernel communication channels. In the microkernel approach, you’re supposed to split up the problem space so much that none of it is complex.
I thought this was stupid. Yes, it makes every single piece simple. But the interactions make it far more complex than it would be if many of the services were included in the kernel itself, as they are in Linux. Think of your brain. Every single piece is simple, but the interactions between the pieces make for a highly complex system. It’s the whole-is-bigger-than-the-parts problem. If you take a problem and split it in half and say that the halves are half as complicated, you’re ignoring the fact that you have to add in the complication of communication between the two halves. The theory behind the microkernel was that you split the kernel into fifty independent parts, and each of the parts is a fiftieth of the complexity. But then everybody ignores the fact that the communication among the parts is actually more complicated than the original system was — never mind the fact that the parts are still not trivial.
That’s the biggest argument against microkernels. The simplicity you try to reach is a false simplicity.
Nobody wants an OS. In fact, nobody even wants a computer. What everybody wants is this magical toy that can be used to browse the web, write term papers, play games, balance the checkbook, and so on.
Good design brings absolute attention to data.
These problems are more than just poor design, for a lack of visual clarity in arranging evidence is a sign of a lack of intellectual clarity in reasoning about evidence.
If displays of data are to be truthful and revealing, then the design logic of the display must reflect the intellectual logic of the analysis.
Also, drawings sometimes have a useful abstracting, idealizing quality; a generic heart is depicted, not a particular or idiosyncratic heart.
Although movement attracts attention, it also diminishes visibility.
The first rule to be borne in mind by the aspirant magician is this: “Never tell your audience beforehand what you are going to do.” If you do so, you at once give their vigilance the direction which it is most necessary to avoid, and increase ten-fold the chances of detection. It follows that you should never perform the same trick twice on the same evening. The audience knows precisely what is coming, and have all their faculties directed to find out at what point you cheated their eyes on the first occasion.
These techniques of disinformation design, when reversed, reinforce strategies of presentation used by good teachers. Your audience should know beforehand what you are going to do; then they can evaluate how your verbal and visual evidence supports your argument.
Another weak approach is to make the interface itself a conspicuous visual statement, with a great deal of creative effort going into styling a billboard that masks a data dump. Believed to be boring and in need of decorative spice, the content becomes trivialized and incidental. Too many interfaces for information compilations have suffered from television-disease: thin substance, contempt for the audience and the content, short attention span, and over-produced styling.
One of the most important goals of good design is for a system to be obvious. This is the opposite of high cognitive load and unknown unknowns.
Good design doesn’t come for free. It has to be something you invest in continually, so that small problems don’t accumulate into big ones. Fortunately, good design eventually pays for itself, and sooner than you might think.
It’s crucial to be consistent in applying the strategic approach and to think of investment as something to do today, not tomorrow. The longer you wait to address design problems, the bigger they become; the solutions become more intimidating, which makes it easy to put them off even more. The most effective approach is one where every engineer makes continuous small investments in good design.
I have noticed that the design-it-twice principle is sometimes hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third possibility. This makes it easy to develop bad work habits. However, as these people get older, they get promoted into environments with harder and harder problems. Eventually, everyone reaches a point where your first ideas are no longer good enough; if you want to get really great results, you have to consider a second possibility, or perhaps a third, no matter how smart you are. The design of large software systems falls in this category: no one is good enough to get it right with their first try.
Design patterns represent an alternative to design: rather than designing a new mechanism from scratch, just apply a well-known design pattern. For the most part, this is good: design patterns arose because they solve common problems, and because they are generally agreed to provide clean solutions. If a design pattern works well in a particular situation, it will probably be hard for you to come up with a different approach that is better.
The greatest risk with design patterns is over-application. Not every problem can be solved cleanly with an existing design pattern; don’t try to force a problem into a design pattern when a custom approach will be cleaner.
The reward for being a good designer is that you get to spend a larger fraction of your time in the design phase, which is fun. Poor designers spend most of their time chasing bugs in complicated and brittle code. If you improve your design skills, not only will you produce higher quality software more quickly, but the software development process will be more enjoyable.
content locates typography
space, location, linebreaks create and clarify meaning
Design is iterative; almost never does a complete fully-fleshed out design pop into the designer’s head. Instead, design is a series of inspirations, tests, failures, analyses, recombinations, reinventions, retries, more failures, and finally success.