As a graduate student at Harvard University, one of my main influences was the Austrian philosopher, Ludwig Wittgenstein. Wittgenstein argued that many philosophical statements, and indeed, much of philosophy itself, became preposterous when applied to the real world.
Since completing my doctorate in philosophy, I have been a professional programmer for more than twenty years, and I have learned a lot about applying philosophical thinking to design and development. Philosophy offers deep and profound insights about subjects like knowledge, meaning and justice. Insofar as computer programs concern these subjects, philosophy can be a fantastic source of ideas – and often is. Reading philosophy books has given me ideas for writing useful computer programs that span multiple industries, from healthcare to business, which contradicts Wittgenstein’s belief. After all, if philosophy can guide the design of profitable products, it must be meaningful.
Ideas and techniques from such varied philosophers as Ludwig Wittgenstein, Jean-Jacques Rousseau, Rene Descartes, Karl Marx, and W.V.Quine can advance UX development and design. In this article, we’ll explore three software challenges, and the solutions philosophy inspired.
Solution#1: Descartes and Austin complete sales
Every point-of-sale (POS) transaction faces the same challenge: how do we bring users through the sales funnel and complete a sale? We know we must provide enticing content and a positive experience, but how? A certain number of prospective customers are expected to leave without purchasing, but the designer of a POS system wants to keep that number as low as possible.
In order to reduce the number of times users abort a POS transaction, we consider an idea from the philosophy of knowledge. Descartes, in his Meditations, tells us:
“An evil genius not less powerful than deceitful, has employed his whole energies in deceiving me; I shall consider that the heavens, the earth, colours, figures, sound, and all other external things are nought but the illusions and dreams of which this genius has availed himself in order to lay traps for my credulity”
Descartes, Meditations
In other words, if someone (in Descartes’ words “an evil demon”) misleads us, we might believe them because what they say is in keeping with what we have seen and heard and felt. For a company like Airbnb, this is exactly the problem UX designers face: the UX designer wants to help users feel comfortable renting an apartment, and so they write engaging copy and show beautiful images. But the user still has no reason to trust the company. How do we combat the problem Descartes outlines and Airbnb faces?
J.L. Austin countered Descartes, three centuries later, saying that philosophical skepticism mischaracterizes the logic of human knowledge. In daily life, claims are doubted only when circumstances suggest a special reason for doubt. Descartes has no special reason to worry about an evil demon, thus his doubt is illegitimate.
Austin’s philosophy of doubt can be encapsulated as a simple interaction design pattern. Whenever A has a doubt about B, the system has to let A know why A should not worry about B. In the context of Airbnb, UX designers solved the problem by implementing rating systems and reviews, which reassure uncertain users that their doubts—like Descartes—are unnecessary.
| J.L. Austin says: | Legitimate doubt is contextual. |
| Philosophical use: | To criticize philosophical skepticism. |
| Use in UX design: | The effectiveness of a software application hinges on specific knowledge of users’ needs. By accommodating doubt patterns (i.e. opportunities to explore alternative design paths), UX designers can support questions about perceived or presumed knowledge and create better experiences. |
Solution #2: Quine solves documentation
Not too long ago, I was asked to fix database code that returned a list of “products shipped but not billed.” In the course of my work, I eventually encountered the code responsible: a complex bit of code that ensured that no products shipped out of a certain subinventory in the warehouse would ever be billed. When I asked the team who had coded this rule, no one had any idea—there was absolutely no documentation.
In my experience, where there is inadequate documentation, there is usually a programmer—we’ll call him “Bob”—who obviates the need for documentation. Whenever someone needs to know something, Bob has the answer, but he doesn’t have time to write it all down. Sometimes a new manager comes in and asks what the team would do if Bob left, but no one takes it seriously—until Bob does leave, and no one has any documentation for their systems.
Fortunately, there is a philosophy of language which recommends a solution to the Bob problem, known as The Indeterminacy of Translation. The Indeterminacy of Translation is the view that there are innumerable different – yet correct – ways to translate any given sentence. A philosopher named W.V. Quine explained that Indeterminacy of Translation is most easily understood by considering the problem of translating a new language:
“An artificial example which I have used elsewhere depends on the fact that a whole rabbit is present when and only when an undetached part of a rabbit is present; also when and only when a temporal stage of a rabbit is present. If we are wondering whether to translate a native expression “gavagai” as “rabbit” or as “undetached rabbit part” or as “rabbit stage” we can never settle the matter simply by ostension….the trouble is that whenever we point to different parts of the rabbit, even sometimes screening the rest of the rabbit, we are pointing also each time to the rabbit. When, conversely, we indicate the whole rabbit with a sweeping gesture, we are still pointing to a multitude of rabbit parts.”
W.V. Quine, Ontological Relativity and Other Essays
Quine’s doctrine is that there are no facts which can show “gavagai” means “rabbit” and not “undetached rabbit parts.” Equally, according to Quine’s explanation, Bob’s omnipotence is a myth—and Quine provides a “solution” to both the Bob problem, and the problem of indeterminacy:
“It is meaningless to ask whether, in general, our terms “rabbit,” “rabbit part,” “number”, etc., really refer respectively to rabbits, rabbit parts, numbers, etc., rather than to some ingeniously permuted denotations. It is meaningless to ask this absolutely, we can meaningfully ask it only relative to some background language. ..We need a background language, I said, to regress into. Are we involved now in an infinite regress..In practice of course we end the regress of coordinate systems by something like pointing. And in practice we end the regress of background languages, in discussions of reference, by acquiescing in our mother tongue and taking its words at face value.”
W.V. Quine, Ontological Relativity and Other Essays
Suppose a code repository allows the association of our code with all design conversations and artifacts that relate to the code. Then we can support a simple interaction design pattern, called “clarifying the meaning.” When we reach the point in the code that is unclear, we index to all the conversations and artifacts that relate to that point in the code. This is documentation, but someone like Bob won’t see it as a waste of time, as it can be done quickly and while coding. Thus Quine alleviates our Bob problem.
| Quine says: | Two manuals of translation can be consistent with all observed behavior and yet diverge, intuitively speaking. |
| Philosophical use: | To attack the idea that mental entities determine meaning. |
| Use in UX Design: | Quine’s ideas suggest that the repository provide widgets which support the attachment and display of searchable discussions about what the code means (and the artifacts that accompany these discussions). |
Solution #3: Mill maximizes project happiness
We’ve all been in projects that were nearly finished when one or more stakeholders intervened with opinions that dramatically changed the course of the project. It’s incredibly frustrating for the designers and developers who attended all the right meetings, invited all the stakeholders, and yet are now faced with new requirements or merely changing minds. The worst of it is that often the stakeholders don’t seem to have any particular agenda in mind—they just want to be heard.
One philosophy that helps us to solve this problem is utilitarianism, as defined by philosopher John Stuart Mill. Utilitarianism is the view that the right action is the one that maximizes happiness. He explains:
“It is quite compatible with the principle of utility to recognise the fact, that some kinds of pleasure are more desirable and more valuable than others. It would be absurd that while, in estimating all other things, quality is considered as well as quantity, the estimation of pleasures should be supposed to depend on quantity alone.”
John Stuart Mill
We can incorporate this into a design for project planning software that includes not only project member’s names and roles, but also their goals and what makes them happy. By tracking happiness alongside responsibilities, the project manager can help stakeholders to feel heard or otherwise satisfied before the end of the project—and without last minute requirements changes.
| Mill says: | The right action is the one that maximizes happiness. |
| Philosophical use: | Mill thought the general acceptance of the utilitarian principle would lead to a harmonious and stable society. |
| Use in UX Design: | Mill’s view might also suggest that customer-facing software consider the happiness of each customer as an individual element in the success of the endeavor. |
Where Do We Go From Here?
In short, although philosophy cannot provide an algorithm for solving every design problem, it can contribute to UX design. Practitioners can channel the abstractions presented by philosophy into practical principles for real world design.
To get started, follow these three steps:
- Choose a difficult or frustrating design problem.
- Read a new philosophy (Spark notes are allowed!)
- Write down every possible way the philosophy might deal with the problem at hand, no matter how unrealistic the answer might be.
Alternatively, a less weighty approach: take a philosopher out for a beer, which can provide the basis for profitable inspiration.
Learn more about applying philosophy to design at UX Brighton 2014 – Practical Philosophy, where David will be discussing these ideas in more detail.