Designing “Designing

Interfaces:”
How Not to Write a Pattern Catalog

Jenifer Tidwell
UPA 2007
Wednesday, June 13
Prologue: a little history

The year was 1997.

Read “Design Patterns” (Gang
of Four) and “A Pattern
Language” (Alexander).
Developers designing UIs…

• They knew the principles of

good design.
• They understood the
importance of usability
testing.
• But they couldn’t get past
rote copying.
“Microsoft did it this
way,
Could patterns help?

“These ideas work. Pick what

you want from them, and
ignore the rest.”

“And by the way, here’s why

they work, if you’re
curious.”
• Hypertext
• Video games
• Consumer electronics
• Spoken interfaces
• Print design
• Data visualization
• Cartography
• etc…
Wanted to apply knowledge from
other fields
But was it useful?

Sort of.
1999-2002: no work done

• I couldn’t solve certain

problems
• Come back to it with a fresh
mind
• Learn more about graphic
design, industrial design,
etc.
Two jobs later…
…and then…
How Not to Write a Pattern Catalog:

1. Treat it as a fun theoretical exercise.

(Design it to be used)
1. Design it to be used
1. Design it to be used

• Prefer concrete to abstract

1. Design it to be used

• Prefer concrete to abstract

• The format doesn’t have to be
GOF, or Alexandrian, or …
• Examples
• Context
• Problem
• Forces
• Solution
• Resulting
Context
• Diagram
• Notes
• Examples • Primary
• Context Example
• Problem • What
• Forces • Use When
• Solution • Why
• Resulting • How
Context • Other
• Diagram Examples
• Notes
But what about
interoperability?…
1. Design it to be used

• Prefer concrete to abstract

• The format doesn’t have to be
GOF, or Alexandrian, or …
• The organization just needs
to function; it doesn’t have
to be perfect
But organization is important!

• Help readers find patterns

• Makes a statement about how
the patterns should be used

It’s an information
architecture problem.
So how should we categorize
them?
• By scale?
So how should we categorize
them?
• By scale?
• By user task?
So how should we categorize
them?
• By scale?
• By user task?
• By problem statement?
• What is the basic shape of the
content?
• What is the basic shape of the
actions taken with the artifact?
• How does the content or available
actions unfold before the user?
• How does the artifact generally
use space and the user’s
attention?
• How is the content or action
organized into working surfaces?
• How can the user navigate through
the artifact?
• What specific actions should the
So how should we categorize
them?
• By scale?
• By user task?
• By problem statement?
• By design stage?
…This kind of worked.
• What Users Do
• Organizing the Content
• Getting Around
• Organizing the Page
• Commands and Actions
• Showing Complex Data
• Getting Input from Users
• Builders and Editors
• Making It Look Good
1. Design it to be used

• Prefer concrete to abstract

• The format doesn’t have to be
GOF, or Alexandrian, or …
• The organization just needs
to function; it doesn’t have
to be perfect
• Don’t sweat the “language”
stuff
“The language is a good one …
when it is morphologically and
functionally complete.

“It is morphologically complete

when the patterns together
form a complete structure,
filled out in all its detail,
with no gaps.

“And it is functionally
complete when … the patterns,
as a system, generate only
Lowered standard: just make
sure patterns link to each
other.

• Is-a
• Leads-to
• Alternative-to
• Works-well-with
• etc.
How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
2. Focus on your users

• Solve the design problems

they have
• Not everyone’s
• Use vocabulary they know
• Use familiar examples
2. Focus on your users

“Microsoft did it this

way,
so we should do it this
way too.”
• Hypertext
• Video games
• Consumer electronics
• Spoken interfaces
• Print design
• Data visualization
• Cartography
• etc…
• Hypertext
• Video games
• Consumer electronics
• Spoken interfaces
• Print design
• Data visualization
• Cartography
• etc…

Only MathWorks software.

How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
• Try to capture all design knowledge as

patterns.
(Other forms can be better)
 3. Other forms can be better

When you’ve got a hammer…

 3. Other forms can be better

My definition of “pattern:”
• Suggestion, not command
• Product, not process
• Captures relationships among
elements
• Usable across platforms
• Clearly improves the user
experience
3. Other forms can be better

