Comments on: Evolution Doesn’t Do Design http://www.marclehmann.net/2007/10/evolution-doesnt-do-design/ Marc Lehmann's Blog Thu, 11 Mar 2010 18:08:45 +0000 hourly 1 By: marc http://www.marclehmann.net/2007/10/evolution-doesnt-do-design/comment-page-1/#comment-29 marc Mon, 22 Oct 2007 09:32:07 +0000 http://www.marclehmann.net/2007/10/evolution-doesnt-do-design/#comment-29 Totally agree. I think our only difference is the target market. I'll post my thoughts, I started writing a comment but it got a bit long. Totally agree. I think our only difference is the target market. I’ll post my thoughts, I started writing a comment but it got a bit long.

]]> By: grant http://www.marclehmann.net/2007/10/evolution-doesnt-do-design/comment-page-1/#comment-28 grant Sat, 20 Oct 2007 10:28:49 +0000 http://www.marclehmann.net/2007/10/evolution-doesnt-do-design/#comment-28 I think that the evolutionary principle is very much at the heart of agile development methodology - get new features "out into the wild" and see what sticks. Sometimes things work, sometimes you'll need to roll back. I think there's one core issue though - how do you determine what "survives" or not? Once a feature has been released, someone, somewhere will find use in it - so it's hard, then, to remove that feature without disenfranchising your customers. The bigger your user base, the harder it is. The other, related, thing is that it's easy to keep adding feature after feature, gradually expanding things until what's evolved is a great fat hairy monster with 8 ears and 5 arms and a technicolor fur. So it can evolve into a bloated bit of software that then gets too heavy and dies a slow and painful death in the market. The evolutionary process occurs through competition in this model - many different companies trying very different things and the one that gets it right (mostly) survives. So it's important, then, to think really hard about what gets added - to make sure that, on balance, the next evolutionary step will provide enough value to give you the evolutionary edge, without falling into the tar pits of bloat. And that's really what "design" is all about. The techniques of design help to understand what is of most value to the customer so that as the software evolves, it remains lean and fresh and ahead of the competition. (Of course I'm talking about design in the broader sense - interaction, experience, information architecture etc. - as well as visual) I think that the evolutionary principle is very much at the heart of agile development methodology - get new features “out into the wild” and see what sticks. Sometimes things work, sometimes you’ll need to roll back.

I think there’s one core issue though - how do you determine what “survives” or not?

Once a feature has been released, someone, somewhere will find use in it - so it’s hard, then, to remove that feature without disenfranchising your customers. The bigger your user base, the harder it is.

The other, related, thing is that it’s easy to keep adding feature after feature, gradually expanding things until what’s evolved is a great fat hairy monster with 8 ears and 5 arms and a technicolor fur. So it can evolve into a bloated bit of software that then gets too heavy and dies a slow and painful death in the market.

The evolutionary process occurs through competition in this model - many different companies trying very different things and the one that gets it right (mostly) survives. So it’s important, then, to think really hard about what gets added - to make sure that, on balance, the next evolutionary step will provide enough value to give you the evolutionary edge, without falling into the tar pits of bloat.

And that’s really what “design” is all about. The techniques of design help to understand what is of most value to the customer so that as the software evolves, it remains lean and fresh and ahead of the competition.

(Of course I’m talking about design in the broader sense - interaction, experience, information architecture etc. - as well as visual)

]]>