Feature-driven development vs user-centereddesign

>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?

Agreed. My perception of "feature driven development" is that you build
the product incrementally, one feature at a time. Hopefully the first
feature you build is the most important one. This does not mean in any
way that the feature can't be a result of solid UCD research.

My shop is Agile right now, and we're making UCD work. UCD and feature
driven development can and should coexist. I don't think they are
opposites at all.

BTW - is my perception of feature driven development correct?

Jeff

Comments

23 Aug 2007 - 1:37pm

bminihan

2007

If you wanted to combine the user-focus of user centered design with tech-focus of feature-driven design, you could call it:

> My shop is Agile right now, and we're making UCD work. UCD and feature> driven development can and should coexist. I don't think they are> opposites at all.>

23 Aug 2007 - 1:46pm

Michael Micheletti

2006

Andre and Jeff, fair questions, and answers. I think you may both work in
environments that are a bit farther along on the design curve. I'm glad
there's no conflict there for you. The pendulum swings evenly back and
forth.

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.

I guess the question matters to me because I have the sense that our shop
could choose features more intelligently, and implement them more wisely, if
we focused less on features and more on the people who use them. It matters
to me because I want to improve our design processes, and
feature-centeredness seems somehow at the core of the problem. Thanks for
helping me make sense of this,

Michael Micheletti

On 8/23/07, White, Jeff <Jeff.White at jtv.com> wrote:
>>> >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?>> Agreed. My perception of "feature driven development" is that you build> the product incrementally, one feature at a time. Hopefully the first> feature you build is the most important one. This does not mean in any> way that the feature can't be a result of solid UCD research.>> My shop is Agile right now, and we're making UCD work. UCD and feature> driven development can and should coexist. I don't think they are> opposites at all.>

23 Aug 2007 - 2:20pm

sandeepblues

2003

Are user interface designers professionals or merely, activists?

Money talks. Competition can copy user interfaces and improve upon them. But, the customer will compare feature by feature....especially when the buyer is not the user. Folks can copy iPod interface, and then add features, and sell it for cheaper. Of course, being cool is associated with iPod, which is purely a marketing campaign success.

Being the devil's advocate. UCD rules. I am an activist at heart.

Sandeep

Michael Micheletti <michael.micheletti at gmail.com> wrote: Andre and Jeff, fair questions, and answers. I think you may both work in
environments that are a bit farther along on the design curve. I'm glad
there's no conflict there for you. The pendulum swings evenly back and
forth.

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.

I guess the question matters to me because I have the sense that our shop
could choose features more intelligently, and implement them more wisely, if
we focused less on features and more on the people who use them. It matters
to me because I want to improve our design processes, and
feature-centeredness seems somehow at the core of the problem. Thanks for
helping me make sense of this,

Michael Micheletti

On 8/23/07, White, Jeff wrote:
>>> >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?>> Agreed. My perception of "feature driven development" is that you build> the product incrementally, one feature at a time. Hopefully the first> feature you build is the most important one. This does not mean in any> way that the feature can't be a result of solid UCD research.>> My shop is Agile right now, and we're making UCD work. UCD and feature> driven development can and should coexist. I don't think they are> opposites at all.>________________________________________________________________
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 - 3:30pm

jayeffvee

2007

We may use traditional usability testing to this end, sometimes -- that
is, if Design can't talk business and/or technology off the ledge about
the value of something they think is 'cool' that gives us grave doubts,
then we let the users tell them.

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