Feature-driven development vs user-centered design

23 Aug 2007 - 8:57am
7 years ago
8 replies
860 reads
Michael Micheletti
2006

A few days ago in another thread, I believe it was Will Evans who mentioned
something to the effect that feature-driven development was the opposite of
user centered design.

I've been thinking about this for a few days. A bit spooked, actually, as I
work in a feature-driven shop that hasn't completely turned the corner into
UCD. Every so often I yank hard on the wheel, but the ship turns slowly and
all the sailors are very busy.

>From my vantage, a designer can have a positive impact on products created
in a feature shop. The controls can have sensible names and locations. The
visual layouts can be pleasing and unified. The operations can be consistent
and functional. Tasty design sauce applied liberally. But there's something
missing at the _core_ of the products, that assurance that they are the
right products for the right people, that the right features were added or
cut, that a truly human intention is behind it all somewheres in there,
right at the heart of things. Sometimes, even if the finished results look
and work right on the surface, the total package doesn't quite hang
together.

I am very interested in this concept that feature-driven development is the
opposite of UCD. Kind designer friends please shed a bit more light on this
if you can. Thank you,

Michael Micheletti

Comments

23 Aug 2007 - 11:03am
Todd Roberts
2005

I'd say it depends on where the feature list comes from. "Feature" has a
really negative connotation implying "junk that marketing thinks is cool but
nobody will want." But if the feature list is garnered from an ethnographic
or other UCD research process, it would probably be more successful.

Maybe the real distinction is Buxton's "getting the design right, and
getting the right design" regardless of what your process is. Feature-driven
just brings to mind the likelihood of the former without the latter through
the corruption of the term "feature."

On 8/23/07, Michael Micheletti <michael.micheletti at gmail.com> wrote:
>
> A few days ago in another thread, I believe it was Will Evans who
> mentioned
> something to the effect that feature-driven development was the opposite
> of
> user centered design.
>
> I've been thinking about this for a few days. A bit spooked, actually, as
> I
> work in a feature-driven shop that hasn't completely turned the corner
> into
> UCD. Every so often I yank hard on the wheel, but the ship turns slowly
> and
> all the sailors are very busy.
>
> >From my vantage, a designer can have a positive impact on products
> created
> in a feature shop. The controls can have sensible names and locations. The
> visual layouts can be pleasing and unified. The operations can be
> consistent
> and functional. Tasty design sauce applied liberally. But there's
> something
> missing at the _core_ of the products, that assurance that they are the
> right products for the right people, that the right features were added or
> cut, that a truly human intention is behind it all somewheres in there,
> right at the heart of things. Sometimes, even if the finished results look
> and work right on the surface, the total package doesn't quite hang
> together.
>
> I am very interested in this concept that feature-driven development is
> the
> opposite of UCD. Kind designer friends please shed a bit more light on
> this
> if you can. Thank you,
>
> Michael Micheletti
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

23 Aug 2007 - 11:22am
Mark Schraad
2006

I can't speak for Will, but that is what is commonly referred to as technology driven design. We can do it, so we will. The typical result is a product with way more features than anyone will really use (think most mobile phones).

UCD, would of course refer to what we designer think of as 'what the user wants'.

Often times business/marketing has its own ideas and drives input based upon 'how we can best keep up or compete'.

Then there is the vision... sometimes driven from research, but typically by an early adopter. This is the influence of what the customer 'will need'. Most of the time customers only want what is already available.

Mark

On Thursday, August 23, 2007, at 12:44PM, "Michael Micheletti" <michael.micheletti at gmail.com> wrote:
>A few days ago in another thread, I believe it was Will Evans who mentioned
>something to the effect that feature-driven development was the opposite of
>user centered design.
>
>I've been thinking about this for a few days. A bit spooked, actually, as I
>work in a feature-driven shop that hasn't completely turned the corner into
>UCD. Every so often I yank hard on the wheel, but the ship turns slowly and
>all the sailors are very busy.
>
>>From my vantage, a designer can have a positive impact on products created
>in a feature shop. The controls can have sensible names and locations. The
>visual layouts can be pleasing and unified. The operations can be consistent
>and functional. Tasty design sauce applied liberally. But there's something
>missing at the _core_ of the products, that assurance that they are the
>right products for the right people, that the right features were added or
>cut, that a truly human intention is behind it all somewheres in there,
>right at the heart of things. Sometimes, even if the finished results look
>and work right on the surface, the total package doesn't quite hang
>together.
>
>I am very interested in this concept that feature-driven development is the
>opposite of UCD. Kind designer friends please shed a bit more light on this
>if you can. Thank you,
>
>Michael Micheletti
>

