The value of practice in design methodology

I’ve been exposing myself to more literature surrounding the way design works. In some ways I could call them design literature, but that’s much too broad. Or, I could say it’s about how designers work, but again – not all designers work the same way.

In a way, I’m searching for something about the way design works that’s more tacit – implicit, yet indispensable.

The reason is because working from a methodology or a process vs. coming up with a really good idea isn’t quite the same thing. Speaking to a classmate recently about the way design works, he found it hard to articulate why he designs the way he does. But we both agreed that there are bad designs, and bad designers, and things designers shouldn’t do. And it seems you could put that into a list of things to tick off, but it’s not quite like that.

I stumbled across an article by Michael Beirut on the Design Observer site about his design experience. The honesty in which he admits that design is not too far from a ‘magic spark’ is indeed revealing about the sort of work that goes behind the scenes.

He borrowed the analogy presented by Rob Austin and Lee Devin regarding theatre innovations – how the collaboration of stage crew and artists both handle minute by minute executions within a tightly controlled environment and time span in order to deliver an impact to the audience. The synergy, well-executed, is hardly a random exercise, but isn’t easy to put down in books or spreadsheets.

It’s easy for me to say a piece of software has to be built this way because it requires so-and-so features, but it’s another thing to create something from scratch, and say ‘this is going to work best for the user experience’.

This analogy is clearly based on my own background as a software engineer, and it’s causing me to be more sensitive to how designers learn and apply their “tricks of the trade”. In this sense, Buxton’s Sketching User Experiences book has been extremely insightful – but only if you truly appreciate that what the book is really offering is a peek into the mind of a designer, and not just another tool to whack together a pretty interface.

I’m not discounting the fact that building software relies on tacit and practical knowledge as well, but in the realm of design – this seems more magic than method – hence the question put forth in the ixda discussion board. While good software can most certainly be replicable, can good design be replicable too?

The more I read into it, the more I’m realizing that the answer lies in practice, and the understanding of it.