User Interface Design – Is it A Science, An Art, or A Craft?

By Gerd Waloszek, SAP AG, SAP User Experience – November 6, 2003

At the CHI 2002 conference, which also marked the CHI's 20th anniversary, participants discussed the direction the conference should take: Should the CHI's focus be shifted toward science, design, or business concerns and practical methods? There were proponents for each direction, even though – thanks to the panel's composition – the science approach prevailed: "The conference isn't academic enough." Others, like Terry Winograd propose to shift the usability community toward the design community. In the panel, Donald Norman supported this view by stating that "we need more design." This year's CHI, however, seemed to indicate a shift toward business issues. In short, the discussion isn't over.

While some people may regard the CHI discussion as an academic debate, I personally feel somewhat torn by this issue in my daily work, too. It has to do with the self-image of one's own work as well as of the profession as a whole. In my thinking, however, the third dimension is craft – in some way it is related to practical methods and business. Therefore, in this article, I want to reformulate the above question with respect to user interface design and ask: Is it a science, an art, or a craft? Having offered an answer, I will then take a look at which authority user interface designers should refer to for guidance in their daily work: books, colleagues, gurus (and their practices), or users. I hope my answers to these questions will be helpful as well as provocative enough to spur some contradictions from readers.



On the one hand, many usability people and UI designers adopt a scientific approach or perspective, trying to derive their work practices and design decisions from sciences such as cognitive psychology, human perception, and social sciences. On the other hand, practical work again and again reveals that the connection between real work issues and research results is fairly vague; there is often little or no guidance from scientific research. Take, for example, the project on "research-based" Web guidelines by the National Cancer Institute. The guideline authors were surprised to find that only a few of the published usability guidelines they examined could in fact be related to scientific research results. Instead, most of them were based on "conventional wisdom."

Science has one prominent characteristic: It allows you to make reliable predictions. Such informed predictions would be very helpful in the daily work of UI designers because they would save them many an iteration cycle in the software design process. However, apart from a few notable exceptions, such as the GOMS model by Card, Moran and Newell, there are no scientific models that reliably predict human performance for given interfaces and tasks. And even more importantly, those models that do exist are far too cumbersome and expendable for use in an industrial environment, given the restrictions on time and human resources.

If science can't tell UI designers enough about software design, they can either base their design decisions on their own intuitions (see below: UI design as an art, according to the maxim "ask yourself") or adopt an empirical approach (maxim: "ask the users"). As a related outcome, a lot of practitioners in the UI profession stand up and tell the community what the best practices are for UI design – maxim: "ask the gurus."

Does this mean that science is good for conference appearances but not so good for practical work? Not quite, in my opinion. I nonetheless believe that UI designers must have basic knowledge of how humans process, structure, and perceive information – maxim: "ask the textbooks."



Some UI designers, particularly Web designers, regard user interface design as an art. Like Pablo Picasso or any other painter, they don't ask users how they should design (or paint). Instead, they follow their own inspiration. Regrettably, the results are not always appreciated by users and by usability people. This non-empirical approach has even been the source of many controversies between designers and usability people in the past. Compared to the more "democratic" approach of usability people, the "art" approach is somewhat "autistic" and personal – which is its strength and its weakness at the same time.

Personally, I have much sympathy for the "art" approach (and for the scientific as well). I doubt that outstanding designs can be the result of democratic decisions – maxim: ask yourself. (Most brainstorming theories, however, state just the opposite, namely that more ideas lead to better ideas in the end.) I also found that designing as an activity in which one implements one's own ideas is personally rewarding and satisfying – much more so than asking people and getting, for example, ten different answers from five people. Nevertheless, with the exception of some artistic Web pages, computer screens are far from being works of art. Like any other product they are designed to be used. In addition, they are created within the confines of an environment that imposes factual and technical restrictions that severely limit any creativity. When designing SAP software, I have to adhere to SAP's guidelines – there is no freedom of choice for me (apart from the option of starting my own company).

I do not deny that UI design, despite all the restrictions, requires creativity. But is it really an art where creativity, uniqueness, and aesthetics are the focus and primary design goals? I would say "no". Ease of use, efficiency, and perhaps pleasure of use are the focus, and these are quite different goals.



