Ever worry you’ll arrive at work to find that your swivel chair has been replaced by a super-intelligent software appliance that can create seven user-centered websites in a single CPU cycle? Haven’t we all? OK, maybe it’s just me. But at some point you’ve probably been asked by a boss or client to squeeze the time and money it takes to design a website to the minimum—by cutting down processes, speeding up your work, and reusing possibly inappropriate code. It seems to me that the ultimate fantasy of this kind of uninformed decision-maker is a robot that can do everything a web designer can, only faster, cheaper, and without asking so many difficult questions—which explains my robot phobia. But don’t give it all up for your backup career as a rock climbing instructor just yet, because it isn’t going to happen this side of the next millennium bug. Nevertheless, we can learn a few things from our fantasy of robot domination.
Design on a production line
Web design is still a young discipline, and it’s generally poorly understood. As the web becomes mainstream, an increasing number of people and organizations want websites—and so more people are involved in commissioning, managing, and designing them. It’s not surprising that many of these people aren’t familiar with how web design works. Clients, managers, and colleagues often assume that web design is a subset of some other discipline, like advertising, graphic design, or software engineering. This creates a tendency to write it off as a low-value, straightforward process that can be streamlined and automated, like a production line.
The result is unhelpful pressure on you, the web designer. You’re asked to design faster, using a smaller budget, and without access to key stakeholders—which can make it difficult to maintain your professionalism, leaving everyone unhappy with the final design. The logical conclusion of this perpetual streamlining would be to stop using your judgment altogether, as if you were a piece of off-the-shelf software: a robot.
A lack of respect
The problem I’m describing is a lack of respect for web design as a profession, primarily caused by ignorance. My proposed solution is to educate, by demonstrating that the value you add to the design process comes from using human judgment and experience—in a way that can’t be replaced by streamlined or automated processes.
But why could a robot never do your job? Because machines can’t generalize. An essential element of a web designer’s job is generalization: a human skill that neither computers nor simplistic processes can simulate. In this article I’m going to describe generalization using some examples, explain why it can’t be done by machines, and conclude that talking about it is a powerful way to demonstrate the value of web design.
Definitions
The Oxford English Dictionary defines “generalize” as:
To form general notions by abstraction from particular instances; to arrive at or express general inferences. [sense 4]
In the context of web design, generalization is the process of creating a concrete, coherent design from a disorganized and conflicting set of needs and objectives.
In this article I use the term “web designer” in the broadest sense: someone who makes websites.
Technology is your servant
One of the most obvious things you could observe about web designers is that we spend a lot of time using computers. Perhaps this is the root of a common misconception: the idea that the main output of web design is a type of computer program—and that, therefore, once we’ve written this computer program, it should be easy to create as many websites as we need. People probably assume that we spend the rest of our time surfing the web. But why is this attitude mistaken?
Web design is about communication. We need to use technology like servers, browsers, code, and databases to make that communication happen. But in a successful website, the technology is the servant of the communication—not the other way around. A professional web designer starts with the communication needs of the organization and its users, and then exercises her judgment to create abstractions of those needs that ultimately end up as web pages—a process of generalization.
These abstractions still need to be technically feasible in order to make it into the final release—but that’s something you deal with after you’ve decided what the “ideal” approach is. The fact that the ACME Content Management System—or even your last project’s CMS—can’t handle your new architecture does not justify ruling it out during the scoping phase.
Web design is a discipline
The mistake of starting with the technology is just one example of the “subset” error that I described above: web design as a subset of software engineering. Other common errors include starting by designing a visual treatment (web design as graphic design), or coming up with a grand concept without considering the user experience (web design as broadcast advertising). There’s nothing wrong with using the approaches of these other disciplines on the web, of course, but they need to be part of a web design process. Web design isn’t rocket science, but it’s not a subset of another discipline—and it’s not as easy as it looks.
So web design is a discipline of its own, and it requires generalization. But what does generalization actually look like?
Generalization in action
Because all websites have different needs and objectives, web design projects need to follow some kind of process in order to be successful. Whatever the details of the process, each stage can be seen as a set of decisions that move us a step further from abstract needs and objectives towards a concrete final website. Every time we make one of these decisions we are generalizing. Here are a couple of examples.
Example 1: scope
Imagine you’re involved in a project that’s based on Jesse James Garrett’s user-centered design process (PDF link), and you’re talking about scope. You’ve already agreed on your strategy—“improve the efficiency of the rock climbing school by offering online booking”—and now you need to come up with content requirements and a feature set. What’s needed? A page for each lesson, or one for each course of ten? A separate section for mountaineering, or is that overkill? Does the children’s intensive summer course need its own booking process, or could it share a generic one with the weekly adult course?
You need to involve the client in the process so that the decisions you make are workable, but they can’t make them on their own, because they don’t have enough expertise in web design (which is why they hired you in the first place). You’re practicing user-centered design, so the users’ needs are paramount, but you also have a limited budget, a deadline, and the school only has a part-time web editor. The decisions you make will affect the chances of meeting the deadline, the quality of the user experience, and the profitability of the school.
To add to the confusion, none of these questions has a “right” answer—that is, you and I could reasonably come up with different answers without one of us being wrong—and our answers will change over time as circumstances change.
Together, you decide that a page for each course is adequate, and that mountaineering isn’t sufficiently different from rock climbing to justify its own section. The summer school needs its own booking form, though, because it needs an upfront payment instead of a recurring one, and some extra fields for parental consent.
From a logical point of view, you’re making a number of assertions: that all 10-week courses can be represented as a single entity; that a generic layout can represent both mountaineering and rock climbing; and that booking the summer course is so different from booking the weekly one that it’s not practical to design a generic form without it becoming cumbersome. This is generalization in action: “abstraction from particular instances” as we defined above.
Example 2: structure
Fast-forward to a later meeting where you’re working on the site’s information architecture. The school has seven types of climbing courses, and the client originally planned to present each in its own section. You’ve agreed that this is a bad idea, because it’s confusing for users. But how can you break the list down into two or three broad categories that will make sense to both the users and the client?
To come up with a successful architecture you need to think about semantics. The way the school describes its courses internally includes jargon that could be confusing to its audience—but you don’t know much about the subject, so you’re dependent on the client to tell you what’s commonly understood. You also need to consider web conventions that most users will understand, irrespective of whether they’re familiar with rock climbing, and you want to build enough flexibility into the architecture to allow it to last for a few years, without overdoing it.
When you decide on the three categories, you are asserting that each course can be grouped into one of them—and that most users will be able to find the course they are looking for using the resulting architecture. As with the scope, the decisions you make about structure are generalizations.
A matter of judgment
Deciding on scope and structure isn’t the only time web designers generalize. Throughout the design process, you continually exercise your judgment to make decisions that often have far-reaching consequences. You use your experience and knowledge of working on the web to make the best decisions you can; and the quality of those decisions is a key source of your value in the design process.
Machines can’t generalize
When we generalize, we are using inductive logic, which is the type of logic that the human brain typically uses to make everyday decisions. A classic example of inductive logic is the way we respond to danger. For example, the first time we touch a steaming kettle, we notice that it is dangerously hot, and a reflex makes us move our hands away immediately. In the future, whenever we see a steaming kettle, we infer that it must be hot and therefore dangerous, and so do not touch it. Because all steaming kettles we have observed so far are dangerous, we infer that this one is too—an inductive inference, or generalization.
When we reach conclusions using inductive logic, they are not certain—it could be something other than the steam that makes the kettle dangerous (although I’d have a hard time convincing you of that in this example). This explains why, when we generalize, we can come up with two different answers that are both “right.”
Computers are good at mathematics and deductive logic, but they are useless at induction, and therefore can’t generalize—which is why artificial intelligence is still just science fiction. Computers can’t make the abstractions necessary to design a successful website—for that matter, neither could a human who was forced to follow a mechanical process instead of using his judgment and experience.
User-centered websites can’t be manufactured on a production line.
The value of a brain
In this article I’ve argued that because web design is poorly understood, the instinct of our bosses and clients is often to squeeze web designers to the point where it’s difficult to maintain our professionalism. This isn’t only bad for us—it’s bad for them too, because the final design will be inferior, and therefore less likely to meet its objectives.
One way to stop this from happening is to convince them that web design is a discipline in its own right, and that it requires human judgment and experience to succeed. Forever demanding that we work faster is a bit like asking us to behave like robots—streamlining to the point that we hardly use our judgment at all. But professional web designers can’t be replaced by robots—at least, not without seriously damaging the product—because generalization by human brains is an essential part of web design.
So next time your boss or client asks you to design a website in ten seconds flat, consider whether they’re effectively asking you to work like a robot. Explaining that a robot isn’t what they really need might persuade them to think again.
http://www.alistapart.com/articles/youarenotarobot
