The Agile Web Design Manifesto, An Introduction
Co-authored by Emily Chang and Max Kiesler of Ideacodes.
On August 20, 1980, Reinhold Messner and Peter Habeler were the first to summit Mount Everest without the use of bottled oxygen. They accomplished this amazing feat by doing what no other expedition had ever done. They carried all of their own gear, did no route preparation, and did not use supplemental oxygen. They were successful where others were not, because they approached the problem from a different angle. After years of climbing experience, they recognized that their two greatest assets were agility and improvisation in the face of constant change. This philosophical shift enabled them to not only succeed, but to innovate, while others had attempted only to survive.
In today’s social web space, there’s also been a shift towards agility and improvisation, and just like Messner and Habelar, designers and developers that adapt and embrace these new conditions will succeed in creating the future of the web. Today’s emerging web applications and services differ from past web companies and sites in a number of ways: faster time to market, lower development costs, greater transparency with users and more social models. Web users have grown to expect a more mature internet – one that lets them explore social spaces, connect via instant, real-time communications, control privacy and sharing with one-click controls, stay up to date with instant, live news feeds, personalize a design, or discover new people or patterns. In her article, “Design 2.0: Minimalism, Transparency, and You,” co-author Emily Chang wrote about trends in design philosophies that support this shift in web applications and online products.
It seems fitting that the web has finally evolved technologically and socially to allow its organic nature to emerge. Designing and developing the web is a live experience and we’re just beginning to witness a new phase of interaction: time-based, collective discoverability, environmental influence from users, mutable to constant change, evolutionary. Agile.
Agile Design Meets Agile Development
Agile software development began in the late 1990’s as several new programming methodologies came onto the scene. One common thread that tied them together was that they all encouraged close collaboration with programmers and business people, constant face to face communication with the client, frequent deliveries of working software, and the ability to program in small self-organizing teams. In 2001 a workshop was held by a group of the thought leaders and practitioners of these methodologies in order to discuss the commonality in their work. They decided to use the word “agile” to name their emerging programming methodologies. They also developed the Manifesto for Agile Software Development, whose most important parts were the statement of shared development values and principles.
The concept of agile design is also not an entirely new one. James Hobart wrote an article in 2002 title, “Optimizing User Experience with Agile Design” where he lays out a great case for using agile design in the development of user interfaces for software application. Scott Ambler, the creator of agile modeling, described that “with an iterative approach to development you work a bit on requirements, do a bit of analysis, do a bit of design, some coding, some testing, and iterate between these activities as needed. It is critical to think through how you’re going to build something, to actually design it, before you build it.” Your design efforts may take on the form of a sketch on a whiteboard, a detailed model created with a sophisticated modeling tool, or a simple test that you write before you write business code. Agile designers and developers realize that design is so important that it is part of the iterative cycle. Design isn’t just a phase you do at the end of a development project.
While forms of agile development have been around for a decade now, some of the newer methodologies have integrated very quickly into the philosophies of web 2.0. Currently our web consultancy, Ideacodes, is designing the user interface and user experience for five new startup companies with web applications and services, all of which have one thing in common – a unique process of collaborative agile design and development.
Think of agile design as user interface design strategy meets agile programming methodologies. In addition to mental mapping, task flow analysis, and user testing, we’re seeing the importance of a new type of agile process. In design, just as in development, “agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility.”
In this new process, we suggest that the core values and principles of agile design closely match those of agile development as a whole. While we imagine that this list will certainly grow and need refinement, there are some major concepts that have already been experienced our clients with great success.
Core principles of Agile Web Design
– Design the system not the surface
– Design as evolutionary and user-driven
– There is no page, only pathways
– Rapid and iterative over final
– Simplicity over complexity
– Collaborative and open design
As we design custom applications for clients at Ideacodes, we’ve adapted and developed several processes to which these principles apply. Our next segment of the Agile Web Design Manifesto will discuss these techniques and more.
Co-authored by Emily Chang and Max Kiesler of Ideacodes.
7 Comments
Join the discussion and tell us your opinion.
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.
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.
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.
i need more !
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.
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…
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.