23 Aug 2007 - 11:56am
bminihan
2007

I agree with your point, but had one additional thought that popped up throughout your comments below: the difference between "too many features" and "the right features" has a lot to do with the product's target audience and its culture. 10 minutes ago I was discussing cell phones with my colleague, and she remarked how cell phones in Japan have tons of features and buttons, and from her visits there and to china (she's 2nd gen chinese american) - she noticed that they actually use most of these features.

And here I am just trying to remember which buttons tell me who just called me.

Frequently, technical folks (I can get this way sometimes) want to rush people along and show them how great the world could be if they only had this or that function. Far too often they have the right idea but forget that not everyone is an early adopter, and some people need a little caution in taking up new technologies and changing their habits. While I would be considered a "geek" in most circles, I am notoriously slow in adopting new technology, mostly because I'm a creature of habit.

- Bryan
http://www.bryanminihan.com

---- Mark Schraad <mschraad at mac.com> wrote:
> I can't speak for Will, but that is what is commonly referred to as technology driven design. We can do it, so we will. The typical result is a product with way more features than anyone will really use (think most mobile phones).
>
> UCD, would of course refer to what we designer think of as 'what the user wants'.
>
> Often times business/marketing has its own ideas and drives input based upon 'how we can best keep up or compete'.
>
> Then there is the vision... sometimes driven from research, but typically by an early adopter. This is the influence of what the customer 'will need'. Most of the time customers only want what is already available.
>
> Mark
>
>

23 Aug 2007 - 12:01pm
Andrei Herasimchuk
2004

On Aug 23, 2007, at 7:57 AM, Michael Micheletti wrote:

> I've been thinking about this for a few days. A bit spooked,
> actually, as I
> work in a feature-driven shop that hasn't completely turned the
> corner into
> UCD. Every so often I yank hard on the wheel, but the ship turns
> slowly and
> all the sailors are very busy.

I have to ask... why does it have to be one or the other or one over
the other? And why does it even matter if they are the opposite of
each other, if that's even true?

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

23 Aug 2007 - 12:42pm
Andrei Herasimchuk
2004

On Aug 23, 2007, at 11:37 AM, <bjminihan at nc.rr.com>
<bjminihan at nc.rr.com> wrote:

> If you wanted to combine the user-focus of user centered design
> with tech-focus of feature-driven design, you could call it:
> Creature-Feature Drive-in Design.

Or you could just call it "product design."

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

23 Aug 2007 - 1:22pm
Andrei Herasimchuk
2004

On Aug 23, 2007, at 11:46 AM, Michael Micheletti wrote:

> Not so everywhere. When the eagerness of technologists to show off
> capabilities joins forces with the eagerness of product managers to
> add more
> features to product checklists, a sort of synergy happens that
> seems very
> different from UCD. Without a deep human perspective on who uses your
> products, and how they do, the temptation is to add more features.
> I've come
> to dread the words "this is cool" when spoken by engineers, because
> they
> inevitably come accompanied by a new screen full of configuration
> parameters.

My first piece of advice, if you don't mind, is to stop dreading the
words "this is cool" from engineers. You should be just as jazzed as
they are by the cool technology things they are cooking up. I always
enjoyed getting messages from various Adobe engineers on all the
product teams saying, "Hey Andrei... come check this out! I've got
something to show you." I always knew there'd be something there that
would be fun to work with and design. As for product managers,
well... I'm the worst person to ask about anything to do with PMs
since I'm usually the guy they hate the most on the project. (I'm
always the one pushing back at them to stop making the interface a
dumping ground for features.) These days, I enjoy checking out the
various cool stuff all the engineers cook up with our various
clients. I find it to be one of the more interesting parts of my job
now as I get to see more technology outside of the computer imaging
world.