If UI design is neither science nor an art, what's left? Craft. And that's fine by me. Like any other craft, such as plumbing or brick laying, the craft of UI design has its own rules and guidelines, its application area, namely software applications, and its ways of acquiring craftsmanship. We have our guilds, our masters (or gurus), and you can find masterpieces of UI design as well as a lot of junk and bungling (take, for example, Jakob Nielsen's statements on the quality of Websites...).

Some people say that UI design is an engineering discipline. For the sake of simplicity, I do not differentiate between engineering and crafts, here. But you can contradict me if you like.

To sum up, I have much sympathy for the science and art approaches; I believe that both are useful contributors to our discipline. But our daily work has much more to do with the work of craftsmen, or if you prefer, engineers. Actually, I'm always trying to get this fact straight in my mind so that my feet remain firmly on the ground and I don't start acting like an artist.


Who Can You Ask?

Having proposed that UI design is a craft, let me move over to the question of how you can learn this craft and find your way through your daily work. In the following, I offer some answers.

Ask the Textbooks?

UI design is a large field, ranging from doing market research to analyzing tasks, prototyping, designing, and testing. Nobody can be an expert in all of these areas; everybody has his or her preferences. I, for example, like to design and to disseminate my knowledge. Others prefer going to customers, or testing products. UI designers therefore need to refer textbooks, such as books on human memory, perception, and human factors, as well as current publications from the field. To assist you in finding the right selection, the SAP Design Guild provides book reviews, lists important books, and presents news publications. Many software companies offer internal training courses in this field – SAP is no exception here. But at the end of the day, it is the practical work that transforms you into a "professional."

Ask Colleagues?

There is a tendency to let UI designers work alone on their projects. In my work, I have learned, however, to appreciate the value of a second pair of eyes and a second opinion. (Of course, it's better not to discuss those different opinions in front of the developers.) If you have to work on a project on your own, ask colleagues, show them your designs, and discuss these with them – provided they can spare some time for you.

Ask Tog (Ask the Gurus)?

There is a famous Web column called "Ask Tog" by Bruce Tognazzini. It's one example of a number of expert columns on UI design that you can find on the Web. The best-known column is probably Jakob Nielsen's "AlertBox" (see below for a list of columns and articles; see also a list of design professionals on the SAP Design Guild).

Obviously, there is no lack of gurus, opinions, and material on the Web as well as on paper. The only problem is to locate the resources and find the time to read them. This is an inherent problem with Websites, and the SAP Design Guild is no exception. Nonetheless, we try to help you find your way through this mass of information by offering pointers and articles that we hope will be useful.

There is another problem with gurus, though. As I already pointed out when discussing the science approach, the appearance of gurus somehow reflects the unsatisfactory scientific state of the field – or the fact that it's not a science at all but "only" a craft. Gurus tend to have the habit of preaching that their method is the be-all and end-all approach. This is simply not true. So, what saves us from becoming disciples of gurus? One approach is having limited time and resources. These restrictions force you to strip methods to their bare minimum. You will find that at least a rudimentary form of prototypical user and usage scenarios is far better than nothing at all. The remainder is the topping; but there are many toppings conceivable, each with its own advantages and disadvantages. I also suggest that you at least passively become a member of the UI community, watch the discussions, read books, go to conferences, and see the gurus in person. For me, at least, this helped a lot.

Ask the Users?

The current credo of the UI community is "ask the users." Regrettably, this message is not easy to get through to software companies. Perhaps we sometimes promise too much; we also often have difficulties in demonstrating the benefits of this approach. At the risk of becoming unpopular, I would, therefore, like to point to some of the caveats of the user-centric approach so that you can avoid disappointments and having your plans backfire.

Often, designers as well as developers listen too much to a singular opinion or request, resulting in a costly "random walk" design. Moreover, you will often find: Five people – ten opinions. That's why you should use only consolidated data for important design decisions. There is no such thing as a product that will completely satisfy 100% of its users, and this should not be our design goal. In case of obvious errors and shortcomings, of course, data from single subjects suffice.

The famous paper from Nielsen and Landauer (1993) perpetuated the lore that five users are enough for testing. According to the authors, this number suffices for finding 80% of the problems. Recently, this statement has been challenged, for example, by independent studies carried out by Rolf Molich and Jared Spool. In short, their results indicate that the more users you involve in your testing, the more errors you will find. (This issue generated much controversial discussion at the CHI 2003 conference.)

Correct generalization of test results is also a problem. Often you do not have the right user sample and take, for example, students instead. Most usability tests are "one-point" measurements and do not consider the time perspective. In most tests, first-time users or beginners are tested. Many problems encountered here vanish when people use a software regularly and become proficient.

Last but not least, the empirical approach of iterative design is unsatisfactory from a scientific point of view: Repeated iterations through a design are much more costly than designs based on reliable predictions from scientific research would be.

All in all, user data should be taken seriously. But designers and decision makers should also seriously consider what consequences can be rightfully derived from them. As a podium member on the CHI 2003 debate stated, there's a difference between promoting usability in a company and making far-reaching design decisions.


Final Word

So, what is UI design? Is it a science, an art, or a craft? My answer is: It's a craft that takes its wisdom from science, its inspiration from art and the design disciplines, its possibilities and limitations from software technology and corporate culture, and its directions – ideally – from the users.



  • CHI 2002: Future of CHI: CHI@20 – Panel held at the CHI 2002 Conference, Minneapolis, Minnesota
  • CHI 2003: The "Magic Number 5:" Is it Enough for Web Testing? Panel held at the CHI 2003 Conference, Fort Lauderdale, Florida.
    See CHI 2003 – New Horizons, But What Are They? (Trend IV: Methodology, Including Killing "Sacred Cows")
  • CHI 2003: Research-Based Web Guidelines: Do They Make Better Websites? Panel held at the CHI 2003 Conference, Fort Lauderdale, Florida.
  • Terry Winograd (Ed.) (1996). Bringing Design to Software. Addison Wesley.
    SAP Design Guild review of the book
  • GOMS model: Stuart K. Card, Thomas P. Moran, & Allen Newell (1983). The Psychology of HumanComputer Interaction. Lawrence Erlbaum Associates, Mahwah, NJ.
  • Nielsen, Jakob, and Landauer, Thomas K.: "A mathematical model of the finding of usability problems," Proceedings of ACM INTERCHI'93 Conference (Amsterdam, The Netherlands, 24-29 April 1993), pp. 206-213.

SAP Design Guild


top top