Oct 19 2007
Agenda: addendum
I’ve been ruminating on the Agenda I set for this reboot of Cognitive Friction, and my attention has settled on to the process issue I identified in that post. I’ve spent a great deal of time this past year creating and refining detailed design specifications for various clients and then struggling to get these products built in the way I intend by either a team of in-house software engineers or a third-party web development house. On reflection, it is the frustrations I’ve experienced in this process that has most induced me to blog again. So, I want to focus on two specific aspects of the development process:
- The role of prototyping and design specifications and the wisdom of spending time on these design artifacts as opposed to just diving into the build process.
- The role of design and designers in the development process and the relationship between designers and engineers
So what’s bugging me about these two specific issues? Well, I have been struggling to reconcile the approach to user experience deign advocated by two parties I greatly admire: The good folks over at 37 Signals and the equally bright people at Cooper Interaction Design.
Alan Cooper vs. 37 Signals
There are two opposed positions on the issues listed above that I can’t satisfactorily reconcile, and wish to explore further in subsequent posts. I’ll attempt a summary here by way of a preface to what will follow:
- The guys over at 37 Signals contend that anything more than a few design sketches is a waste of time. They prefer to start to build as soon as possible, because the sooner you can interact with something concrete, the better they say the end design will be.
- The people at Cooper Interaction Design hold that you need to design the whole thing in great detail up front before the build can begin. This entails lots of user research, requirements analysis and the creation of an exhaustive form and behaviour specification.
So which is it? The Agile Auteurs model from 37 Signals or the Product Engineers model from Cooper? It is this dichotomy that I most want to address in this blog and in my professional practice. I have a number of half-formed posts in draft on these issues, and I will try to get them out as soon as I can to start raking over this ground and see where it is I stand.
Technorati Tags: 37 Signals, Alan Cooper
Hi John - an excellent issue to try and tease out. I come across all the time with my web clients (compounded by the small business lack of funds that mean they’re inherently suspicious of lots of planning).
I’ve done both approaches - the Cooper big workshops and big documents version, and the 37 Signals throw something together and see how it looks version. Both have problems:
- lots of the big workshop approach seems to involve stating the bleedin’ obvious, which slows things down
- too often, the throw stuff together approach results in whatever you threw together being the finished product
i don’t know if there’s a middle ground, but I know that I just got hired by a big client because (and I quote) they ‘love my process’ - which is pretty much JJ Garrett’s ‘Elements of User Experience’ with a bit of Cooper’s persona/scenario stuff thrown in.
My sense is that the larger the site, the more clients will let you get away with more planning (which makes sense). Sorry I’ve got no more insight than that, but it’s Friday evening.
John, my experience building websites has been most of the clients with smaller sites were much happier to be presented with the final plan - with a small project it’s always seemed easier for me to hold it all in my head and then produce the final object straight from there.
When working on much bigger sites, I’ve generally had to produce much more detailed plans and work through them in depth. I think this is more to do with the sheer number of people involved than any intrinsic requirement of larger sites - everyone on the client side wants to have their say, and generally it’s that their area should be at the top and everything else is irrelevant.
I lean towards the 37 Signals approach usually - I think that their concepts are used much more prescriptively by many fans than the 37S team, and as taken as guidelines rather than gospel, they do make development much faster, being able to iterate rapidly can lead to some real breakthroughs.
Rob, David, many thanks for the comments guys. You both hit on the issue of scale and complexity, which is central, but I think here’s more going on here. I’m trying to get my thoughts straight for the next post on the issue. I have a sneaky feeling that what the 37 Signals guys do is fine in their context, but doesn’t port that well. I hope to post again tomorrow, when the kids are at their Nan’s, so I’ll see if this is going anywhere then.
I think the main difference between 37Signals and Cooper is that 37Signals rarely design anything that they don’t or wouldn’t use themselves.
37Signals are a consulting company building software that consulting companies like. They are addressing issues that they have first hand experience with, so it makes sense for them to bypass several stages of planning, requirements documents, functional specs etc. They can design,build and user test as they are their own customers.
It’s a real thorn in my side, and with the advent of AJAX, Rich Media and the like I believe/hope the static wireframe will become redundant for web application design.
Instead what we will see are screen frameworks[1], followed by design description documents[2], followed by working low fidelity prototypes[3]. Unfortunately the tools for quickly hacking the last of these are lacking at the moment.
Great to see you back blogging John!
Des
[1] http://www.uxmatters.com/MT/archives/000225.php
[2] http://www.thinkvitamin.com/features/design/deliverables-that-work-design-description-documents
[3] http://protoscript.com/
Some great points Des, thanks. You’ve guessed where I’m going with this. In my follow on post I want to argue that the Agile roots of 37 Signals development methods are not a contributing factor in their success, but rather a natural extension of how you would work if you were:
a. A well motivated and very talented crew.
b. Working in a domain where you are a typical user.
Strip away these factors and you just have a development ethos that is Agile-lite. In the hands of the average bunch of schmos, this approach will probably lead to software that is not terribly good.