That said, the way I found to keep some semblance of control over
allowing the features get away from you was to use "alpha testers."
I started using this approach back in my early days at Adobe, where I
basically convinced the product teams to let me have 4 to 7 users
sign extremely nasty NDAs and once they did so, they became part of
the team. What that meant is that once a customer became an alpha
tester, they had access to literally everything we did on the
project. Documents, crude alpha builds that crashed often,
screenshots, email threads of everyone on the team arguing over the
design, etc. Their feedback at that level always kept the "feature
driven" problems in check and brought it back to reality in my
experience.

I encourage and try to implement this approach with every client
Involution works with. Some of them can make it happen, some can't.
The ones that can make my life easier as a designer as it provides a
nice reality check during the design process. The ones that can't for
a variety of legitimate reasons (sometimes legal, sometimes cultural)
require us to find news ways to deal with that lack of feedback.

Are alpha testers a UCD methodology? I don't know, probably. Back
when I was doing it in 1995, I didn't care. I just did it because
that's what I do as a designer. I get feedback and iterate and build.
I do it over and over and I involve as many people as I can get away
before some lawyer finds me and tells me I can't do it anymore or the
executives tell me I have to stop and ship.

I also do feature driven design as well. One doesn't exist without
the other. Ever. I'm not sure how its possible to operate designing
"for users" without also design "for technology." In graphic design
terms, I think that's like trying to design a poster based solely on
the grid and compositional elements with no regard to the content's
message and what the poster is communicating. Or vice versa.

It simply seems impossible to me, both have to happen. It's also why
I tend to find the label "user centered design" to be flawed because
semantically, as a label, it's inherently exclusionary.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

23 Aug 2007 - 1:57pm
Michael Micheletti
2006

Andrei, this is brilliant. I've done design on in-house systems with user
representatives on the design team, but hadn't thought to try this for
external shipping products. Having real live domain-aware users on the
design team keeps everybody focused. Good decisions happen quickly. This
could be very helpful in our shop. Thank you for the great suggestion and
details on how you made it work,

Michael

On 8/23/07, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
> On Aug 23, 2007, at 11:46 AM, Michael Micheletti wrote:
>
> That said, the way I found to keep some semblance of control over
> allowing the features get away from you was to use "alpha testers."
> I started using this approach back in my early days at Adobe, where I
> basically convinced the product teams to let me have 4 to 7 users
> sign extremely nasty NDAs and once they did so, they became part of
> the team. What that meant is that once a customer became an alpha
> tester, they had access to literally everything we did on the
> project. Documents, crude alpha builds that crashed often,
> screenshots, email threads of everyone on the team arguing over the
> design, etc. Their feedback at that level always kept the "feature
> driven" problems in check and brought it back to reality in my
> experience.
>

23 Aug 2007 - 2:05pm
bminihan
2007

Not to add a marketing spin, but inviting a small set of users/customers "into the fold" is a good way to appeal to a particular kind of customer - those who need to be on the inside, adopt early, and are more likely to set the precedent and tell their friends that you have a good product (assuming you do). It's similar to passing out Walkman tape players to celebrities (http://www.sony.net/Fun/SH/1-18/h3.html).

- Bryan
http://www.bryanminihan.com

---- Michael Micheletti <michael.micheletti at gmail.com> wrote:
> Andrei, this is brilliant. I've done design on in-house systems with user
> representatives on the design team, but hadn't thought to try this for
> external shipping products. Having real live domain-aware users on the
> design team keeps everybody focused. Good decisions happen quickly. This
> could be very helpful in our shop. Thank you for the great suggestion and
> details on how you made it work,
>
> Michael
>
> On 8/23/07, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
> >
> > On Aug 23, 2007, at 11:46 AM, Michael Micheletti wrote:
> >
> > That said, the way I found to keep some semblance of control over
> > allowing the features get away from you was to use "alpha testers."
> > I started using this approach back in my early days at Adobe, where I
> > basically convinced the product teams to let me have 4 to 7 users
> > sign extremely nasty NDAs and once they did so, they became part of
> > the team. What that meant is that once a customer became an alpha
> > tester, they had access to literally everything we did on the
> > project. Documents, crude alpha builds that crashed often,
> > screenshots, email threads of everyone on the team arguing over the
> > design, etc. Their feedback at that level always kept the "feature
> > driven" problems in check and brought it back to reality in my
> > experience.
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org

--

Syndicate content Get the feed