Design and Engineering

A few weeks ago, a colleague pointed me to this article, which led to several other sites, including this one. This colleague and I have discussed the issue of the role of graphic and interaction design in software before, and we tend to agree that there’s a lot of embarassingly unusable software out there. However, I feel very strongly that putting the blame solely on programmers misses many of the more important aspects of the problem. It’s an easy cop out to point at the people who wrote the code and say it’s their fault.

To understand where I’m coming from, consider this question: Who created the specification for the visual and interaction aspects of the software to which those developers wrote the code?

One possible answer is that there was no specification for visuals or interactions—not even a napkin drawing. If there was no specification, then it's extremely likely that no one has really thought about it, and by no one I am including the domain experts, customer liaisons and reps, managers (both technical and non-technical), and developers. If no one has thought about it, it seems a bit ridiculous to expect a beautiful, elegant, and highly usable interface to emerge out of sheer hacking or luck. Unfortunately, in my experience, that seems to be an acceptable expectation in industry.

Yet another possible (and typical, in my experience) answer is that the developers themselves created a specification, either in some document or set of drawings (paper or electronic), or in an ad-hoc way, possibly even on the fly as code was being written. One big problem with this is that developers are not trained in design. They are trained in algorithms, data structures, network protocols, etc. In advanced programs, that training can extend to object modeling, software architectures, and even software project management and the business skills necessary for running a software company. Their training may even include the dreaded GUI programming course(s). In my experience, however, it is extremely rare for any areas of the typical computer science or software engineering curriculum to include interaction design concepts such as mental models, metaphors, and affordances, or visual design concepts such as layout, typography, color theory, etc.

The fact is that, most developers simply are not trained in these areas. However, in my opinion, that is the not the problem. The problem, I believe, is that the general expectation of most executives, managers, and developers themselves, is that all developers can do these design activities effectively. To put it simply, developers are expected to do something they were never trained to do.

Developers are very good at solving problems that involve logic and complex algorithms to process and transform data, but they are typically not good at creating, for example, a color palette that evokes a certain emotional response, or a text and widget layout that leads the user effortlessly through filling out an online form, yet we consistently expect that developers take on the role of design experts. Would it be reasonable to expect a graphic designer to write a program that solves the Towers of Hanoi? Or to create an XML parser? Or better yet, to create efficient and elegant implementations of those things? Or how about a well-defined system architecture for an inventory system to track millions of items across multiple geographically distributed warehouses and distribution centers in near real time? These are not reasonable expectations because designers are not trained to do these things, and typically do not have industry experience doing them.

I think the revival of design in Web 2.0, along with several higher profile companies who have focused on design has started to change the expectations a bit and to educate people on the benefits of good design. Unfortunately, I think it will be a while before the benefits of good design percolate up to the point that expectations really start to change on a large scale.