Comments on: The Agile Web Design Manifesto, An Introduction

By: Aaron Smith

Aaron Smith — Fri, 10 Aug 2007 11:39:22 +0000

I found this article interesting, although I think that the meat of it should have involved delving into the points listed as the “Core Principles of Agile Web Design.” If you wrote a follow-up, please let me know.

I have noticed lately that some Agile adherents reject the notion of UI designers / IxDs altogether. I wrote an article on the case for the UI designer on Agile projects which you might find interesting: http://tinyurl.com/ypn7sz. It is located on SmartAgile.com.

By: Quinlan

Quinlan — Sun, 23 Jul 2006 07:43:20 +0000

Have been thinking more about this and feel the idea of Agile Web Design is a misnomer.
Surely what designers should be considering is Organic Web Design or Parametric Web Design??
Agile as a process already removes a lot of the pain by including the design team in the ‘production team’ - certainly SCRUM does.
I think what Emily and Max are getting to is an extention of what Jesse James Garrett had to say on Web Design as a science…

By: Quinlan

Quinlan — Tue, 18 Jul 2006 02:22:27 +0000

gahlord dewald on 02/23 at 10:39 PM says; “Also, agile development doesnt get to have price + quality + service/speed. It incrementally sacrifices quality. Which is why everything is always in beta; a little bit broken but functional enough that the user can overlook it.. “

This is palpably not true. Scrum forces out a ‘finished product’ at the end of each month, fully tested and functioning. XP also ensures improved quality through pair programming and testing cycles. Speed may be an issue, but there again you have to see it in terms of Pareto, 20% functionality now for 80% of your real needs, and where the business is drawing the top and bottom lines.

As to an ‘Agile’ approach to deisgn at the front end, this has to become part of the package if websites are to go to the next level. There are far too many ‘artists’ out there and far too few empirical designers meeting stakeholder needs in terms of AIDA and therefore the business goals of site design. Matters become more complex when agencies come in to teach the in-house team why and how they are doing it all wrong - and it is never that clear cut. Agile, as much as a methodology, is a philosophy and one designed to resolve a lot of the people frictions evident when designing at the Business, Interface, Application and Architectural levels along traditional lines. Because I see it as a production and design philosophy I think it has real possiblilities at the user end.

By: renato cruz

renato cruz — Sun, 23 Apr 2006 09:12:46 +0000

i need more !

By: gahlord dewald

gahlord dewald — Thu, 23 Feb 2006 10:39:25 +0000

I just wanted to pipe in and suggest watching a documentary called “Death by Design.” It’s a biology thing about programmed cell death.

It relates to the topic and also to David’s comments about efficiency by highlighting the way in which things are created in the biological world: excessive overbuilding followed by ... programmed cell death.

We mimic some of these behaviors directly ourselves as a social organism (to build a skyscraper first we put up a lot of scaffolding, and then when we are done building the skyscraper we tear down the “inefficient” scaffolding).

The point is that there’s a cult and myth of efficiency which will always fail to grasp agile design/development. And there’s something about the word “agile” which is counter-intuitive to it’s inefficient processes. it would seem to be mroe efficient to conceive of something and produce it whole, of one cloth. But not if the pace of business/life/trends/taste/fashion move so fast that you lack time to conceive of something in its entirety.

Also, agile development doesn’t get to have price + quality + service/speed. It incrementally sacrifices quality. Which is why everything is always in beta; a little bit broken but functional enough that the user can overlook it..

As a designer who is often hired initially to work on the surface of a product but quickly ends up guiding clients through improvements to the whole system, I can say that this agile stuff has teeth. I’ve let it permeate my own business practice to the point where I am constantly looking for ways to be more transparent. Even to the point of showing *gasp* rough comps to clients who I know can handle it. The transparency thing is key. And shucking our designer/fascist berets and listening. It’s all there. And if the client trusts the relationship they won’t pick the bad comp or interfere in a negative way with the work. The end result is better for everyone. And we have fun along the way.

Anyway, great article. I’m halfway between you and David. Please write more.

Gahlord

off to apply some agile development to my own sorely battered and bruised site.

By: Emily Chang

Emily Chang — Sat, 18 Feb 2006 07:46:52 +0000

David, thanks for your insightful comment. I agree with you that design research and thinking must be done up front. There’s no doubt that reflection, exploration, and nonlinearity are inherent to the process. That said, designing for today’s web applications also requires continuous improvements or refinements to both technology and design. This agility doesn’t imply a linear process by any means but the opposite: a process that’s fluid and subject to iterative research through user feedback, user generated content, knowledge patterns, technological shifts, etc. Personally, I’ve never bought the old consultant’s adage of picking 2 out of “fast, cheap, good.” That’s where I see the difference. Agile design and development means you can have all three.

By: David Heller

David Heller — Mon, 13 Feb 2006 06:38:58 +0000

I don’t get it ... Seriously, this looks interesting on paper, and I in spirit like the idea of agile design, but you can’t do research iteratively. It is an upfront process that actually is used for determining core strategy that you need before you even begin the design process itself. Even that being said, design up front is required for framework development that is necessary before the core architecture can go too far along. There are opportunity costs and resource wasting. It assumes that your development team and design team are working in tandem on linear processing, instead of in a hop-scotch manner between 1.0, 2.0, 2.2, etc.

There is an old consultant’s addage ... fast, cheap, good ... pick 2, but you can’t have all three. There is always an opportunity lost if you do fast, cheap and not good and visa versa.

That being said, your bullet points at the end of your manifesto are completely on target, but I see those as just good design practices that have very little to do with Agility. The only exception I take is “rapid & iterative”.

Design done well reqiures reflection, requires exploration, requires non-linearity. It is the core of design thought and practice for the last 100 years, and to remove it, is to turn design into engineering. Again, we are on this pendullum of moving from technological focus to aesthetic focus and swinging back to technological. There is a happy place that I imagine where the 2 are married with sacrificing either for the greater good of the two real focuses of our employment: business and users.