• Principles
• Heuristics
• Style guides and standards
• Components
• Genres / idioms
3. Other forms can be better

Principles:
“Make your interfaces easy to
learn.”
“Prevent errors.”

Bedrock design concepts

Commands, not suggestions
Very abstract, high-level
3. Other forms can be better

Heuristics:
“Performance, cost, schedule:
pick two.”
“Expand the scope to simplify the
problem.”

Strategies for solving problems

Commands, not suggestions
Process, not product
3. Other forms can be better

Style guides and standards:

“If an item is too long to fit in
the list box, insert an ellipsis
in the middle and preserve the
beginning and end of the item.”

Design parameters for a class of

products
Commands, not suggestions
Often very specific
3. Other forms can be better

Components:
“Here’s the code for a sortable
table.”
“Here’s a set of icons for use in
drag-and-drop.”

Individual elements of a UI
Not relationships among them
Often very specific
3. Other forms can be better

Genres / idioms:
Form
Information graphic
Searchable online repository

Categories of UI types; “set the

rules”
A context, not a pattern!
3. Other forms can be better

What about new innovations?

3. Other forms can be better

Another problem: patterns

are verbose.
tp://www.visual-literacy.org/periodic_table/periodic_table.ht
 3. Other forms can be better

What had I done wrong?…

• Tried to “patternize”
genres/idioms
• Tried to “patternize”
information shapes
• Attempted to create too many
patterns for controls
• Almost published “Inverted-L”
as a pattern
How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
• Try to capture all design knowledge as

patterns.
(Other forms can be better)

• Describe
(Think hard the obvious,
about without
use contexts) offering

any genuine insight.

4. Think hard about use
contexts

Problem: You need X.

Solution: Use X.

(with apologies to Martijn)

You’re stuck in
Obviousland!
 Diversion: pattern writing

How I write a pattern:

• Notice a recurring design
element.
• Work up and down the
abstraction ladder.
• Understand why it works.
• Figure
This is whatout theyou
gets context
out of--Obviousland
when
it should or shouldn’t be used.

5. Name it.
Diversion: pattern writing

Pattern discovery in another

domain…
Step 1: find a recurring
element

What’s common here?

• Brown the meat in oil, on
high heat
• Remove it before it’s cooked
• The rest of the dish involves
liquid
• Return the meat to the
liquid, eventually
Step 2: walk the abstraction
ladder

Up, up, up:

• Does it work with vegetables
too?
• Is the liquid required?
• Would dry heat work, instead
of frying?

But these seem to lose the

“sense of
Step 3: why does it work?

Research uncovers “Maillard

reactions”…
• Produce hundreds of flavor
components
• High heat (360+)
• Requires both proteins and
sugars
• Deglazing often done too
Step 4: figure out use context

…What, you want me to be a chef

too?
Step 4: figure out use context

• We discovered that flavor

depth is added
• We ruled out vegetables and
delicate oils
• We decided that liquids
define the pattern as much as
the meat-browning does

Counterexamples?
Step 5: name it

Any ideas?
How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
• Try to capture all design knowledge as

patterns.
(Other forms can be better)

• Describe
(Think hard the obvious,
about without
use contexts) offering

any genuine insight.

(Visual examples are critical)
• Don’t bother with screenshots; they’re

too hard.
5. Visual examples are critical

• They help you define the

pattern
5. Visual examples are critical

• They help you define the

pattern
• Put your “evidence” out
there
5. Visual examples are critical

• They help you define the

pattern
• Put your “evidence” out
there
• Explain in pictures, not
just words
5. Visual examples are critical

• They help you define the

pattern
• Put your “evidence” out
there
• Explain in pictures, not
just words
• Inspiring in their own
right
How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
• Try to capture all design knowledge as

patterns.
(Other forms can be better)

• Describe
(Think hard the obvious,
about without
use contexts) offering

any genuine insight.

(Visual examples are critical)
• Don’t bother with screenshots; they’re
(Find out how it’s really used)
too hard.
6. Find out how it’s really
used

Conducted a survey of DI
readers to find out how they
use patterns

(Not statistically significant)

6. Find out how it’s really
used

