Developers, I know this might hurt, but it has to be said: beautiful, logical architecture within your code does not magically lead to software that users find equally beautiful and logical to use.
The sad state of most software is largely a result of ignorance to this distinction, leading to development practices that privilege the concerns of developers above those of users.
I found a striking illustration of this in Eric Evans’ well-regarded book, Domain-Driven Design. The needs of users appears as only a shadow amidst discussion about the design of data and logic.
This is the design process that Evans recommends:
- Developers extract and clarify business needs through conversations with customers (who may not be the actual users of the software).
- Through great intellectual effort, developers convert the business model into a software model.
- Back and forth dialogue between developers and customers ensures the accuracy and viability of this model.
- At the end of this process, a single model exists which represents the needs of customers and guides developers as they write code.
The deficiency of this approach for building human-facing systems is illustrated by an example provided by Evans himself. In the example, he tries to show the dangers of “superimposing” a UI model that differs from the underlying business/development model.
A user of Internet Explorer thinks of “Favorites” as a list of names of Web sites that persist from session to session. But the implementation treats a Favorite as a file containing a URL, and whose filename is put in the Favorites list. That’s a problem if the Web page title contains characters that are illegal in Windows filenames. Suppose a user tries to store a Favorite and types the following name for it: “Laziness: The Secret to Happiness”. An error message will say: “A filename cannot contain any of the following characters: \ / : * ? " < > | ”.
In Evans’ opinion, silently removing illegal characters to eliminate the error is unacceptable, which leaves two possible fixes:
- Expose the underlying filesystem to the user and have them deal with Favorites like they would any other file.
- Change the way Favorites are stored to eliminate the problem of illegal characters.
Amazingly, Evans treats each of these options as equivalent. The first solution increases the work users must do, forcing them to interact with the filesystem, while the second option simply removes constraints, keeping the simplicity of the Favorites model. Each of these solutions is logically valid, but only one is correct. It is only blindness to the needs – and frustrations – of users that allows them to be treated as equal.
The first solution is seen as viable because it retains the purity of the codebase and requires no work from developers. Instead, the burden is shifted onto users.
Evans makes the dubious claim that “when a design is based on a model that reflects the basic concerns of the users and domain experts, the bones of the design can be revealed to the user to a greater extent than with other design approaches.”
Exposing “the bones of the design” means expecting users to have the same mental model as the developers. This is exactly the problem: developers expecting the beauty of their code to lead to beauty (or even clarity) for users. This is a fundamentally wrong assumption.
The mental model of users is the model that should inform the design of software. The needs and goals of users must take precedence over the desire of developers to write beautifully architected code. If the purity of the code would suffer from a change that enhances the experience of users, then the code should suffer.
The design process that Evans endorses is a fine way to handle the collection and analysis of business requirements. But this must be paired with a design process that focuses explicitly on the human facing parts of the system. Agreement between customers and developers does not ensure the soundness of a design. Users don’t really know what they want, nor do they understand the complexities of software well enough to drive the design process. The specific skills and methods of designers (interaction, user experience, whatever they happen to call themselves) are needed to distill the real needs of users. Even then, a designer must continually evaluate his or her work through direct observation of users in front of running software.
The contrast between these different approaches can be seen in a classic debate between Alan Cooper and Kent Beck, appropriately titled Extreme Programming vs. Interaction Design.
In the ten years since this discussion, Cooper and the interaction design community have moved to incorporate the agile/lean methodologies championed by XP. However, while the value of design for software has become more apparent, my own experience with developers is that many still do not grasp the real consequences of designing software from the perspective of users, not themselves.