A personal soap-box issue which my colleagues and friends are certainly tired of me ranting about is what I call the ‘design vacuum’ present in many, if not most, software vendor’s product teams. So I figure it’s high time to rant about it here!
Traditionally, the majority of software companies have been culturally engineering-centric, by which I mean that for the vast majority of software developers there is no tradition of Design as a distinct discipline on a par with Development. This is in stark contrast to virtually every other product-oriented business in existence – CPG, automotive, white goods, consumer electronics and entertainment media nowadays all place at least as much emphasis on design as on engineering, more often than not with dedicated design departments at least as large as their engineering colleagues.
Before we get into why there is no Design tradition, let me explain what I mean in a bit more detail: Even massively complex professional software products, requiring tens of developers, frequently have just one or two dedicated design staff, themselves rarely qualified interaction designers and who would quite often be better described as ‘domain experts’. In some cases, they don’t even have much domain experience – I’ve even seen junior QA testers taking on product and interaction design roles at major software vendors (rather unsurprisingly, the resulting products leave a lot to be desired).
In many teams, including some that I have worked with, coders are given the title of “Software Design Engineer” as if it will in some way dissolve away the rather obvious contradiction in terms. For me, with a couple of significant exceptions, “Design Engineer” is an outright oxymoron. There is an inherent conflict of interest – engineers are close to the code and are motivated to minimize the complexity of their engineering solutions. They are rarely motivated to understand broad user context, or to design for overall user fulfillment. Alan Cooper puts it well in About Face 3:
There is an important conflict of interest in the world of digital product development: The people who build the products – the programmers – are usually also the people who design them. Programmers are often required to choose between ease of coding and ease of use. Because programmers’ performance is typically measured by their ability to code efficiently and meet incredibly tight deadlines, it isn’t difficult to figure out what direction most software-enabled products take. Just as we would never permit the prosecutor in a legal trial to also adjudicate the case, we should make sure that the people designing a product are not the same people building it. Even with the appropriate skills and the best intentions, it simply isn’t possible for a programmer to advocate effectively for the user, the business, and the technology all at the same time.
Assaulted by unhappy, frustrated users and thus at least partially aware of the sub-optimal results that the ‘design engineer’ approach produces, software engineers and development managers have been exploring ways to produce better digital products (albeit without ceding design-leadership to a dedicated team, and thereby necessitating a potential reduction in development resources).
Enter Agile development methods – a family of approaches that offer, arguably, a quick way to evolve adequate products with minimal design investment, and a way to adapt development to changing requirements. Agile methods replace many traditional Waterfall processes with tight iterations based on continuous customer feedback. Agile methods’ purported benefits are that they allow teams to be more responsive to customer needs, offer faster time-to-market and more frequent stable product releases. Undoubtedly, it is possible to achieve a fast release turnaround, and to be very responsive to those users that get a voice. But at what cost? Well, I promise to look at this issue in detail, along with the other pros and cons of Agile methods, in a subsequent blog post. In the meantime, I’ll leave you with a little excerpt from a 2003 post by Dave Cronin over on the Cooper Journal:
The way RUP (and other “agile” development philosophies) deals with [changing requirements] is to accept it (however unfortunate it may be) and to optimize development practices around managing and responding to change. This is an understandable approach, and makes a lot of sense when you think about what the development team has to work with, but I also think the attitude is defeatist. It is little different than throwing out your roadmaps before your cross-country trip because there’s really no telling how many flat tires, rain storms, and rude drivers you may encounter along the way.
I think that’s right on the money – and as I said, I promise we’ll return to the agile discussion. But now let’s get back to why there is no design tradition in software development, and what we can do about it.
First, I think it’s useful to recall that today’s software development industry has it’s origins in scientific academia and the military; the first software products were by scientists and engineers for scientists and engineers. These are not communities known for their difficulty with complexity, nor for their extensive aesthetic vocabulary. In such times, users were invariably programmers themselves. They were solving complex problems for incredibly smart people, often in rather esoteric fields. As a direct result, the software industry evolved cultural and developmental practices that were far more suited to controlling nuclear reactors or understanding particle physics than finding simple ways for (for example) my daughter to make 3D movies and post them online.
Second, although the ability of computers to present things in an intuitive, graphical way may be ubiquitous now, it is comparatively recent in terms of the history of computers, with graphical environments themselves appearing less than thirty years ago. We’re only just beginning to have a handle on this, and to a huge degree it is thanks to the videogames industry, whose products are highly visual and exclusively consumer-focused, that things have progressed so quickly; the stereotypical VCR perpetually flashing “12:00″ illustrates well how little the consumer electronics industry contributed to the evolution of good interaction design with it’s earlier efforts.
Before GUIs (Graphical User Interfaces) came into existence, the software industry had already had to develop interaction methods. Many of those methods became standards that are still in use today (scripting, command lines … even keyboards themselves). Typically, such early affordances involved significant mind- and muscle-training on the part of users to become adept, resulting in modes of use and interaction paradigms that infected a couple of generations of users, and are still around today. (It may be worth noting that esoteric interaction methods have an interesting tendency protect revenues for the senior, seasoned professionals in many fields, thus indirectly reducing the rate of innovation – but that’s a whole other story for another post.)
And I speak from personal experience when I say that, as we get older and creakier, we tend to cling to the ways we know, which clearly extends to our relationships with digital products. With age, we find it harder to adapt to the new: A significant percentage of the current generation of senior software ‘design engineers’ and managers are of my forty-something generation, replete with all the pre-interaction design computer-science baggage that our age entails.
Third, and finally, software is often perceived as an infinitely malleable medium, with negligible manufacturing or inventory overhead, meaning that if one ships a dud release, just shipping and update fixes the problem. There’s minimal discarded inventory or wasted materials – if it’s a boxed shipment, then there’s a DVD ROM that needs to be re-duplicated, if it’s a download, just stamp a new build, re-do the release QA, and update the .zip file on your download portal. This is a far cry from the huge costs associated with botching a CPG product and hardly a situation conducive to careful advance planning.
Companies such as Microsoft have very effectively used the ’ship it and see’ approach to help dominate the markets they compete in: Everyone familiar with Windows knows to wait until the first Service Pack is made available before switching to a new version, when a great many glitches, inconsistencies, workflow and performance problems are ironed out. It doesn’t make people happy and fulfilled (witness Microsoft’s brand perception issues; the company we all rely on, but love to hate), but it turns out that, at least in the case of Windows, getting to market first has a bigger impact on revenues than ironing out all the glitches and thus improving customer perception. Personally, I think the long term damage to the brand will outweigh the time-to-market advantage, as we’re already seeing with the migration to Apple in some affluent, quality sensitive segments (designers, CG artists, etc), and that design and quality must play a more dominant role. I think Microsoft, too, recognizes this – the recent versions of Office and Windows bear witness to a remarkable increase in investment in user-centered interaction design. The core Office 2007 applications are a tour-de-force of brilliant and yet sympathetic interaction design – even those of us who know the older versions inside out had little trouble migrating to the new releases, despite their radically updated organization.
***
So how to we address these barriers that are stifling the emergence of ne and innovative products that escape the old-world baggage and truly embrace the potential of software as a medium with with we can have rewarding relationships? Clearly, there are a lot more to these issues than I have presented here, with business goals and wider economic context playing a significant part.
The first step in getting to grips with software products as designed, not developed, artifacts is to begin to think of the present challenges as culture problems and not as process problems. The goal can no longer be to “ship a product on time and on budget”, but rather to “delight and capture the hearts of a community”, who naturally choose to invest their time and efforts, and generate value using the most desirable option available to them.
Design is at least as broad and deep a discipline as engineering, and as we have seen, it is practically impossible for an engineer to be an effective user advocate.
The software ROI equation employed by many vendors needs to be re-evaluated: More design investment leads to more desirable products, which in turn leads to more fulfilled, effective and (most importantly for vendors) loyal customers. Happy, loyal customers often become passionate evangelists. This, then, is a perhaps formula for long-term success.
