What is software design?

As I explain in EOS, I’ve coopted the term “software design” to mean something different from what most people in the software world expect. To me, it means designing function: how the software will behave and interact with its users and the world.

So the design of the software is what determines whether or not it fulfills the user’s needs, because if the function is wrong (or confusing), the user won’t be happy. The user interface matters too, but that’s a separate issue (of how the design is presented).

What I particularly do not mean by software design is how the code is structured. That’s important, but more for the programmer than the user. It will turn out that concept design influences code design, but that’s not my focus here.

Why is it important to reclaim the term “software design”? Why not just call this “product design” or “UX design”? The problem with those terms is that they reinforce the way in which software design is typically siloed into different roles in a company, even though it usually involves people across all of them—and in other roles too (such as software engineering and architecture). I want to advocate for the centrality of software design in shaping the experience of users, just as Mitchell Kapor did in his manifesto 25 years ago.

The term “product design” also encourages the misconception that software is no different from any other kind of product, and that it doesn’t have its own design criteria, challenges and principles. My work is in part aimed at dispelling this misconception by showing how rich the field of software design is, and how much has been missed by thinking of software in generic product terms, and drawing ideas from other fields (industrial design, visual design, behavioral economics, psychology, etc) that have limited leverage.