I've been thinking on this for a while and I admit the idea's still
only half-baked. But I thought I'd toss it out to the list for
I think there are three kinds of design for product features (web site
features also, not so much with intranet features).
1. Core design. This is "the good stuff" that we all want to be
doing, that we have tools and techniques aimed to support (personas,
contextual design, et cetera). We write and speak about this design
all the time, and we behave as if it was the only kind of design we
However, we end up designing other things, and those other things
often eat up a lot of design cycles.
2. Demo design. This is particularly prevalent in enterprise software
or situations where the customer (person who writes the check) isn't
the user (person who works with the software on a regular basis).
This design is not for things that support user goals, or that help
people complete tasks with the software. Or for that matter, any
other metric that's used to judge features in category 1. This design
is all about "does it look good on a demo?" "will it impress
customers?" For example, a program might support complex layout
movement/arrangement features for its components. Salespeople will
use this to show off how whizzy and powerful the app is. But real
users (or at least 95% of them) won't change the default settings or
may even be given a 'corporate look' and not allowed to change it.
When doing this design, all the user research in the world is
irrelevant. Most good interaction design techniques aren't much help
either. If it looks good and sales people can memorize a great spiel
around it, you design it. (or at least, I do, grimacing all the way.
Dunno about anyone else.)
3. "Checklist" or "me too" design. This happens a lot in situations
where products enter into a highly competitive space, or one where
there's a dominant or well-known leader. If you want to compete in
the market space then you end up needing to check off certain features
on a head-to-head comparison. It's not usually an opportunity to
apply innovative design - everyone knows what the feature is and
expects it to behave in a certain way or look a certain way. The fact
that you can produce a more efficient or aesthetic design isn't really
at issue here - doing so would run counter to peoples' expectations
and that's not going to help.
A classic example here is entering mailing addresses into a form. In
the US, having the Zip code uniquely identifies the state, and in over
95% of cases allows you to know the town as well. And yet, every
single form asks you for city, state, and then zip code. Why?
Because it's not a differentiating feature. Nobody cares that it's
2/3 wasted effort on the user's part. You have to have a way to
capture mailing addresses, but the usual interaction design goals
don't really apply here. Just do it the standard way. (where here
"standard" really means "expected").
Does this match up with your experiences? Is there another major
category I'm missing that you find sucks up significant design cycles
on your projects?