The Role and Evolution of Design in Software Products
Published: February 6, 2006
Design professionals often decry the lack of importance and investment their companies place on design. After all, most software projects revolve around a product’s engineering, to the ongoing detriment of its design—not to mention the chagrin of so many designers, who wriggle uncomfortably toward the bottom of the food chain. But there is a good reason for this: products can be very profitable without investing a single penny in interface design—at least, beyond the user interfaces the engineers build. Indeed, at least in the early stages of a market or company, resources dedicated to intentional interface design are often a bonus rather than being viewed as a necessity. Sound crazy? Consider the natural and normal evolution of a software product:
- It starts with an idea.—In the beginning, somebody has an idea. They see a market opportunity, or they see a solution to a problem, or they see something that they find fun or enjoyable. They have vision, they imagine a product or service, and they want to make a commitment to make it real. That is where it begins: in the mind, in the realization that an opportunity possibly exists to create something new and different—or better.
- Then, the idea must become real.—Having an idea is not enough. For the idea to have value, a company must make it real. If it does not work, there is no product. For a software product, making an idea real requires engineering, and engineering can also produce the product’s user interface. It may not be very usable or attractive, but at least it can work. It is through engineering that the product becomes real.
- Finally, the real must become ideal.—This is where design often enters the equation today. Once engineering has built a functional product, people realize they need to make it more attractive and/or usable, and formal, professional, intentional user interface design becomes necessary.
Traditionally, before the industrial age and particularly before the discovery of various forms of convertible energy such as crude oil or coal, making ideas both real and ideal was design: it was the entire process of giving an idea form, shape, structure, and function. A single person could take creating something like a great dining table from idea to fully realized product. But once we learned how to convert various natural materials into energy, the problems of creation became exponentially more complex. There are many scientific and mathematical issues around integrating and using these forms of energy in products. For example, there are thousands more variables in creating a jet airplane as opposed to a horse-drawn cart, specifically because of the highly complicated physics and chemistry and the overall complexity that accompany such manufacturing. The amount and degree of knowledge this takes is beyond the capacity of any one human being.
Creating software is similar, in that making software requires a great deal of engineering acumen, which typically requires a very different skill set, process, aesthetic, and training than user interface design. Whereas with a table, one person (the designer) could accomplish both the what (idea) and how (creation), software requires another complicated step (engineering) to provide the how. This is true to a large degree on a product’s back end and to a lesser degree on its front end. It is highly unusual and—in the case of large or complex products, literally impossible—for any one person to craft the entire thing in a truly skillful way.
Thus, in many contexts, the result is the divorce of form and function at the most basic problem-solving level. And while both are certainly necessary and inherent in any product, function precedes form in anything that is built for use. So it is possible—and often the case—that engineers build ideas into reality without giving much thought to formal, intentional user interface design. And because so many ideas—particularly in the high-tech software space—are notable because they stretch the bounds of technology and apply technology to new areas of functionality, it becomes a self-fulfilling prophecy that dedicated design is simply not necessary for young products. After all, if an engineer can build a product that lots of people will buy and use, that makes a company money, and can create and update it in reasonably controlled periods of time, what impetus is there for good design? In fact—and now it is officially time to cover your eyes, designers!—in these cases, there is often no compelling business reason for immediately addressing design on such a product. Initially, getting to market—the right market—and differentiating a product through technology are essential. While design may become a factor once the market catches up to the technology, at first, it is more important to keep competitors from catching up; then, later on, to stay ahead of them through good design.
Of course, capitalism drives much of this reality: if there were no reason to get something done quickly or first, in order to get the money, focusing on a product’s form and function together in the very beginning would be much more natural and desirable. But there is little incentive for this approach in the real world, where the rewards go to the first mover before the best mover. So we are caught in a perpetual cycle of design being a lower-order priority in the creation of software products. And while we might not personally like this—and understand that it ultimately contributes to inferior products—it is hardly surprising given the realities of our economic model.
Happily, software in general and the Web in particular have reached a stage where much of the foundational technology already exists, and many of the corporate giants in our space are now forced to turn to good design in order to stay ahead or achieve meaningful differentiation or meet and exceed the expectations of an increasingly sophisticated and demanding user base. But in most cases, when we are talking about new technologies—pushing out the frontiers of technology and what is possible—the emphasis is on technology, possibly to the complete neglect of a separate and structured design process for a product’s user interface. This is something we should not only come to expect, but even to understand.