• 130 respondents
• 20 were primarily developers
• 50 were designers of some sort
• A mix of managers, researchers,
etc.
• Majority have been in that
role 2-8 years
• But they do many different
things…
 6. Find out how it’s really
used

The book says:

• Advice on specific design
problems
• Learn about UI design
• Use examples as
“sourcebook”
• Terminology for
describing design
“How often do you or your team
refer to the book for advice
when you're designing
interfaces?”

Total: 80%

Most common answer: “Once or

twice during a project” (40%)
“Has the book changed your mind
about any design decisions?”

“Yes:” 50%

Sample answers: balanced

palette, date choosers, data
graphics, page organization
“Identify chapters that taught
you something you didn’t know
before”

Total: 55%

Most common answer: Chapter 4,

“Organizing the Page”
 “Identify chapters that taught
you something you didn’t know
before”
What Users Do
Organizing the Content
Getting Around
Organizing the Page
Actions and Commands
Showing Complex Data
Getting Input from Users
Builders and Editors
Making it Look Good
 “Identify chapters that taught
you something you didn’t know
before”

but many respondents said “all” or “non

“Have you used the book to help
or encourage other people to
learn about UI design?”

“Yes:” 70%
“Have you or your team used the
book to find or brainstorm new
design ideas?”

“Yes:” 65%
“Have you used the pattern
names when talking about
design?”

Total: 75%

“Have you used the pattern

names in design specs or other
design documents?”
6. Find out how it’s really
used
• Advice on specific design
problems
• Learn about UI design
• Use examples as
“sourcebook”
• Terminology for
describing design
…yes, patterns are used
• Creativeininspiration
all these ways!
 6. Find out how it’s really
used
Some other tidbits…

• 2/3 of workplaces
“informally encourage use
of UI patterns”
• 1/3 formally use patterns
“to enforce consistent
design”
 6. Find out how it’s really
used
Frequently-named patterns:

• Few Hues, Many Values

• Right/Left Alignment
• Responsive Disclosure
• Diagonal Balance
• Deep Background
 6. Find out how it’s really
used
Pattern names used:

• Responsive Disclosure (9
mentions)
• Input Hints (6)
• Wizard, Progress Indicator,
Row Striping, Liquid
Layout, Closable Panels (4-
5)
6. Find out how it’s really
used
On changed design decisions…

“considering an action panel

to replace a convoluted menu
system”

“Simplifying color and

making the page balance
diagonally.”

“Color Coding of pages was a

6. Find out how it’s really
used
On changed design decisions…

“I've moved away from linear

wizards and toward 2-panel
selectors, to give users more
control over how they work with
info or move through a process.”

“It changed my mind about web

page organization. I tend to
think of them as inherently
textual and organize them from
left to right. I plan to spend
 6. Find out how it’s really
used
General comments…

• Good summation or reference

for familiar ideas
• Useful as a “memory jogger”
• Different platforms: good
• More patterns!
• More AJAX!
6. Find out how it’s really
used
General comments…

“Synthesis, reinforcement,
clarification: this is what the
book was mostly useful for.”

“…it has boosted my design

decisions and given me confidence
to go ahead with the designs.”

“…many times I think of one way

of doing things and after
consulting with the book I have
 6. Find out how it’s really
used
Conclusions:

• Patterns are used in the ways

we predicted
 6. Find out how it’s really
used
Conclusions:

• Patterns are used in the ways

we predicted
• They help both novice and
skilled designers
 6. Find out how it’s really
used
Conclusions:

• Patterns are used in the ways

we predicted
• They help both novice and
skilled designers
• Many workplaces are aware of
them and use them
 6. Find out how it’s really
used
Conclusions:

• Patterns are used in the ways

we predicted
• They help both novice and
skilled designers
• Many workplaces are aware of
them and use them
• Repository of design wisdom,
more than a teaching tool
How Not to Write a Pattern Catalog:

• Treat it as a fun theoretical exercise.

(Design it to be used)
• Write it for all designers, everywhere.
(Focus on your users)
• Try to capture all design knowledge as

patterns.
(Other forms can be better)

• Describe
(Think hard the obvious,
about without
use contexts) offering

any genuine insight.

(Visual examples are critical)
• Don’t bother with screenshots; they’re
(Find out how it’s really used)
too hard.