Daniel Burka
Iterative Design

Your design sucks, how do you evolve your site over time.  So constant
changes to you site is important.

There's a difference in how to design if you're in house or contract work.
Burka went from contract work to in-house (Digg, Pownce, etc.).  E.g
contract work is handing off design to another group that has to do it's own
in house work.  In house design allows you the freedom of quick change at
the expense of lack of objective interpreation.

Recommendation: Stewart Brand - How Buildings Learn (evolution of
architecture).  Differentiates between high road / low road.

High road: Lots of planning, little changing.  Changes take as long as
initial design.  E.g.: castle, cathedral, etc.  Website: The Adventure
School.  Flash based, uses small animations, etc, but uses map metaphor so
adding new menu is large change.

Low road: Modular, cheap to build & cheap to change (unfortunately the
examples are ugly but doesn't have to be).  E.g. a trailer, warehouses,
modular homes, etc.  This is the dominant architecture (90%).  Website: most
blogs, etc.  Often reuse tools (CSS standard, frameworks, CMS, etc.).

Slightly different than Cathedral and Bazaar, since focuses on structure not
on build process.

How to accomplish good results using a low road architecture.  Important to
establish the visual language and avoid Tower of Babel.  Tower of Babel:
mixed "language" (metaphors) between different parts.  E.g. Pownce: Daniel's
first design appeared static: boxed, perpendicular, etc.  Switched to
smaller borders and "speech-bubble arrow" on bottom left to make dynamic and
guide eye down (also made colors more bold).  Then made this part of the
language and reused this detail on other pages (e.g. homepage, dock icon).
Digg: based on shape of the digg button.  Rounded, etc.  Also changed over
time: went from heavy gradient to flatter, to light gradient, etc.

FaceBook is a good example of integrated design: single pixel lines, light
blue background for tites, dark blue for menus & some buttons.  Very simple
vocabulary that's oft. repeated.  Makes it easier to develop a facebook
app... also makes it more annoying when sites don't conform (same as on
Mac).

Another point from Stewart's book is "Desire Paths": don't put paths in
until you see where people go (counter-point: don't some people want to go
off-path?).  But meta-point is valid: you don't know how people will use
things, instead follow your users use.  E.g. Digg used to have a single
threaded comment system, but people used "@" to simulate threads, so
obviously feature was in demand, so added.  Also on Twitter.  Re-iteration
of agile, release early & often, etc.

Also need to addapt to scale.  E.g. move from drop-down to more intelligent
searching system.  Also applies to technical scale (e.g. code,
performance). For web: divide up CSS to ease homepage, use CSS sprites (less
HTTP transfer).

Evolving is not always adding: subtraction of features is also iteration
(and often better).  Or, think you're adding simplicity.  Best: add feature
that streamlines visual interface.  E.g. 3rd Digg revision vertical was
title, source, text, meta (vs. title, source, meta, text).

Evolution should also be as small as possible.  "Realign don't Redesign":
don't want full rewrite, just "refactoring".  Want to figure out what's
happening on site right now and do hundreds of small adjustments.  Massive
redesign also breaks all users expections, ruins their knowledge of site.
Likewise, innovation isn't good in interfaces.  An interface shouldn't hold
your stamp, it should be transparent.  E.g. tab navigation on the web:
everyone knows how it works, so just use it.  Though innovation can be
useful, just choose battle.

Innovation requires time set aside.  If you have a formal design process,
build in an iteration step.

Don't panic: listen to feedback carefully before making changes.  Users
often want changes too quickly, also squeeky wheel.  Same as with bugs:
think about bugs before putting in fixes, often they will be simpler.

Case study: Digg comment section.  2005: linear comments.  Very much they
were brief comments on the articles.  Problems: doesn't scale (too many
comments unreadable), no features (not threaded, no votes), not compact, not
very attractive, too literal (speech bubbles for comments).

2006: more abstract.  Added threads & votes (necessary since comments became
negative as site scaled).  Problems: still doesn't scale (and now a problem
since more peole are commenting), ended up with 500-600k of HTML.  Nesting
can confuse novices ("why are some comments indented?"), but wasn't good
enough for experts ("why only 1 level of hierarchy?").  Design promoted
top-posting: instead of threading, reply in top just so comment gets seen.

2007: Simpler version of 2006.  Hide threads by default w/ "view replies",
no identation, small enough.  Problems: slower UI while loading comment
replies.  Problem for power users.  Nesting is there, but still cluttered:
used vertical lines (ala directory tree).  Awkward interactions between
steps (bury, ban user, vote, etc.)  Folded comments also prevented quick
search for your own user.  An example of user feedback: lots of angry
threads about changing the system, but 20% more comments: so some people are
angry, but in general it works.  Realign: not redesign.

2008: Visually simpler, grid layout.  Faster, scales, some power user
features (up/down vote count), streamlined some interactions (made A-B,
e.g. can only block user after burying comment).  Based on lots of
"play-time", which was very handy for Daniel.  Problems...?

Need to be able to convince people that adaptation is important.  Depends on
environmnet and audience.  E.g. use ROI for business people.  Other ideas:
quick and dirty ("a room and pizza" usability test).

Question: what sort of instrumentation do you use to gather statistics?
Digg does use lots of analytics and it drives design.  Don't currently do
A-B tesitng, but appreciates the idea.  Technical limitations make it hard.
(Technical limitations do matter, for lots of things you don't think of).

Question: what about explicit feedback mechanisms (e.g. "vote for your next
feature").  Sure, but be careful about trusting users too much: they don't
know what they want and someone's always unhappy.  Be careful about how you
phrase the question, not "we will do A or B" but "what do you think?".

Question: what about the interplay between designers and developers?
Understanding HOW things will be coded, or can even prototype things is very
important.  Allows sandboxing design.  (Likewise, developers should
understand how they affect designers?  Also argument for the "1-man army"
Lisp-like approach).

Question: how big are your steps?  The Digg story comments are lots of small
changes.  The comments changes were done as large releases, which probably
caused a lot of the negative feedback.  Changes should be almost un-noticed
(e.g. Google's products).

Question: how do you mix graphics & colors with text?  They're equivalent!
Your text is part o fyour design & your interface.  Basically, it's up to
the designer unless there's another impact (e.g. marketing needs to have a
say).

Question: how do functionality and form interplay?  Something like the
Shaker furniture: don't make something unless it's useful, but if you make
it, make it beautiful.  So aesthetics are really a minor part of design.

Question: what could you take away from this to consulting work?  More
statistics in use.  It's easy to do low-hanging fruit simple changes, but
that often isn't the most profound change.  Analyzing a site's usage and
adding new features can add brand new things to a site.

Question: how do you aesthetically design your visual language?  Not a real
solid answer, it's artistic taste.  Pownce was based on copy design: telling
a story and have notes in the margins.  One way is riffing off of other
designs in the area.

Question: development is become more iterative thanks to agile, but often
interaction devlopment, UI, etc. is not considered a high technical
priority.  Is there a way you can balance that?  Really, it's just a
user-centered mindset.  Must convince developers that the interface is what
the user sees, so designing that is important, the plumbing should work but
not be seen.