Three kinds of design

14 Dec 2007 - 5:27pm
6 years ago
3 replies
380 reads
DrWex
2006

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
commentary.

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
do.

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?

--Alan

Comments

14 Dec 2007 - 6:15pm
dmitryn
2004

Alan,

This doesn't relate directly to your question, but Luke Wroblewski has a
recent blog post where he examines the pros and cons of the approach you
mention to collecting address information:

http://www.lukew.com/ff/entry.asp?605

Dmitry

On Dec 14, 2007 2:27 PM, Alan Wexelblat <awexelblat at gmail.com> wrote:

> 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?
>
> --Alan
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

14 Dec 2007 - 6:57pm
Jared M. Spool
2003

There's another reason, in addition to what Luke points out in his
article:

Many users enter one of the components wrong. This is why the post
office hasn't eliminated the redundancy on the envelope. It's not
unusual for someone to get a digit wrong in the zip or to get the
name of the town or state wrong. (People regularly confuse MS and MA
or MA and MD, for example.)

By having both the zip & the city/state, both the system (with a
decent address verification system) and the post office can do error
correction.

Jared

On Dec 14, 2007, at 6:15 PM, Dmitry Nekrasovski wrote:

> Alan,
>
> This doesn't relate directly to your question, but Luke Wroblewski
> has a
> recent blog post where he examines the pros and cons of the
> approach you
> mention to collecting address information:
>
> http://www.lukew.com/ff/entry.asp?605
>
> Dmitry
>
> On Dec 14, 2007 2:27 PM, Alan Wexelblat <awexelblat at gmail.com> wrote:
>
>> 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?
>>
>> --Alan
>> ________________________________________________________________
>> *Come to IxDA Interaction08 | Savannah*
>> February 8-10, 2008 in Savannah, GA, USA
>> Register today: http://interaction08.ixda.org/
>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

14 Dec 2007 - 8:53pm
Petteri Hiisilä
2004

Alan Wexelblat kirjoitti 15.12.2007 kello 0:27:

> I've been thinking on this for a while and I admit the idea's still
> only half-baked.

Your ideas and observations reflect with mine.

But I think there's #0, which is where every designer begins: getting
away from what me or you personally thinks is cool. That's a sticky
problem. We are hard-wired to like the things we've worked so hard
for, like your grandpa, and the grandpa before that...

To the list:

> 1. Core design. This is "the good stuff" that we all want to be
> doing,

Good stuff from the end user's point of view, right?

There is the stuff that should be in the design, and I think it's
absolute what should be there - theoretically at least - more advanced
design methods are making us sharper at identifying, which form,
information and behavior helps the users and customers to achieve
their goals better than what they had before, and what the competition
offers.

> 2. Demo design. This is particularly prevalent in enterprise software
> or situations where the customer (person who writes the check)

Almost every product/service goes through some layer of enterprise or
financial management, or a bank, unless the entrepreneur has deep
pockets her-/himself. This means that some part of the design must be
especially comfortable to inform to the stakeholders, and none of it
should be especially uncomfortable to inform to the stakeholders.

--> A demonstration is required but it's not sufficient. Design
communication is a tough topic in itself.

> 3. "Checklist" or "me too" design.

This could be thought as the design of how to make the final product/
service comfortable to sell. The salespeople have to establish a
business relationship with every customer, and they can have one to
one hundred (?) relationships per day. Feature lists are a good
shortcut for negotiation.

Quite often a customer doesn't have time or money to make a truly
rational choice. Therefore, we must design the product to feel good to
sell and buy. Does it matter if the purchase decision is irrational,
if they end up with your design, which hopefully helps them to achieve
their goals better than the alternatives?

"Checklist" or "me too" considerations are required but not
sufficient. But you've probably identified a need for a design/
prediction process, which isn't limited to what you mentioned.

> Is there another major category I'm missing that you find sucks up
> significant design cycles
> on your projects?

It's really hard to not like your own experience with your own design,
and that's what I'd add to the list. It does suck up a lot of design
cycles.

So,

#0 No self-referential design
#1 Design for the users
#2 Design for the stakeholders
#3 Design for the salespeople and the buyers

Number three has 2 groups. If you bow to the sales force, you have to
bend over to the buyers, and vice versa. In the end they have to agree
on the same price, so there is a design target - the value of the
exchange. (Beliefs * Desires) = Value?

Thanks,
Petteri

--
Petteri Hiisilä
Senior Interaction Designer
iXDesign / +358505050123 /
petteri.hiisila at ixdesign.fi

"Simple is better than complex.
Complex is better than complicated."
- Tim Peters

Syndicate content Get the feed