Design vs engineering: not an either-or
A serendipitous collision of two worlds through links passed via Twitter today. First, a nice rant from Andraz Tori from Zemanta: Do semantic web interfaces have to be ugly?. Tori bemoans semantic web applications that let their clever technological underpinnings and perfect abstractions hang out for all to admire, rather than focussing on helping the user to achieve their goals through superior user experience design. Well and good. Then I got linked to an article by Brian Zmijewski of Zurb: Fewer engineers please!. In this piece, Zmijewski argues that smaller project teams are better: if two pizzas can’t feed the team then it’s too big. In particular, the suggestion is that there should be fewer engineers messing up the user experience design (ok, I’m paraphasing a bit … but only a bit). Separate from the main thesis (I’ll come back to that), the most interesting part of the article is the furious reaction in the comments, mostly from engineers who claim that the only role of designers is to “pretty things up”, presumably by picking exactly the right shade of pastel or something. Of course, if I can borrow an American phrase, that’s a total crock. Designers do much more than that. But equally, engineers shouldn’t be parodied as introverted inaesthetes either. Nobody wants to develop a poor product or let down customers and users. It’s bad for business, but it’s fundamentally unsatisfying to work on something that people don’t like or won’t buy.
What’s most depressing to me is to hear from both sides “No, we solve problems - that’s our training”. And it’s true, both engineering training and design training focusses on solving problems. Which is right? Well, it’s not a zero-sum game, so both camps are correct – up to a point. What we need more of, in my view, is really thinking about the end-user. The design community have, traditionally, had a greater strength in this regard, but it’s a teachable skill and it’s a skill that should be shared and developed, not hoarded. Design thinking should not the sole purview of design_ers_. Let’s work together to build some non-ugly semantic web interfaces, and other great products.
Are small project teams better? It’s axiomatic that adding more people that necessary just increases waste and delay, but arbitrary rules are silly. It depends what you’re trying to achieve. Yes a small teams can do good work, but, for example, nearly two thousand two hundred people built the LHC. That would be a singularly big pizza.
In summary: fewer arbitrary rules and demarcations, more user-centred renaissance developers.