This brilliant presentation was given at the IA Summit by Leisa Reichelt, a brilliant Interaction Design/User Experience expert from the UK. I’ve already heard a bunch of others use her metaphor, which I think works really well in illuminating the fact that design isn’t linear at all…it’s a neverending cycle of design -release - get feedback - design, etc.
But most of all, it struck me that this works for all levels of any project, whether it is design, development, customer service, marketing…
You’ve heard a great deal of me over the past couple of years talk like I’m some sort of developer or something. Talking about Onramps and Command Line Interfaces and Microformats et al. I don’t just hang out with the developers for street cred…I hang out with them because it’s essential for me to learn and to see the opportunities to make it easier for people to use, learn and love the products that I’m supposed to introduce them to.
Personally, I’m a strong believer in ‘Great Products Market Themselves’, so I kind of have a stake in it. 
I know that when organizations get big, that they start silo-ing off their teams into “Developers” “Designers” “Customer Service & Sales” “Marketing” and other such job functions…passing the project down the waterfall of disciplines: here’s some code, add design, here’s a design, sell it, etc. However, the most successful teams that I’ve observed are those of mixed discipline. Sure, perhaps explaining how OpenID works to a Marketing hack slows you down in the beginning, but once we realize that it works to empower the customers more, we get right behind you and make it happen with you…we also know how, then, to communicate it to the customer in the terms of ‘benefits’ to them….but so do the developers.
It’s not just that the marketers should get involved in the development cycle, but the developers should also see what’s going on and give input to the marketing cycle, too. Everyone should be involved and accountable at every point. And, if you can’t be there every point of the way, just like in the washing machine, the knowledge transfer needs to by cycled around.
One big team washing machine.
4 Comments
Tara,
What I see happening in software development is akin to the quality revolution in manufacturing. Software development is a process and the state of the art for process improvement is are the techniques spearheaded by Japanese manufacturers.
It follows rather strictly what you are endorsing in your post: get all the stakeholders in the room and discuss ways to improve the process and as a result increase the quality of the delivered product.
Yes, the design-release cycle is dying becuase software is evolving into a continuous process… Google slips new features into their services… Firefox updates frequently…
Getting design, marketing, sales and even users into a discussion about improvements is a natural “quality circle” and is incremental improvement rather than re-design.
Thanks for the writing prompt! I’m saving this for my own blog.
NOTE: All ideas are free. Use, re-use, extend or revise at will.
Check our Six Sigma and any other modern quality methodology for more ideas on software improvement as process.
Tara - thanks for the always interesting observations.
But call me an old-timer, but I’m not sure I completely agree. It’s definitely important that everyone be involved, that everyone have a stake in the final product, and that everyone feel responsible for the total finished experience. But I still think that we all benefit from some specialization.
I’ve seen brilliantly bad marketing ideas come from developers, just as often as I’ve seen so-called “product people” try to influence technical decisions. We all have our stories about “engineering UI” or technologists that get “promoted” to managers.
I think what it boils down to - and what I think you’re saying - is that everyone needs context. Product people need to know what’s possible in the technology, so they can use their background and experience to build a great product. Designers, too, need to know what can and can’t be done, and what tradeoffs they can make that will influence downstream (slipstream?) technical decisions. Engineers need to know the goals of what a product is supposed to do, so they can make choices along the way of what and how to use the technology best. And QA and operations people need to have context so that they can test and deploy in a manner that they believe people will actually use the product, not just the way that it’s spec’ed to work.
I believe that’s true whatever your development methodology. There are some great (large) products I’ve worked on that were developed using a waterfall approach, but they succeeded because we knew not just what but also why we were building it. Conversely, I’ve seen other experiences where you can put a bunch of people in a room, put them in the spin cycle, and all that comes out is agitation.
Call it a washing machine, call it a waterfall, but I think that the key is to remember that everyone in the team’s swimming in the same water - connected to the same lifeline. If one guy sinks, the whole team goes down.
I subscribe to the iterative model but at some point, one has to yell “Freeze!” and launch the thing, collect feedback and start over. And without a degree of strict project planning one is just (speaking as a poacher turned gamekeeper) handing agencies your credit card and saying “Here you are, guys. Go wild!”
Also, I fail to understand why one can’t reach the bottom of the waterfall with ALL the water that’s been tumbling down still in play from each step of the process, with an incremental richness being added as the project progresses. If you have a big team, you get nowhere by starting with 25+ people in the room yelling (including the inevitable database guy who’s a frustrated marketing guru) and arguing over who gets to play with the post-it notes.
And what’s to stop you reaching the bottom and (Escher-style) heading back up to the top?
Bitter experience teaches me that if you mix up different colours in a hot wash, you end up with a murky pink that nobody is quite happy with.
Oh and one more point about Agile (sorry). As an interface designer, I hated doing detailed documentation. As a manager and owner of the final product, I hate people who DON’T do it much, much more - why? Maintainability. Given the inevitable rate of staff churn in the industry, NOT having solid, accurate documentation just isn’t an acceptable business risk. For too many developers, Agile (like Extreme Programming before it) means not having to comment your code properly (takes up valuable development time, apparently)
One Trackback
[...] Agile development workflow described Posted April 29, 2007 ::HorsePigCow:: marketing uncommon » Waterfall bad, Washing Machine good for teams, too [...]