In essence, patterns are structural and behavioral features that improve the “habitabil-
ity” of something—a user interface, a website, an object-oriented program, or a building.
They make things easier to understand or more beautiful; they make tools more useful
and usable.
As such, patterns can be a description of best practices within a given design domain.
They capture common solutions to design tensions (usually called “forces” in pattern lit-
erature) and thus, by definition, are not novel. They aren’t off-the-shelf components; each
implementation of a pattern differs a little from every other. They aren’t simple rules or
heuristics either. And they won’t walk you through an entire set of design decisions—if
you’re looking for a complete step-by-step description of how to design an interface, a
pattern catalog isn’t the place to find it!
Patterns are:
Concrete, not general
All designers depend upon good design principles, like “Prevent errors,” “Create a
strong visual hierarchy,” and “Don’t make the user think.” It’s rather hard, however,
to design an actual working interface starting from fundamental principles! Patterns
are concrete enough to help fill the space between high-level general principles and
the low-level “grammar” of user interface design (widgets, text, graphic elements,
alignment grids, and so on).
Valid across different platforms and systems
Patterns may be more concrete than principles or heuristics, but they do define ab-
stractions—the best patterns aren’t specific to a single platform or idiom. Some even
work in both print and interactive systems. Ideally, each pattern captures some minor
truth about how people work best with a created artifact, and it remains true even
while the underlying technologies and media change.
Products, not processes
Unlike heuristics or user-centered design techniques, which usually advise on how to
go about finding a solution to an engineering or design problem, patterns are possible
solutions.
Suggestions, not requirements
You should almost always follow good design principles and heuristics, of course.
And organizations need designers to follow style guides so that their products stay
self-consistent. But patterns are intended to be only suggestions; you can follow them
or reject them, depending on your design context and user needs.
Relationships among elements, not single elements
A text field is not a pattern. The spatial relationships between a text field and a piece
of help text near it, however, might be a pattern. Likewise, changes in a set of elements
over time—as a user interacts with the software—may constitute a pattern, though
some patterns capture only static relationships.
Customized to each design context
When a pattern is instantiated in a design, the designer should adjust the pattern as
needed to fit the situation. You could use some of the pattern examples verbatim, but
as long as you understand why the pattern works, why not be creative? Fit the pattern
to your particular users and requirements.
Some very complete sets of patterns make up a “pattern language.” These patterns resem-
ble visual languages in that they cover the entire vocabulary of elements used in a design
(though pattern languages are more abstract and behavioral; visual languages talk about
shapes, icons, colors, fonts, etc.). The set in this book isn’t nearly as complete, and it con-
tains techniques that don’t qualify as traditional patterns. But at least it’s concise enough
to be manageable and useful.
ity” of something—a user interface, a website, an object-oriented program, or a building.
They make things easier to understand or more beautiful; they make tools more useful
and usable.
As such, patterns can be a description of best practices within a given design domain.
They capture common solutions to design tensions (usually called “forces” in pattern lit-
erature) and thus, by definition, are not novel. They aren’t off-the-shelf components; each
implementation of a pattern differs a little from every other. They aren’t simple rules or
heuristics either. And they won’t walk you through an entire set of design decisions—if
you’re looking for a complete step-by-step description of how to design an interface, a
pattern catalog isn’t the place to find it!
Patterns are:
Concrete, not general
All designers depend upon good design principles, like “Prevent errors,” “Create a
strong visual hierarchy,” and “Don’t make the user think.” It’s rather hard, however,
to design an actual working interface starting from fundamental principles! Patterns
are concrete enough to help fill the space between high-level general principles and
the low-level “grammar” of user interface design (widgets, text, graphic elements,
alignment grids, and so on).
Valid across different platforms and systems
Patterns may be more concrete than principles or heuristics, but they do define ab-
stractions—the best patterns aren’t specific to a single platform or idiom. Some even
work in both print and interactive systems. Ideally, each pattern captures some minor
truth about how people work best with a created artifact, and it remains true even
while the underlying technologies and media change.
Products, not processes
Unlike heuristics or user-centered design techniques, which usually advise on how to
go about finding a solution to an engineering or design problem, patterns are possible
solutions.
Suggestions, not requirements
You should almost always follow good design principles and heuristics, of course.
And organizations need designers to follow style guides so that their products stay
self-consistent. But patterns are intended to be only suggestions; you can follow them
or reject them, depending on your design context and user needs.
Relationships among elements, not single elements
A text field is not a pattern. The spatial relationships between a text field and a piece
of help text near it, however, might be a pattern. Likewise, changes in a set of elements
over time—as a user interacts with the software—may constitute a pattern, though
some patterns capture only static relationships.
Customized to each design context
When a pattern is instantiated in a design, the designer should adjust the pattern as
needed to fit the situation. You could use some of the pattern examples verbatim, but
as long as you understand why the pattern works, why not be creative? Fit the pattern
to your particular users and requirements.
Some very complete sets of patterns make up a “pattern language.” These patterns resem-
ble visual languages in that they cover the entire vocabulary of elements used in a design
(though pattern languages are more abstract and behavioral; visual languages talk about
shapes, icons, colors, fonts, etc.). The set in this book isn’t nearly as complete, and it con-
tains techniques that don’t qualify as traditional patterns. But at least it’s concise enough
to be manageable and useful.
No comments:
Post a Comment