Agile is here to stay. The economic difficulties of the past months have finally put waterfall out of its misery; now more than ever, long requirements phases and vaporous up-front documentation aren’t acceptable. Software must be visible and valuable from the start.
For many designers, Agile is already a fact of life (and for those less accustomed, some recommended reading follows at the foot of this article). We are reaching the point where we must either acclimatize or risk being bypassed. The good news is that Agile does allow us to still do the things we hold dear—research, develop a vision, and test and improve our designs—we just need new techniques. Now is the time to get real, and prove design can adapt, if we want to stay relevant in these increasingly unreal times.
The story so far#section2
Time, research, and ideation have historically been designers’ comfort zones. They suit our natural aptitude for vision and intuition, and allow us to carefully synthesize nebulous things like “brand” and “user behavior” into objects developers love: specifications, sitemaps, layouts, and graphics.
Agile, on the other hand, aims to deliver software quickly and handle change smoothly. The two systems rely on subtly contrasting ideologies: reactive versus predictive, accommodating change versus pre-empting it. Despite these differences, a lot of the Agile Manifesto is fundamentally relevant to designers. Interactions above processes. Collaboration above negotiation. Feedback. Simplicity. All music to our ears.
While designers and developers look at the world from different viewpoints, the Agile philosophy is, at heart, flexible enough to sustain the approaches and views of both professions. There are still ways to fit quality design work into an Agile world.
Research#section3
Given that Agile says “working software is the primary measure of progress,” there’s little room for detailed research. While Agile projects can function without any recourse to users (substituting hunches and “user-scented design”), the output is usually poor. The operation may succeed, but the patient dies.
Proxy users can suffice if team members are sufficiently similar to the audience. Designers should use their expertise to make the call, recognize the inherent bias, and accommodate it. This situation is rare, however, and most projects will benefit from research, lest they quickly build momentum in the wrong direction. The iteration zero is deservedly becoming an accepted way of buying time, but some teams are extending this idea with an additional mid-project iteration zero, in which no user stories are delivered. Instead, developers can tidy up code and plan next steps, while designers can revisit the vision and check that brand, aesthetics, and experience are coherent across the site so far.
Since research must be lightweight, it must also be less meticulous. Fortunately, even one or two short sessions per iteration can suffice. A good approach is to recruit using personal networks (friends of friends, Twitter) and hold short dual-purpose sessions: research for future stories, and guerrilla usability testing for completed stories. If reaching genuine users is impossible, all is not lost. Marketing teams often sit on mountains of demographic data, server logs can help expose search terms, and so on. It’s crude, but even this hacked-together research can help designers fill in the gaps.
These approaches clearly aren’t suited to research-critical projects which, by necessity, require up-front research phases. Some teams try to sidestep this by using satellite researchers outside the Agile cycle to drip-feed research findings when available. However, results appear mixed and useful details can be lost in the gap. For all but the largest projects, designers can gain great insight by doing the research themselves.
Design process#section4
Agile iterations are planned to create a steady development velocity, but designers don’t always benefit from the same uniformity of workload. Therefore it can be worth exposing estimates for design too. Accuracy can be tricky, but even a ballpark estimate can help reduce rushed design and reinforce that design is as critical to the project as development.
“Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1. This is sound advice but should not be taken too literally: some stories will take longer to design than these arbitrary timeboxes. Designers should use their intuition and experience to flag up potentially complex stories in advance, giving themselves increased lead time. It’s bending the Agile rules, but should be encouraged if the product benefits.
Vision#section5
Lack of coherent vision is a common weakness of Agile projects. This stems both from Agile’s modular nature and, to an extent, its inherent power balance. Product owners, for all their strengths, sometimes lack the tactics to appreciate the big picture. Unchecked, this can lead to vague, volatile requirements based on strategic whim, and products faithful to company daydreams, not customer reality. A telltale symptom of this malaise is the “horizon effect,” whereby potential problems are pushed repeatedly from view into future iterations, and the designer is unsure whether the solution works as a holistic whole until it is complete.
Fortunately, we can learn from other fields. Filmmakers operate in a similarly agile fashion, filming scenes in an order dictated purely by logistics. To ensure vision, coherence, and narrative continuity they employ specialists: directors and script supervisors. On the web, designers can play a similar role, but must volunteer and adapt it for themselves. This means getting involved in writing user stories and trying to guide product owners away from over-hasty solutions.
There’s still little time to explicitly explore product vision, but we can get close by chaining user stories together into entire user journeys where possible, and designing those chained stories together. We can then review and test them as whole journeys too. This approach reveals a lot about a user’s overall experience and warns us of holes caused by the horizon effect.
Deliverables#section6
Agile is deliberately light on documentation. Great—more time to spend on thinking and designing. Given this bias, static page comps and wireframes are a dead end. They’re simply too rigid for Agile, particularly now that the page is no longer the atomic unit of the web. Instead, we can favor “interactions over processes” by starting with conversations, not templates, and choosing interactive prototypes over static wireframes.
User experience (UX) designers have a host of options for deliverables. Lo-fi sketches and paper prototypes are ideal mechanisms for sharing design ideas and exploring discussion points, yet they are still surprisingly rare in practice. By sketching lots, quickly, and often, UX designers can rapidly iterate on their work, while building up a paper library of components, buttons, navigation elements, dropdowns, and so on.
Prototyping in HTML or with tools like Axure and iRise can be a good alternative. While all have learning curves, they avoid the ambiguity of sketches (and the paper cuts). They’re also flexible enough for changing requirements, but consistent enough to test entire interactive user journeys.
Visual designers still need to create high-quality graphics so they can’t stray far from Photoshop or Fireworks for the end product. However, they too should be involved in early prototype iteration with UX colleagues. Pushing proposed solutions out early and often can be an alien concept to some, but it is central to the Agile philosophy. To save time, it can be wise to design only one example of each content type—one form, one search results page, and so on. With sufficient communication, the prototype can double as the spec.
Evolving roles#section7
We are told that the modern org chart is hyperlinked, but in many companies design is still a single point of decision. Designers must let go of perfection to produce rapid, iterative work: “90% right” solutions are par for the course for Agile. This can be counterintuitive, but for better or worse, Agile prioritizes the timeline over virtuosity. Certainly it makes designing to impress other designers harder. No great loss.
There comes a point at which compromises become too great, however. In the words of Alan Cooper, “there is no large group of people out there waiting in a breathless delirium to purchase your lousy product.” Best-to-market usually beats first-to-market, and designers naturally work well as quality custodians, lobbying sponsors for extra resources where required to do the product justice.
There can be a temptation when designing quickly to fall back on easy stereotypes and clichés. Drawing on the diversity of others’ creative skills can help. Designers should therefore become comfortable as facilitators, not dictators. That’s not to say design should become a democracy—specialist knowledge is as necessary as ever—but by working together, designers can foster this shared ownership of the design, and also boost the credibility of their own skills. This approach also demands literacy: the best Agile designers, project managers, developers and business owners all have a good understanding of each others’ disciplines.
The future#section8
While many designers are keen to adapt to the Agile world, few believe the Agile community is meeting them halfway. Agile is successful to the extent that, for some, it is dogma: an inviolable best practice in software development. However, Agile is no more “best practice” than Python, usability testing, or microformats. It’s just a tool: sometimes appropriate, sometimes not. To this end we see the emergence of post-Agilism, which tries to retain a lower-case-a agile mindset but deprecates elements not suited to the project.
Regardless of the label, it’s time for the Agile and design communities to agree on our common future. We need each other, but also need to dismount from our high horses and jump from our ivory towers. After all, we have the same goal: giving our clients and users the best we can.
Recommended reading#section9
- The Agile Manifesto — an important starting point for anyone new to Agile.
- Agile software development on Wikipedia.
- Jeff Patton’s AgileProductDesign.com — contains a wealth of information on practical Agile design. See also SpoolCast: UX in an Agile Environment with Jeff Patton.
- Emily Chang and Max Kielser’s Agile Web Design Manifesto.
- Johanna Kollmann, Designing the User Experience in an Agile Context. Master’s dissertation (HCI and Ergonomics), UCL 2008.
Presentations#section10
- Leisa Reichelt, Waterfall bad, Washing machine good [mp3] — presented at dConstruct 07.
- Jeff White & Jim Ungar, User Interface Design in an Agile Environment: Enter the Design Studio — presented at Interaction08.
- Alan Cooper’s The wisdom of experience — keynote at Agile 2008.
- Maria Guidice, Can’t we all just get along? Human-Centred Design meets Agile.
Finally, the IxDA and Agile Usability lists frequently discuss the issue of Agile design.
I admire your passion about agile development and you are right about some of the issues that make design and agile uncomfortable (but often required bed fellows), but I have a few disagreements with 1st the core assumption and then more importantly your understanding about what is design and how it works.
*Core assumption that Agile is what we need b/c of the economy*
Yes, fluidity, agility (lower case “a”), and efficiency are definitely needed, but what “Agile” (upper case “a”) represents is not efficiency but expediency. Agile was first defended in better times as not purely a way to cut costs but to make better software. I haven’t seen this proven yet. I’m not so sure that the case studies show would have actually been better with Agile or without. Cheaper yes, better. Not so sure. But this is a tangent. Your working assumption is that our economy requires Agile more than ever.
Ok, hmm? While Agile may address costs, I’m not so sure it addresses strength of solutions. Example, what is the poster child of software and product design success today? hmm? let’s think about the white chord going down your from your ears to your … oh that’s it, your iPhone or iPod (I’m sure there is one there). NOT done in Agile. Could never have succeeded as Agile. And is the perfect example of what we need to help us during these economic times. We need THOUGHT and Vision and Innovation. NOT Expediency. We need greater investment with less games. We need deeper investments that don’t try to skip important steps. (Derivatives anyone?)
So I really really deeply challenge your primary assumption that sets this whole article in motion.
*Now to the real content of your article. Why Design does what design does?*
Iteration is not a fools foley. It is purposeful and leads to better design. Artistic creativity is an important part of all levels of a design process. It is the core method of exploration of ideas based on the solid and proven belief that the 1st idea is not the best. Evaluative methods suggested in Agile get the current design right, but they do not actually address making sure you are doing the right design (read Sketching User Experience and see Bill Buxton’s and Alan Cooper’s Interaction08 presentations regarding these issues (interaction08.ixda.org). So to me because you don’t really seem to get the importance of real design methods it would be easy to negate their importance towards creating successful products and services in exchange for expediency.
That is really the most important issue there. But I think I also have to take on your example of using film making as a means of being agile. yes, THAT part of the process in film making is very fluid based on the needs of logistics. “Fluid” is rather a funny term in film making though because it is soooo incredibly planned and documented. I mean first there is a script. Talk about heavy documentation. Then designers (get that, designers!) have to do TONS of prep work on costumes, art direction, audiology, etc. usually using TONS of upfront design methodologies, while actors do RESEARCH on characters to better understand them. THEN the line producers take the scripts and usually using storyboards (more documentation) create schedules which have to be prepared meticulously for lots of logistical contingencies (such as weather or personnel issues) way in advance. This is the furthest thing from Agile I could imagine. So while your small piece looks agile, it only works because a greater whole is in place that enables the type of heavy planning that allows for the fluidity of line production that you’ve observed.
*Now am I saying that Agile is capput?*
HELL NO!!! Agile is a great down stream process that DOES add value and bring efficiency to the DEVELOPMENT process. But that does not mean that Design and Development need to be married in some layer merging that in the end makes Development the “man” of a husbandry like relationship between the two important facets of a product lifecycle. Basically, Design should do design as it knows best and keep dev out of its processes and let dev do what it does best and keep design out of its processes (Yes, this is an over simplification, but so is Agile Development). In the end, there is so much more to design that Agile gives respect to (just like most developers don’t feel respect from designers). Its important to remember that Design actually has outlived development (software) for some 100 years or so (not counting the several millennia that architecture has been around as a craft and design process. It has gone through horrible economic crises during the last hundred years as well, including a few big wars.
Now are there ways for Designers to find more efficiencies in their processes the same way that developers have tried to do? You betchya!!! Let’s discuss THOSE!!!! But they need to be discussed from a design-method perspective and not a development/engineer perspective. Our total goal is the same, but the ways we deliver our pieces are sometimes worlds apart and for good reason.
Dave Malouf, just want to say I enjoyed your letter, was stimulated by the directness of your challenge, and think perhaps an article discussing the benefits of traditional approaches to design may be in order. You may even be moved to write that article for us.
@David: Thanks for your thoughts. Always great to hear from a respected voice in the IxD/UX community. I should preface my response with the comment that as a user experience designer I too have led waterfall projects for many years, read the references you give, and agree that the “˜real design methods’ you describe bring notable benefits to design work.
My passion is not for Agile development — it is for making technology better via design. In a world of limitless time, budget and patience, waterfall is undoubtedly the best way to achieve this. Sadly we aren’t afforded this luxury now, nor were we ever. Business owners are already insisting on seeing outputs for their precious investment sooner rather than later. Simply put, few are brave enough to choose months of ethnographic research over putting an incomplete beta up and seeing what happens. Rightly or wrongly, we need to deal with this scenario.
Agile is not a magic bullet for a failing economy. It is merely a tool, as I mention in the article, and for many projects it’s entirely inappropriate. I would include here the domain of commercial product design, which you touch upon with your iPod example. Agile is concerned with software, and is incompatible with the design of a consumer hardware product. I would, however, contend that it is highly relevant to the software side of the iPod experience. In fact, what Apple are doing now — putting new features live, fixing them, iterating based on user feedback and new technical and design innovations — seems very much in an Agile spirit.
I couldn’t agree more that good design needs thought, vision and innovation. Where we differ is that I believe these are all philosophically compatible with Agile. At present, there are weaknesses in the way we try to integrate them, caused in part by dogmatic focus — from both sides — on process rather than pragmatism. This article was designed (and I use that word advisedly) to kick-start debate on how these weaknesses can be overcome. I’m glad it seems to have had that effect, although our viewpoints diverge. (I absolutely second Jeffrey’s suggestion, by the way).
As a final thought, I mention in the article that designers face a choice: stand our ground, or try more flexible approaches. Both options have risks. With one, we risk accusations of irrelevancy or martyrdom, meaning we simply get ignored. With the other, we risk losing the ways of working we’ve previously held dear. I choose the latter, since it puts my destiny in my own hands.
Both Dave and Jeffrey’s timestamps indicate that they posted their comments from, as near as I can tell, somewhere in the mid-Atlantic ocean. Can either of you confirm?
There’s lots of nasty agile developer-types out there who don’t have a good understanding of what design is and what designers do. Please don’t let their ignorant voices squash the good thinking that’s starting to gather inside the agile community – including the agile design community.
For my money, agile finally conjoins the design process with the construction process. To over-extend the movie metaphor, finally lets the script writers and storyboard authors work with the actors; finally allows us to show our audience bits of the movie before it’s done to get early feedback so we don’t end up with another “GiGli”:http://www.imdb.com/title/tt0299930/ And David’s right in that lots of work is done up front on movies before we start shooting. But I’d submit that has quite a bit to do with the cost of “George Clooney’s”http://www.cinema.com/news/item/441/clooney-drops-salary.phtml time – and all the other people it takes to make a movie. If George charged the same rate as an off-shore developer, the process to make movies might go a bit differently.
Most metaphors break down a bit when talking about software… because software is SOFT – or at least it’s supposed to be. By soft I mean easily changeable. Building software shouldn’t be like constructing buildings, or making movies. It can be sorta like them – but the raw materials we work with just aren’t the same. The process should reflect that important context difference. At least one movie director, Robert Rodriguez, has figured out that movies are softer than others previously thought. Look at one of his “10 minute film schools”:http://www.youtube.com/watch?v=4UOa7tkByrw to see film making. They’re on every one of his movie DVDs.
Process design is sorta like software design in that it’s the context that process fits in that matters – just that as it’s the context the software fits in that has huge bearing on its design. For those reasons agile isn’t a one size fits all process. I’m finding that most design processes were designed to fit in a waterfall context – to fit in their design silo. Smart designers working in an agile context have been successfully adapting a healthy design process to work inside of agile processes. I’m sure it’ll only get better.
Ignore the the agile bozos that dismiss design. They’re ignoring an important part of _their_ context – that design is necessary for successful software.
Our CMS appears to have slipped its clock. Thanks for noticing.
Now back to agile design.
Timely article and thoughtful response. I see both the advantages and the complaints at work as part of a small development group adapting to the Agile process in the last year (an effort still in progress). As far as Agile vs. Design, I don’t see it as debating either/or as an approach. I think the main thing to remember is that that Agile is an efficient and responsive development *process*; whereas as a design professional for an ongoing concern, you have to guide your design and proposals towards business *goals* and vision. I think designers can help the Agile development environment, lending an eye and a hand to help keep the ongoing process on target towards an end product design goal (e.g., what the end user needs); and learn something from it at the same time: to incorporate design changes earlier as more direct user needs are learned from feedback, and how to quickly update design implementation to meet more immediate requirements. It seems to me that somewhere in the middle, Agile will meet design so that the whole will reflect more adaptive and effective strategies to industry changes.
We, too, are still trying (after two years) to find how design fits in to the Agile process. We still don’t have a “silver bullet”, but we are getting better. One huge advantage for us is our progress at tearing down the very walls between designers and developers that, for some reason, Mr. Malouf finds counter-productive. Indeed, my take is the exact opposite: By working closely with developers both before and during short-cycle sprints, we as designers have come to better understand the limits and possibilities of the platform, and the developers have come to better understand good design practices.
That’s a win no matter what.
Mr. Malouf is, in my view, correct when he states that Agile hasn’t yet given the design process all the “respect” it deserves, but that only means that we as designers have to educate and evangelize that much more, rather than throw out the proverbial baby with the bathwater.
My problem with agile design work is the loss of perfection. Sure, the apps from 37 Signals are useful, but do I appreciate them like I appreciate the design of Apple products? No. I won’t let go of perfection, it’s in my nature as a designer.
‘Good [enough] is the enemy of great’
Can agile design work for solo projects?
Maybe it’s because I have no formal design training or experience that I’m missing this.
Is this a management approach you’re advocating here?
To use the vernacular of jazz-players – an approach that relies more on collaborative “head arrangements” versus one that relies on charts?
Couldja sum the whole thing up in a sentence or two?
I’m coming away with little more than, “Hey, maybe it’s time we just start winging it and see what happens.”
Tor said: “My problem with agile design work is the loss of perfection,” and I can empathise with this. Especially when budget/time is a scarce commodity, visual perfection can easily be overlooked in favour of additional functionality. From the Agile projects I’ve worked on at Clearleft with Cennydd, I can confirm that a mid-project Iteration Zero is essential for mopping up the details which may otherwise be missed.
Couple cents worth (literally): I think there’s a separation of church and state that has to be maintained, even when one is considering an Agile method.
More increasingly, we have worked with these types of projects and have always tried to keep the actual design process in a separate discovery milestone.
DESIGN VS. PRODUCTION
The true UX and Creative Design portion of any project deserves its own method and respect. It deserves time for the creative process, testing and approval.
However, PRODUCTION design is incredibly well-suited for Agile, and in most Web application projects, it fits incredibly well (almost better than traditional waterfall projects).
So far everyone has focused on SCRUM but there are various items in the Agile/XP toolbox that can be handy for UX. I particularly like pairing for the understanding and co-operation it fosters – a way to make best use of the collective. Mixed with an iterative process to get development involved early and keeping design involved late we all feel like we own the project. There’s a “wonderful article”:http://mikewest.org/2008/11/the-inspiration-of-ownership by Mike West of Yahoo! about aspects of this.
Design is ART + Science. It is that combination of the exploratory, experimental, nonlinear with the rational and analytical.
Recently, in a sketching for interaction design workshop I was teaching I put up on the white board the phrase “planned serendipity”.
Design is the creation of a space where accidents of beauty can occur. This irrational, non-linear space is how you get to “great”. Is how you best innovate, and how you best increase the value of your products over your competitors.
I’m not sure if it is “management” style, but it is definitely work style.
— dave
Tor said: “My problem with agile design work is the loss of perfection”?.
Perfection is in the eye of the beholder, and if there’s anything that you learn quickly in web design, it’s that there is a huge diversity of beholders out there.
I think it’s a mistake to think you can achieve perfection. You can’t, ever. You should be aiming for excellence instead: making your site and applications work superbly well for whomever they need to.
For me, one key thing about agile processes is the rapid iteration and improvement of prototypes. In pursuing excellence, it’s critical to get good feedback on these prototypes to incorporate into the next round of changes. You need to ensure you are obtaining high quality feedback and responding to it.
Catherine, everything is in the eye of the beholder. To make something usable is a great first priority, but the process shouldn’t stop there. The look and feel of something is something every designer should have in mind and strive for. You’re right, a site and a application can never be 100% perfect, but I don’t want to stop iterating at ‘good enough’.
WOW I don’t know where to begin.
While the article is lacking what motivated me to post was a comment. In responding I will also address agile methods.
@David Malouf You don’t understand Agile methods at all. Be it design or development.
To begin with what I learned about agile methods was from a gentlemen named Ken Schwaber. One of the orginial signatories of the agile movement.
Agile methods do not address cost. It sets the potential or ground rules for getting work done. It does not set the project into motion. This is accomplished by different methods most notably Scrum. These methods have built the MRI and heart stints to name two. So they are actually independent
or not mutually exclusive to application design/development.
David it was interesting how you only mentioned Apple as not using Agile. You failed to mention that companies like Intuit, McDonalds, State Farm Insurance (which is HUGE) and many others use agile methods successfully every day. Did you bother to read the principals to Agile methods? I like this one the best.
“Continuous attention to technical excellence and good design enhances agility.”
Agile methods require a rethink of how you approach the design and development process. The two become one. With the client also interacting in the process. This is critical.
“Business people and developers must work together daily throughout the project.”
That customer is just as smart as you. If you think about it
they are the first user group and have many useful ideas and can motivate the process as well as any designer or developer given the chance. I love it when I see the “lights go on” and the client begins to feel empowered and part of the team. With Agile you do not lead or follow. Which brings us to this principle.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
So this not about dev or designers or clients but it is about the interactions of people not whiteboards where ideas get lost but working applications where anyones idea can be implemented.
Please David, Agile is not a downstream process HELL it is not a process at all those are your words. From the manifesto.
“Individuals and interactions over processes and tools”
Most of all Agile requires you to adapt to change and innovation quickly and easily during project cycle. It is demanding and asks for your best.
As mentioned other methods such as scrum and working in pairs
create the kinetics for getting the work done. Unit testing is critical at each iteration be it interaction user group testing or 100,000 unit tests for the code. Each iteration
must pass to continue to the next.
In larger projects teams are separated into developers and designers but all work together and are aware at each step what the other is doing.
Since you mentioned that the design process is somehow exclusive of development and has been that way for the millennia I like to point the Parthenon, the Roman Coliseum, and the pyramids were all constructed by people who trained themselves as multi-disciplined individuals.
Just ask Davnci.
I think developers can learn design as well as designers can learn development they are not mutually exclusive given the proper environment.
I don’t give talks you can’t Google me but I am part of a productive and profitable software firm. We use Agile everyday.
Most of all Agile means letting go of your ego and contributing to the greater good. For some this is a challenge to big to overcome.
bq. David it was interesting how you only mentioned Apple as not using Agile. You failed to mention that companies like Intuit, McDonalds, State Farm Insurance (which is HUGE) and many others use agile methods successfully every day.
You also mention the Parthenon, the Roman Coliseum, and the pyramids. Aren’t we talking design and not development? I think you are missing the point of this article.
The very concept of “waterfall” is unknown in the design community (industrial design, graphic design, architecture). The term originates from the business analysis/software engineering community. If you look at the core processes of industrial design and architecture there is a lot of iteration, collaboration, and reflection involved. They just don’t happen to be Agile software processes. I’m not for waterfall. I am for design first. Meaning LEAD with design. Create a lifecycle that puts design first.
Why in this age, are we even considering using any processes that are led from the engineering perspective to be used to permeate through the total lifecycle of a product.
I don’t mean to be dogmatic or even exclusionary. I just mean to put out what product companies have figured out that software companies are still raging far behind. Nokia and Apple get this pretty well. Their emphasis on a design led approach has had clear success and organizations from P&G to GE have also taken on these innovation & design methods to heart.
The very framework of Agile is a software engineering development framework. It’s core purpose is not efficiency but to create better code (from the early readings). Applying it beyond its original intent is like saying we use a taxi cab as a long-haul truck.
Yes, there are lessons to be learned, but asking design to move toward agile software methodologies has a feel of myopia to me.
So to summarize:
1. being anti-Agile for design processes is not being anti-Agile.
2. being anti-Agile is not being pro-waterfall
3. Agile methods are software methods
4. Design methods have their own toolkit for finding efficiencies
5. Design first is not only good, but in these times of shit software (much of which today IS being done in agile environments) is a necessity. And please don’t say that waterfall is the same as design first b/c it is not. WF is a business analysis/system analysis tool. Most software organizations doing software have never done design. They wrongly believe that design is about aesthetics.
6. The suggestion that design move towards Agile as this article does, while noble, puts engineering in front of design, in a time when design-led organizations are killing engineering-led organizations in the marketplace.
— dave
Nice overview! Thanks for promoting the discussion. For more ruminations on Agile Design, you might want to check out this presentation that Leslie Chicoine and I did at Web 2.0 Expo last year.
“Are Agile Projects Doomed To Half-Baked Design”:http://www.slideshare.net/theinfonaut/are-agile-projects-doomed-to-halfbaked-design ?
(We titled it as a question to be provocative; clearly we believe the answer is “No” :-))
One of our main insights is the need for what we call an “open design,” one where flexibility is built in from the beginning, thus making use of a professional designer’s sense of perfectionism and directing it towards an Agile purpose. Since an Agile project must be ready to launch at any time, the underlying design (graphic, information, navigation) must be able to work well with only a subset of the eventual feature set, and also must be able to plug in as-yet-unimagined features in a clean way.
The slideshare link above has the slides, but I’ve also got an MP3 recording of the event, so maybe if there’s interest I’ll figure out how to do audio synchronization…
Are we talking about visual design, interaction design or both?
A lot of usability and design people seem to be freaking about agile methods.
From Nielsen:
http://www.useit.com/alertbox/agile-methods.html
It is as if Agile methods disempower work teams which is not the case. Who said that Agile is an engineering method at all? It is merely a way to empower work teams so that no one leads. Emphasis is put on self organization. So what comes first in a product lifecycle?
To use the architecture metaphor it is always design. But it is balanced with consultation from engineering design.
The two carry a converse relationship as the velocity of the project increases. !important I used the word “balanced”. If you are doing Agile correctly you are creating a balance between engineering design and architecture that respects the input of people allowing everyone to lead when it is appropriate to do so. After all architects don’t build buildings.
Some work environments already achieve this naturally they are smaller organizations. Larger places like Intuit use Scrum because they have 1200 people working on product lifecycle. BTW Dave GE has certified Scrum masters.
“It’s core purpose is not efficiency but to create better code”
It’s core purpose is to empower architects and engineers. You can apply Agile to the design development and usability of a product. If designers are supposed to be so liberal why is it that many design ideology when they should be designing product?
BTW Dave “shit software” being created by Agile methods? No “shit software” is being created by people that understand in the first place. This is not a he man contest.
But after all of this is said this is still not the issue. All these convention speaking types are trying to monetize what Agile is or is not. They are exploiting the pros and cons and pimping it out for all that it is worth. Me I just sit back smile and make it work for me.
Isn’t that the moral after all? Making it work.
bq. To use the architecture metaphor it is always design. But it is balanced with consultation from engineering design. The two carry a converse relationship as the velocity of the project increases.
Drawing parallels back to the web, wouldn’t the person doing the design also have a good understanding of the ‘engineering’ (HTML, CSS, JS and back-end) seeing what’s possible and what would result in troubles?
Even so, I still don’t see how an agile method would benefit the design work in a project.
@ Tor Designers are not the know all to a project.
I see a pattern among designers that I like to call the Oracle personality. No one is an Oracle.
No one part of a lifecycle should play god.
Perhaps this reference to you and others might help. XP or extreme programming is one way of inducing Agile to a project.
http://www.martinfowler.com/articles/designDead.html
@William — What I mean is web designers, experienced web designers, have knowledge in the fields you’re drawing parallels too in architecture (HTML, CSS, JS and some back end). By no means should the designer run the whole project or play god, I’m not implying that at all.
In my experience, designers with front-end skills usually welcome Agile design. If you stop believing your design time exists only in Photoshop, you can really make a difference with this type of fast evolving design. Whether I’m using layers in Photoshop or manipulating Rails view files, I’m still a designer with a hand in usability and user experience.
I’m glad you like your agile process.
But please don’t assume too much about me. I don’t care about what people say Agile is, I care about how it works in reality and having been on MANY agile projects in many different environments, I have found them all to be failures. Maybe my 8 or so different attempts with it are all failures for other reasons than the agile process itself, but ya know 1x your learn 2x’s your a fool, 3x’s … well. 😉
What is interesting is that you list a host of companies and maybe Intuit is the only one remarkable in their success around customer experience in terms of software. All the rest are well huge question marks. And for every organization that you can name doing successfully with agile I can name 10 doing successfully without it. So what’s the point. It just sounds like religion to me. I’m glad you found your god.
What really gets me about this conversation as I have been trying to dissect it and really understand the issues is not that agile is bad, or incompatible with design, or anything absolute like that, but rather that people try to assume that their success and ways of working are easily generalizable to infinite contexts. This is my issue with these movements (agile or even waterfall approaches like six sigma).
I have had better success trying to extrapolate from the idealized version and parsing it into the specific contexts where I have to live. But in the conversations we get very dogmatic and overly protective and downright silly.
Personally, I think there is still and will continue to be a strong need for upfront delivery in my world. I deal in hardware and you only get one shot at tooling. Software might do well to think about lessons from the hardware world about getting it right once. It does work in many scenarios and has for a lot longer than software ever existed.
— dave
I’d like to add to the interesting discussion Dave started about agile and design:
For me, design innovation can happen for:
a) the big ideas (e.g. products, services)
b) the small details (e.g. interaction design solutions)
I agree with Dave that agile doesn’t allow enough room for coming up with big ideas. For most projects, Iteration Zero is not sufficient to develop a person-centric design vision. Especially when it comes to business strategy and design decisions, understanding the people you design for is important. I see methods that aim to establish this understanding happening prior to agile development. Agile is like running fast. While you don’t need to know what the goal you are running towards will be like, you should know the direction, where the goal is. Otherwise you end up running in circles.
I do think that Agile can support innovation, though. Design naturally is iterative and collaborative. Quick iterations, working as a team as well as the continuous sharing and testing of ideas means that, on the small detail level, I produce more designs. The more ideas the better the outcome will be. Less perfectionism support this: I spend less time on each idea and am more willing to throw stuff away. Agile makes people more open to light-weight tools like sketches, so supports my way of concept design better than waterfall, demanding specifications.
I agree with Cennydd that getting involved in Agile allows UX designers to shape their role and increase an understanding for design and its techniques. This, for me, is the main benefit of agile: by working together, with flexible mindsets and less dogma, we can understand and respect each others’ disciplines. Which could lead to a more people-centred approach.
(I admit being a bit of a romantic idealist here)
bq. Personally, I think there is still and will continue to be a strong need for upfront delivery in my world. I deal in hardware and you only get one shot at tooling. Software might do well to think about lessons from the hardware world about getting it right once. It does work in many scenarios and has for a lot longer than software ever existed.
Isn’t that the whole point? Learning from other? I don’t think design can just take “Agile” and use it. But I am sure there things it can learn from it. Just like Software Development took the concept of Design Patterns from architecture.
On the other hand you also have to acknowledge differences between disciplines. Hardware and software are two very different environments. If you look at the technological standard of the satellites being launched today, you will see they are 10 years out of date. These things take years to build and perfect and you can’t keep on iterating and improving. You have to draw the line to get the thing launched. And once it’s launched, that’s it. You can’t make a quick hack to cover some missed aspect.
The same is not true for software. SW is infinitely more malleable. The truth is you can always modify SW and doing so costs little as it doesn’t mean re-building a $100m satellite or production chain. It simply means re-compiling.
Then you have to look at the clients. Clients commissioning satellites normally know very well what they want. Clients commissioning web sites usually have no idea. Hence Agile is far more useful to producers of websites than of satellites.
Then you need to take changing demands into account. Scientific satellites are going to be measuring something. The client isn’t going to turn round and say I want to measure X instead of Y. The requirements are relatively stable. Whereas if you look most SW, requirements are changing all the time. Often due to legal policy changes. Agile is an attempt to deal with this.
It is worth accepting that there are different ways of achieving a quality product. eg: TDD is often put forward as a way to minimise bugs in SW. TDD advocates to write your tests first. Others often write them afterwards. In fact it doesn’t matter when you write your tests. What matters is that they are written. TDD is one way of ensuring the tests are written. But there are other ways of ensuring this.
Finally, none of this should be taken as black and white. There are always exceptions. It is a shade of grey.
I think the “vision” question is the most compelling in the design v. agile discussion. However to use film making as an analogy doesn’t solve this problem for me. A film has a screenplay, a script, or sometimes even an entire book written before filming. Of course it’s revised constantly, but there is a whole picture there to start with.
Entirely different to design and build one, or a few, scenarios at a time, with little sense of the big picture beyond broad outlines.
Is an iteration 0 with time to map out, say, 20 key scenarios in one place and their relationships to one another really too much to ask? Is there a better solution?
I enjoyed your views on this…thanks! In particular, I look forward to reviewing some of the presentations you list at the end, and checking out some of the HTML prototyping software you mentioned.
I was curious about what you meant that ‘the web page is no longer the atomic unit of the web.’ I would have said that information is still listed on a page (even if it is dynamically generated). It seems to me the web still revolves around putting information about a resource at a particular, static URI. Are you saying that’s not how users view the web anymore?
@AudreyCrane I think the analogy with film making revolves around that fact that movies aren’t filmed in sequential scene order, similar to the way apps aren’t always developed top-down. Yet in both cases, someone has to be the ‘consistency, overall vision champion’ to make sure everything hangs together in the end.
There is no design/development model that will work perfectly for every project. It’s dangerous to assume a particular development model will work every time.
Agile development is the most popular model at the moment because of architectures like Ruby on Rails and Django (for Python). Both of these architectures have been developed towards Agile methods, and for web projects this method (and these platforms) work well a lot of the time.
However, there are other methods, some based on Agile ideals, but still following more classic development patterns that will suit perhaps larger projects better, especially when comprehensive documentation is required along with the product. Not to mention, Agile development doesn’t work very well if the client isn’t available to be involved in the ongoing project. Otherwise, you end up with a project that can easily go off on tangents and never have a finished product.
Methodologies go in and out of fashion just like any other part of the industry. Unfortunately, from a business point of view, Web Development, and other IT in general, is all about buzzwords, even to the detriment of a project.
There are certainly many options out there, and they all have their criticisms, defenders and champions. WaddleWorks in its own right is doing its best at succeeding in the “jacksonville web design”:http://www.waddleworks.net/web-design/community/jacksonville-organizational-and-nonprofit-web-development/ market. Nonprofits and social organizations are not the only ones cutting corners in these economic times, however they are the most dependent on strategic software that agile may or may not ensure. It truly is a case by case trial and error process.
Being able to deliver the capabilities of chatting from your mobile phone and/or your PC with the use of in depth agile software is easier said than done. Then advanced agility concept may be the best solution for you… Though, it does come at a learning curve. It allows interaction from most browsers and from various platforms. On their web site, they have a list of over 250 networking tools to which you can easily set-up and connect your interfaces to and utilize some useful features such as an online graphical, “free chat rooms”:http://rooms.aim2chat.com, monitoring and alerts that tell you how much of what is being used.
As in “(blog cinema)La scatola delle emozioni(blog cinema)”:http://www.lascatoladelleemozioni.it Designer should not be considered actors.